соединение разрывается, потому что VPN изменит маршрут по умолчанию, поэтому все идет в VPN. Вы можете изменить эту таблицу маршрутизации, но это может быть сложно исправить, особенно если вы потеряете доступ ssh, если что-то пойдет не так.
одно простое и простое решение-указать серверу, чтобы он достиг вашего IP-адреса через eth0, установив маршрут:
ip route add your_ip_address via the_server's_gateway
и надеясь, что сценарий VPN не коснется его.
если вы также хотите разрешить другим хозяевам доступ к исходному адресу сервера, то есть, если вы также хотите, чтобы ваш сервер отвечал на его исходный IP-адрес и IP-адрес VPN, вам нужно будет изменить, как VPN изменяет ваш маршрут, или, по крайней мере, знать, как он изменяет их, чтобы обойти то, что он делает.
в основном, то, что вы хотите-это правила маршрутизации. У вас будет две таблицы маршрутизации: одна будет использовать VPN, а другая не будет его использовать.
если сценарий VPN будет изменять только main таблица, после этого вы можно добавить другую таблицу маршрутизации для исходного IP-адреса.
так что в основном, перед запуском VPN, вы дублируете main содержимое в другую таблицу, например table 2 (2-произвольное число, см./etc/iproute2 / rt_tables для определения псевдонима имени):
ip route add (network)/(prefixlen) dev eth0 src (address) table 2
ip route add default via (gateway) dev eth0 src (address) table 2
теперь добавьте правило, чтобы использовать эту таблицу, если ваш сервер доступен по его исходному IP-адресу из eth0 интерфейс:
ip rule add to (address) iif eth0 table 2
затем вы запускаете VPN сценарий.
теоретически, вы должны бежать ip rule add перед добавлением маршрута по умолчанию к вашей второй таблице, потому что в противном случае ядро отклонит это правило, сказав, что оно не может направить к шлюзу. но в вашем случае он будет просто отлично работать как main уже маршрут к шлюзу.
Komp
2553
