Попередити втрату з'єднання SSH після входу в VPN на серверній машині


14

У мене виникло питання, з яким я не можу вирішити питання. Коли я входжу на VPS через SSH і намагаюся встановити VPN-з'єднання на цьому VPS, SSH-з'єднання між VPS та моєю машиною втрачається. Я припускаю, що це тому, що маршрутизацію змінили налаштування VPN. Як цього запобігти?


Що з підключенням до SSH після встановлення VP? : p Ви праві, що це викликано тим, що VPN перезаписує маршрути маршрутів. Що ви можете зробити, це зберегти свої первісні шляхи недоторканими та просто додати додатковий шлях VPN (якщо ви не хочете використовувати свій VPS як проксі. Це вже інша історія). Якого клієнта ви використовуєте?
Миколаїдіс Фотіс

Що ви маєте на увазі під "спробою встановити VPN-з'єднання на цьому VPS"? Ви підключаєтесь зі свого комп'ютера до сервера Openvpn на VPS? Ваш VPS підключається до сервера Openvpn, який працює на третьому хості? В останньому випадку таке VPN-з'єднання відштовхує деякі маршрути назад? Також підтвердьте, що немає перекладу NAT, щоб дістатися до вашого VPS (IP-адреса, налаштована на його інтерфейсі, така сама, яку ви вказали у підключенні SSH?
Damiano Verzulli

@NikolaidisFotis Я не в змозі підключитися, оскільки VPN працює. Я використовую клієнт openvpn. Є --route-noexecможливість ігнорувати маршрути, що надсилаються сервером, але, як ви вже згадували, це не допомагає, коли я хочу використовувати VPN як проксі ...
mic22

@DamianoVerzulli другий варіант, так, маршрути висуваються (але я думаю, що це потрібно зробити, оскільки мені потрібен VPN, щоб діяти як проксі, щоб закрити оригінальну IP-адресу машини), і немає NAT
mic22

Відповіді:


6

Вам потрібно додати route-nopullопцію (та видалити, redirect-gatewayякщо вона існує) до файлу конфігурації вашого клієнта OpenVPN на VPS.

Таким чином, підключення до VPN-сервера не змінить жодних маршрутів вашого VPS, тому ви зможете самостійно встановити ті, що вам потрібні.


Гей, дякую за цю пораду, але зараз я не можу зайти до Інтернету через tun0. Я гадаю, що мені бракує шлюз. Будь-які ідеї, як додати шлюз для tun0? Відповідна частина ifconfig:inet addr:10.56.10.6 P-t-P:10.56.10.5 Mask:255.255.255.255
Housemd

Вам потрібно вручну додати маршрут до самого сервера VPN через шлюз провайдера ISP за замовчуванням, а потім додати шлюз за замовчуванням через 10.56.10.5 для всього іншого трафіку
Anubioz

Вибач, що? Я поняття не маю, що ти щойно сказав. Чи можете ви навести приклад?
Housemd

Дозвольте лише уточнити - я не хочу, щоб маршрут за замовчуванням був через tun0, але мені потрібен tun0, щоб мати доступ до Інтернету.
Housemd

@Housemd hm вам потрібно мати доступ до Інтернету через tun0 самостійно або вам потрібні клієнти, підключені через tun0 з інших місць, щоб мати доступ до Інтернету?
Анубіоз

4

Розглянемо наступний сценарій:

  1. ваш VPS має єдиний інтерфейс Ethernet, налаштований з IP-адресою 4.3.2.1/24;
  2. ваш VPS може отримати доступ до Інтернету через шлюз за замовчуванням 4.3.2.254
  3. ваш VPS ще не активував жодне з'єднання OpenVPN; отже, немає активного інтерфейсу tun

У такому сценарії з Вашої машини (припустимо, Ваша машина 9.8.7.6/24 з def-gw 9.8.7.254) Ви зможете успішно встановити з'єднання SSH до 4.3.2.1. Отже, обидва хости 4.3.2.1 та 9.8.7.6 можуть успішно дістатися один до одного.

Тепер, якщо встановлено таке з'єднання SSH, припустимо:

  1. ви запускаєте OpenVPN-з'єднання зі свого VPS 4.3.2.1;
  2. як такий, новий інтерфейс tun0 буде динамічно налаштований (припустимо, йому буде призначено 10.10.10.2 IP, з 10.10.10.1 PTP).

На цій стадії:

  • Якщо жоден маршрут не буде висунутий з віддаленого сервера OpenVPN до локального VPS, то в процесі маршрутизації нічого не зміниться, і ваше SSH-з'єднання виживе без проблем. У цьому випадку єдиним трафіком, що проходить через VPN, є той, який спрямований на віддалений сервер OpenVPN (10.10.10.1);

  • Якщо віддалений сервер OpenVPN відштовхне деякий маршрут, і особливо, якщо шлюз VPS за замовчуванням буде замінено на 10.10.10.1 (віддалений кінцевий пункт OpenVPN), ТОГО виникнуть проблеми. У цьому випадку ви тунелюєте ВСІ вихідні IP-трафіки (за винятком самого OpenVPN) всередині VPN.

У другому випадку (замінивши def-gw одразу після встановлення VPN-з'єднання) ваше попереднє з'єднання SSH "зависне" через асиметричну маршрутизацію:

  • Трафік від вашої машини (9.8.7.6) до VPS (4.3.2.1) буде протікати по попередньому, ніколи не зміненому шляху;
  • Трафік від VPS (4.3.2.1) до Вашої машини (9.8.7.6):
    • без VPN (отже, спочатку) був спрямований через шлюз 4.3.2.254;
    • після встановлення VPN-зв’язку з відповідною заміною def-gw здійснюється маршрутизація через VPN (10.10.10.1).

Іншими словами: як тільки буде встановлено VPN-зв'язок, ваш шлях повернення з VPS на ваш апарат зміниться і ... це не дуже добре (кілька мережевих пристроїв, вздовж шляху повернення, можуть розпізнати такі асиметричні шлях і просто скиньте пакети).

Крім того, велика ймовірність того, що ваш віддалений сервер OpenVPN виконує роль NAT-вікна: весь трафік, що надходить від VPN, буде NATET із відкритим IP-адресою віддаленого сервера OpenVPN. Якщо це правда, ніж справ більше немає ... "не добре", але, безумовно, "погано", що стосується вашого SSH-з'єднання: повернення трафіку, окрім повернення за іншим маршрутом, повертається до вашої машини з інший джерело IP (один із відкритого інтерфейсу VPN-сервера).

Як вирішити цю проблему?

Досить легко, справді.

Просто вкажіть ваш сервер VPS не маршрутизувати трафік на вашу машину вздовж VPN, а, замість цього, спираючись на попередній маршрут . Перед запуском OpenVPN це повинно бути таким же простим, як додавання:

     route add -host 9.8.7.6 gw 4.3.2.254

де:

  • 9.8.7.6 - це загальнодоступна IP-адреса вашої машини
  • 4.3.2.254 - це оригінальний шлюз за замовчуванням вашого VPS.

PS: надавши набагато більш детальне запитання, ви отримали б набагато швидшу відповідь :-)


Дякую за вашу відповідь @DamianoVerzulli! Шлюз за замовчуванням не визначений. route addкоманда з такими SIOCADDRT: Invalid argument
0,0,0,0 гВ

Ось що я отримую відразу після підключення openvpn[server] Peer Connection Initiated with [AF_INET]64.251.27.139:443; 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 10.200.1.251/22 broadcast 10.200.3.255; ERROR: Linux route add command failed: external program exited with error status: 2
mic22

@ mic22: Цікаво, як не можна вказати def-gw вашого VPS, оскільки в такому випадку такий VPS не може досягти нічого за межами локальної підмережі (а це означає, що і ваша машина - можливо, зможе підключитися через SSH-- і сервер OpenVpn --би мати можливість встановити VPN-- повинен бути "локальним" і, як такий, зовсім марним!). BTW: підключившись через SSH, ви можете легко отримати def-gw за допомогою "netstat -rn" (рядок, що починається з 0.0.0.0, другий стовпець)
Damiano Verzulli

netstat -rnВ результаті 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0VPS, який я використовую, є базовим варіантом OVH з сервером Ubuntu 14.04 на борту
mic22

ifconfigта netstat -rnвихід: goo.gl/TEZ61q
mic22

0

Це може допомогти:

покласти TCPKeepAlive=yesв свою/etc/ssh/sshd_config

З

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Вказує, чи повинна система надсилати повідомлення про підтримку TCP в іншу сторону. Якщо вони будуть надіслані, загибель підключення або збій однієї з машин буде помічено належним чином. Однак це означає, що з'єднання загинуть, якщо маршрут тимчасово не працює, а деяким людям це буде дратує. З іншого боку, якщо збереження TCP не буде надіслано, сеанси можуть нескінченно висіти на сервері, залишаючи користувачів `` привидів '' та споживаючи серверні ресурси.

За замовчуванням yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set toнемає "".


У мене вже було TCPKeepAliveвстановлено варіант, щоб yesце не було правильним рішенням
mic22

0

У мене була ця проблема і спробували всі рекомендовані рішення, і все-таки моя проблема не була вирішена!

Після багатьох спроб рішення я використав screenкоманду. (мій клієнт VPN - це cisco-any-connect).

$ screen -R VPN
$ openconnect -b "your server"

Надавши свій обліковий запис, негайно натисніть ctrl + a + d і поверніться до свого сеансу.


0

Особисто я вважаю за краще, щоб усі підключення до SSH проходили через VPN. У разі активного ssh-з'єднання до встановлення VPN, він повинен знову підключитися через змінений маршрут.

Я рекомендую використовувати autossh Під конфігурацією клієнта ssh просто додати.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes
  • BatchMode розшифровується як автоматичне підключення
  • ServerAlive розшифровується як Keeping Alive

-1

Після підключення VPN, ssh відключається через те, що ssh трафік із сервера проходить через VPN-сервер. Отже, щоб уникнути цього, перед підключенням VPN виконайте таку команду.

route add -host your-machine-public-ip gw Server-gatway-ip dev eth0

your-machine-public-ip: IP вашої машини, з якої ви робите SSH. Server-gatway-ip: IP-адреса маршрутизатора / маршрутизатора цього сервера

Вищевказана команда буде перенаправляти трафік через заданий шлюз, а не через VPN-сервер.


Це заплутано, і, здається, мова має її назад. Чи не хочете ви додати маршрут із IP-адресою цілі SSH та шлюзом локальної робочої станції за замовчуванням?
rmalayter
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.