Предотвращение потери соединения SSH после входа в VPN на сервере

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

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

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

Давайте рассмотрим следующий сценарий:

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, предположим:

4. вы запускаете соединение OpenVPN с вашего VPS 4.3.2.1;
5. таким образом, новый интерфейс tun0 будет динамически сконфигурирован (предположим, ему будет назначен IP-адрес 10.10.10.2 с PTP 10.10.10.1).

На этом этапе:

• Если ни один маршрут не будет перенаправлен с удаленного сервера OpenVPN на ваш локальный VPS, то с точки зрения маршрутизации ничего не изменится, и ваше SSH-соединение будет работать без проблем вообще. В этом случае единственный трафик, проходящий через VPN, - это трафик, направленный на удаленный сервер OpenVPN (10.10.10.1);

• Если удаленный сервер OpenVPN будет отодвигать некоторый маршрут и EXPECIALLY если 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, будет NAT с публичным 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: предоставив гораздо более подробный вопрос, вы бы получили гораздо более быстрый ответ :-)

Это может помочь:

положить 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нет ''.

У меня была эта проблема, и я попробовал все рекомендуемые решения, и все же моя проблема не была решена!

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

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

После предоставления ваших учетных данных, немедленно нажмите Ctrl + A + D и вернитесь к сеансу.

Лично я предпочитаю, чтобы все подключения к SSH маршрутизировались через VPN. В случае активного ssh-соединения перед установкой VPN, он должен переподключиться из-за изменения маршрута.

Я рекомендую использовать autossh Под вашей конфигурацией клиента ssh просто добавьте.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode означает автоматическое переподключение
• ServerAlive расшифровывается как Keeping Alive

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

добавление маршрута -host your-machine-public-ip gw Сервер-gatway-ip dev eth0

your-machine-public-ip: IP вашего компьютера, с которого вы делаете SSH. Server-gatway-ip: IP-адрес Gatway / router этого сервера

Приведенная выше команда перенаправит трафик через данный шлюз, а не через VPN-сервер.