У меня есть виртуальный частный сервер, на котором я хотел бы запустить веб-сервер, когда мой сервер подключен к службе VPN
Когда VPN-соединение с моим провайдером не установлено, я могу делать все, что захочу, с этим сервером, ssh, scp, http и т. Д.
Когда openvpn запущен и подключен к VPN-сервису провайдера, сервер недоступен никакими средствами и, конечно, по уважительной причине.
Картинка примерно такая:
My VPS ------------
+----------------+ / \
| | / Internet / 101.11.12.13
| 50.1.2.3|-----------------\ cloud /----<--- me@myhome
| | / \
| 10.80.70.60| / \
+----------------+ \ \
: \_____________/
: :
: :
: :
: :
+------------------+ :
| 10.80.70.61 | :
| \ | :
| \ | :
| 175.41.42.43:1197|..............:
| 175.41.42.43:yy|
| ..... |
| 175.41.42.43:xx|
+------------------+
Legend
------ Line No VPN connection present
...... Line VPN connection established
Вещи, чтобы уточнить:
- Все IP-адреса и номера портов выше и ниже являются вымышленными
- Строки с номерами портов xx, yy и любым другим между ними - мое предположение, а не то, что я точно знаю.
- Я настроил задание cron, которое запускается каждую минуту, проверяет пинг другого моего VPS, на котором работает apache2. В журналах apache2 я вижу изменение исходного IP-адреса с 50.1.2.3 на 175.41.42.43, когда VPN активен, поэтому VPN работает нормально.
Журналы OpenVPN показывают это:
UDPv4 link remote: [AF_INET]175.41.42.43:1197
[ProviderName] Peer Connection Initiated with [AF_INET]175.41.42.43:1197
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.80.70.60 peer 10.80.70.61
На данный момент, я хотел бы иметь возможность SSH от myhome
к My VPS
в картине, в то время как VPN вверх и с помощью PuTTY.
Раньше на одном из моих рабочих мест мне давали очень странную последовательность ssh на один чрезвычайно безопасный сервер с тремя @
знаками в строке. Итак, он прыгал с коробки на коробку, как я себе представляю, но, поскольку на коробках перехода работала некая версия ОС Windows и проприетарное приложение для них, я не мог видеть, что происходит под покровом. Поэтому я не обращал особого внимания. Теперь я начинаю понимать, что могу оказаться в такой же или похожей ситуации.
Используя IP-адреса и порты в схеме и / или фрагменте журнала, может кто-нибудь сказать мне, как я могу пройти через этот туннель и получить доступ к своему серверу?
источник
Это может быть немного поздно, но ...
Проблема в том, что шлюз по умолчанию изменяется OpenVPN, и это нарушает ваше текущее соединение SSH, если вы не настроили соответствующие маршруты перед запуском OpenVPN.
То, что следует, работает для меня. Он использует iptables и ip (iproute2). Ниже предполагается, что интерфейсом шлюза по умолчанию перед запуском OpenVPN является «eth0». Идея состоит в том, чтобы при установлении соединения с eth0, даже если eth0 больше не является интерфейсом шлюза по умолчанию, ответные пакеты для соединения снова возвращаются на eth0.
Вы можете использовать один и тот же номер для метки соединения, метки межсетевого экрана и таблицы маршрутизации. Я использовал разные числа, чтобы сделать различия между ними более очевидными.
===
ОБНОВИТЬ:
Вышесказанное прекрасно работает для меня в Debian Jessie. Но в более старой системе Wheezy я только что обнаружил, что мне нужно добавить «через» к записи таблицы маршрутизации:
Там "12.345.67.89" должен быть оригинальный шлюз не VPN.
источник