SSH к Серверу, который подключен к VPN
Мой сервер должен быть подключен к VPN как клиент. Когда я запускаю скрипт OpenVPN (от HMA), соединение с моей локальной машины на сервер по SSH теряется - соединение больше не возможно, и я должен вручную уничтожить процесс VPN. Кроме того, скрытый сервис TOR (.onion страница) недоступен в то время.
Возможно так или иначе, что страница TOR доступна, и я могу соединиться по SSH, в то время как сервер подключен к VPN?
2 ответа
У меня есть подобная проблема. Мой рабочий стол Ubuntu находится на VPN, и мое нормальное соединение SSH не работает снаружи домашней сети.
Что-то я действительно просто думал, все же. Вам все еще передавали порты тому компьютеру?
VPN присваивает новый IP-адрес от сайта VPN, таким образом, маршрутизатор больше не может находить что IP-адрес соединяться с.
я предположил бы, что необходимо будет знать новый IP-адрес, присвоенный хостом VPN знать что адрес соединиться с.
я только высказываю образованные предположения, не известную фиксацию; поэтому не оскорбляйте меня, если это не работает. :)
На дальнейшем расследовании, я обнаружил, что необходимо передать порты через VPN (я думаю), потому что VPN перенаправляет порт 80, и туннели SSH обычно используют порт 22. Я думаю, что Вам нужно к порту передачи 22 через Вашу VPN так, чтобы, когда Вы соединяетесь со своим vpn на порте 80, это перенаправило Вас до Вашего переданного порта, требуемого Вашим туннелем SSH т.е. PuTTy.
я все еще не на 100% уверен, что это - то, как сделать это. Если бы кто-то может подтвердить, что, это было бы большим.
Проблема состоит в том, что шлюз по умолчанию изменяется OpenVPN, и который прерывает любое соединение, происходящее в интерфейс не-VPN. Linux отправит ответы на пакеты, которые вошли в реальном интерфейсе интерфейс VPN! Необходимо настроить соответствующие маршруты перед запуском OpenVPN.
, Что следует за работами для меня. Это использует iptables и IP (iproute2). Ниже, предполагается, что интерфейс шлюза по умолчанию перед OpenVPN запускается, "eth0". Идея состоит в том, чтобы гарантировать, чтобы, когда связь с eth0 установлена, даже если eth0 больше не является интерфейсом шлюза по умолчанию, ответные пакеты для соединения возвратились на eth0 снова.
Вы могли использовать то же число для метки соединения, метки брандмауэра и таблицы маршрутизации. Я использовал отличные числа для создания diffences между ними более очевидным.
# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412
# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412
ОБНОВЛЕНИЕ ===
:
Вышеупомянутое хорошо работает для меня на Debian Jessie. Но в более старой Хрипящей системе я только что нашел, что должен добавить "через" к записи таблицы маршрутизации:
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412
Там "12.345.67.89" должен быть исходный нешлюз VPN.