У меня есть 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:
client dev tun proto udp remote nl.privateinternetaccess.com 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt tls-client remote-cert-tls server auth-user-pass comp-lzo verb 1 reneg-sec 0 crl-verify crl.pem
IP-адрес VPS:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:be: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 preferred_lft forever
inet6 fe80::250:56ff:febe:16f7/64 scope link
valid_lft forever preferred_lft forever
4: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 10.172.1.6 peer 10.172.1.5/32 scope global tun0
valid_lft forever preferred_lft forever
IP-маршрут VPS:
0.0.0.0/1 via 10.172.1.5 dev tun0 default via 104.167.102.1 dev ens33 proto static metric 1024 10.172.1.1 via 10.172.1.5 dev tun0 10.172.1.5 dev tun0 proto kernel scope link src 10.172.1.6 104.167.102.0/24 dev ens33 proto kernel scope link src 104.167.102.77 109.201.154.177 via 104.167.102.1 dev ens33 128.0.0.0/1 via 10.172.1.5 dev tun0
Основываясь на ответе @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, и он отлично работает.
Это может быть немного поздно, но ...
Проблема в том, что шлюз по умолчанию изменяется 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 я только что обнаружил, что мне нужно добавить «via» в запись таблицы маршрутизации:
# 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.
У меня аналогичная проблема, и я пытаюсь исправить, описанное в это сообщение на форуме.
Идея состоит в том, что в настоящее время, когда вы подключаетесь к общедоступному IP-адресу, ответные пакеты маршрутизируются через VPN. Вам необходимо принудительно маршрутизировать эти пакеты через ваш общедоступный интерфейс.
Надеемся, что эти команды маршрута помогут:
ip правило добавить из таблицы x.x.x.x 128
ip route добавить таблицу 128 в гг.г.г / г dev ethX
ip route добавить таблицу 128 по умолчанию через z.z.z.z
Где x.x.x.x - ваш общедоступный IP-адрес, y.y.y.y / y должен быть подсетью вашего общедоступного IP-адреса, ethX - вашим общедоступным интерфейсом Ethernet, а z.z.z.z - шлюзом по умолчанию.
Обратите внимание, что у меня это не сработало (с использованием Debian и PrivateInternetAccess), но может вам помочь.
хм звучит как перекрытие подсети IP .... не зная больше о вашей схеме IP, кроме общедоступного IP для вашего терминала vpn как nl.privateinternetaccess.com, не могу сказать наверняка.
так, например, если удаленная подсеть на другой стороне nl.privateinternetaccess.com - 10.32.43.0/24, а ваш экземпляр находится в aws vpc с подсетью 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-трафик через туннель».
У меня была такая же проблема с экземпляром AWS (VPN-клиент), подключенным к локальному серверу OpenVPN, и я не могу получить к нему доступ, если я не подключен к тому же VPN-серверу или локальной сети. Решение просто добавляло маршрут от общедоступного IP-адреса локального компьютера к шлюзу экземпляра AWS.
ip route add xx.xxx.xx.xx via 172.xx.xx.1 dev eth0
и я могу повторить то же самое для любого внешнего пользователя, которому нужен доступ к экземпляру AWS, поскольку он нужен только для совместного использования с горсткой внешних пользователей.
Расширение на https://serverfault.com/a/660106/577384 и https://serverfault.com/a/793700/577384. Чтобы это работало должным образом с общедоступными службами докеров, мне также пришлось сделать ip -4 rule add to 172.0.0.0/8. Чтобы пакеты, идущие на localhost (службы докеров), не перенаправлялись через eth0. Убедитесь, что это правило превалирует над правилом «таблицы».
У меня также есть следующее правило перед остальными правилами iptable для устройств LAN в целом iptables -A PREROUTING -t mangle -s 192.168.0.0/16 -j ACCEPT -m comment --comment "Skip special route for LAN".
(Я настаиваю, что мне понадобится что-то подобное для IPv6, но у меня еще нет докера, работающего в IPv6)