Разрешение SSH на сервере с активным клиентом OpenVPN

У меня есть VPS под управлением CentOS 7, к которому я подключаюсь по SSH. Я хотел бы запустить клиент OpenVPN на VPS, чтобы интернет-трафик направлялся через VPN, но все же позволял мне подключаться к серверу через SSH. Когда я запускаю OpenVPN, мой сеанс SSH отключается, и я больше не могу подключиться к своему VPS. Как я могу настроить VPS так, чтобы входящие соединения SSH (порт 22) были открыты на фактическом IP-адресе VPS (104.167.102.77), но по-прежнему маршрутизировать исходящий трафик (например, из веб-браузера на VPS) через VPN?

Служба OpenVPN, которую я использую, - PrivateInternetAccess, и пример файла config.ovpn:

клиент
Dev Tun
прото удп
удаленный nl.privateinternetaccess.com 1194
разрешить-повторить бесконечный
nobind
упорствовать-ключ
упорствовать-чан
ca ca.crt
TLS-клиент
удаленный сервер cert-tls
аутентификации пользователей проход
Comp-LZO
глагол 1
ренег-сек 0
crl-verify crl.pem

IP-адрес VPS:

1: lo: mtu 65536 qdisc noqueue state НЕИЗВЕСТНО
    ссылка / петля 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1/8 хост хоста lo
       valid_lft forever предпочитаемый_lft forever
    inet6 :: хозяин области видимости 1/128
       valid_lft forever предпочитаемый_lft forever
2: ens33: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир 00: 50: 56: быть: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 scope global ens33
       valid_lft forever предпочитаемый_lft forever
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 область видимости ссылка
       valid_lft forever предпочитаемый_lft forever
4: tun0: mtu 1500 qdisc pfifo_fast состояние НЕИЗВЕСТНО qlen 100
    не ссылка / нет
    inet 10.172.1.6 peer 10.172.1.5/32 scope global tun0
       valid_lft forever предпочитаемый_lft forever

IP-маршрут VPS:

0.0.0.0/1 через 10.172.1.5 dev tun0
по умолчанию через 104.167.102.1 dev ens33 простатическая метрика 1024
10.172.1.1 через 10.172.1.5 dev tun0
10.172.1.5 dev tun0 Proto ядро ​​область ссылка src 10.172.1.6
104.167.102.0/24 dev ens33 область видимости ядра протока src 104.167.102.77
109.201.154.177 через 104.167.102.1 dev ens33
128.0.0.0/1 через 10.172.1.5 dev tun0

У меня проблема, похожая на эту, и я пытался исправить проблему, описанную в этом сообщении на форуме .

Идея состоит в том, что в настоящее время, когда вы подключаетесь к общедоступному IP-адресу, возвращаемые пакеты маршрутизируются через VPN. Вы должны заставить эти пакеты маршрутизироваться через ваш общедоступный интерфейс.

Надеемся, что эти команды маршрута сделают свое дело:

IP-правило добавить из таблицы хххх 128

ip route добавить таблицу 128 в гггг / у dev ethX

ip route добавить таблицу 128 по умолчанию через zzzz

Если xxxx - ваш общедоступный IP-адрес, yyyy / y - это подсеть вашего общедоступного IP-адреса, ethX - ваш общедоступный интерфейс Ethernet, а zzzz - шлюз по умолчанию.

Обратите внимание, что это не сработало для меня (с использованием Debian и PrivateInternetAccess), но может помочь вам.

Это может быть немного поздно, но ...

Проблема заключается в том, что шлюз по умолчанию изменяется OpenVPN, и это нарушает ваше текущее соединение SSH, если вы не настроили соответствующие маршруты перед запуском OpenVPN.

То, что следует, работает для меня. Он использует iptables и ip (iproute2). Ниже предполагается, что интерфейсом шлюза по умолчанию перед запуском OpenVPN является «eth0». Идея состоит в том, чтобы при установлении соединения с eth0, даже если eth0 больше не является интерфейсом шлюза по умолчанию, ответные пакеты для соединения снова возвращаются на eth0.

Вы можете использовать один и тот же номер для метки соединения, метки межсетевого экрана и таблицы маршрутизации. Я использовал разные числа, чтобы сделать различия между ними более очевидными.

# 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. Но в более старой системе Wheezy я только что обнаружил, что мне нужно добавить «через» к записи таблицы маршрутизации:

# 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.

Основываясь на ответе @MrK, я написал здесь простой код, чтобы сделать работу быстрее, чтобы вам не приходилось проверять интерфейсы / IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')

Я пробовал этот скрипт на 4 из моих VPS, и он работает отлично.

хм звучит как перекрытие подсети ip .... не зная больше о вашей схеме ip, кроме общедоступного ip для вашего завершения vpn как nl.privateinternetaccess.com, точно сказать не могу.

например, если удаленная подсеть на другой стороне nl.privateinternetaccess.com - 10.32.43.0/24, а ваш экземпляр находится в виртуальной частной сети aws, чья подсеть - 10.32.44.0/24. но ваш исходный ssh-клиент живет 10.32.43.0/24 (ваша сторона aws vpc), он не будет работать, так как обратный ssh-трафик будет ошибочно передаваться через vpn в Нидерланды.

предоставьте полную информацию ip / подсети для получения дополнительной помощи в этом.

...

хорошо, так ... похоже, ваш маршрут по умолчанию находится в туннеле, после подключения к nl:

0.0.0.0/1 через 10.172.1.5 dev tun0

так что вы можете изменить это после подключения. Много раз серверы vpn дают вам фиктивные маршруты. особенно на небрежном корпусе. в этом случае они отправляют вам маршрут по умолчанию, поэтому весь трафик с vps-ящика идет на nl. измените маршрут по умолчанию на 104.167.102.x или любой другой шлюз подсети ur у провайдера ur vps.

Когда вы включаете VPN, ваш шлюз по умолчанию заменяется. Это означает, что любой трафик, генерируемый или маршрутизируемый через ваш ящик, будет перенаправлен на шлюз VPN.

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

Мы сделаем это здесь. Сначала создайте новую таблицу маршрутизации и добавьте маршрут по умолчанию, который маршрутизирует все через ваш локальный шлюз:

# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>

Затем создайте новое правило фильтрации пакетов, которое маркирует весь трафик, выходящий из вашего ящика, с заданного исходного адреса с некоторым идентификатором.

# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>

Наконец, создайте политику маршрутизации, которая выбирает весь вышеупомянутый отмеченный трафик и маршрутизирует его, используя сгенерированную таблицу выше.

ip rule add fwmark <mark> table <table>

Еще раз, значения <mark>и <table>являются произвольными идентификаторами по вашему выбору.

Для меня с запуском сервера OpenVPN в pfSense я должен был снять флажок «Принудительно генерировать весь клиентский трафик IPv4 через туннель».