LINUX.ORG.RU
ФорумAdmin

ipsec соединение рубит LAN трафик

 , , ,


0

1

Поднял ipsec подключение через strongswan

conn remotehost
        keyexchange=ike
        dpdaction=clear
        dpddelay=300s
        eap_identity=LOGIN
        leftauth=eap-mschapv2
        left=%defaultroute
        leftsourceip=%config
        right=remotehost.net
        rightauth=pubkey
        rightsubnet=0.0.0.0/0
        rightid="remotehost"
        type=tunnel
        auto=add

После ipsec up remotehost отваливается весь LAN трафик, включая SSH подключения. При этом как VPN всё работает - IP адрес при HTTP запросах определяется как адрес VPN сервера, а не мой.

Если бы это была какая-то традиционная технология, создающая отдельный сетевой интерфейс - я бы сказал что надо отключить смену default gateway (в конфиге openvpn это элементарно делалось), но здесь его нет в природе.

Интерфейсы:

lo
enp0s3 192.168.112.112 - LAN
enp0s8 10.0.3.15 - интернет

Это виртуалка, на которой я тестирую. В реальной работе будет VPS с одним сетевым интерфейсом, к которому будет подключение пользователя по SSH и через него же VPS имеет доступ к интернету.

Я неоднократно делал такие вещи с openvpn: создаю несколько tun/tap адаптеров и соединений в разные локации, потом в коде создаю сокет, делаю bind с нужным адресом и трафик с каждого сокета будет идти через нужное VPN соединение.

Прошу подсказать как сделать c ipsec так же, чтобы, как минимум, можно было продолжать работать по SSH без обрывов связи. Как максимум, чтоб через VPN шел только трафик с сокетов, бинд которых был сделан на IP адрес полученный от VPN сервера.



Последнее исправление: Dima_228 (всего исправлений: 1)

Потому, что на уровне ipsec нет маршрутизации, в поле rightsubnet указывается маска, адрес сети или конкретный адрес назначения, пакеты с адресами назначения, подпадающие под эту маску будут отправляться на другую сторону IPSEC туннеля.

У тебя там указано 0.0.0.0/0, а под эту маску подпадают все пакеты.

anonymous
()
Ответ на: комментарий от anonymous

Понял. Если я укажу там что-нибудь несуществующее, например,

rightsubnet=192.168.250.0/24

то все пакеты кроме адресованных в эту сеть, будут отправляться в обычный интернет мимо VPN. Как я могу получить какой-то локальный IP и биндить его? В реализации которую я выше описал, разделение потоков на разные VPN соединения не обязательно было по хостам или адресам (имею в виду что разные запросы к одному и тому же сервису могли уходить через разные соединения, представьте задачу как использования 10 разных сервисов по 2 API ключа к каждому, чтобы разные API ключи не использовались с одного IP, то что я делал максимально похоже на эту задачу).

Dima_228
() автор топика

Вообще то, IPSEC в туннельном режиме может выглядеть как отдельный интерфейс - xfrm. Только это не решает вашу проблему с маршрутизацией.

Bloody ★★
()

Если бы это была какая-то традиционная технология, создающая отдельный сетевой интерфейс - я бы сказал что надо отключить смену default gateway (в конфиге openvpn это элементарно делалось)

Пиписек это прям самая традиционная из технологий. Попенвпн это новодел по сравнению с ним. И емнип пиписек в линуксе создаёт отдельный интерфейс, хотя может в strongswan оно где-то спрятано

но здесь его нет в природе.

Дефолтный гейт это либо left=%defaultroute либо 0.0.0.0/0 которые вы в конфиге прописали. Не работал со strongswan, но и то и другое вполне означают «пихать весь трафик сюда».

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

пиписек в линуксе создаёт отдельный интерфейс

Только ip a его не видит. То есть при попытке bind() на созданный сокет я пойду очень далеко по известному адресу.

Пробовал для той же задачи Cloudflare Warp задействовать. Создается интерфейс CloudflareWARP, с ip адресом, всё как мне надо, сеть вроде не рушится, но всё равно он либо заворачивает весь трафик, либо ничего (всякие doh-only режимы).

В сети нашел вариант реализации с командой

warp-cli add-excluded-route 0.0.0.0/1

но по какой-то причине, мой warp-cli не имеет такой команды.

Dima_228
() автор топика

Для lan нужно создать отдельные конфигурации с политикой passthrough. Создать отдельный интерфейс можно (xfrm), но там есть ограничения по версии самого strongswan. Емнип, для этого надо перейти на конфиг swanctl.conf вместо ipsec.conf
И лично мне swanctl нравится больше с его local/remote вместо архаичных left/right

Khnazile ★★★★★
()
Ответ на: комментарий от upcFrost

И емнип пиписек в линуксе создаёт отдельный интерфейс

Как раз нет. То что можно накостылять и отдельный интерфейс это да, слышал что делают и такие костыли, но изкаробки нет.

Не работал со strongswan, но и то и другое вполне означают «пихать весь трафик сюда».

С ipsec робит ip xfrm policy, а не традиционно привычный ip ro s table all.

anc ★★★★★
()
Ответ на: комментарий от Bloody

Через systemd-networkd ничего не получилось, интерфейс не появляется. Действовал по аналогии с https://www.linkedin.com/pulse/create-virtual-network-devices-network-config-manager-susant-sahani

Однако, получилось сделать так:

ip link add eth6 type dummy
ip link set eth6 up

Далее в конфиге /etc/strongswan.d/charon.conf подправил следующие параметры:

install_routes = no
install_virtual_ip = yes
install_virtual_ip_on = eth6

ipsec restart

чем добился того что новый внутренний IP 10.60.ххх.ххх/32 присваивается не вторым моей реальной сетевухе, котрая смотрит наружу (нат), а этой виртуальной eth6. Но простейшая проверка

curl --ipv4 --interface eth1 api.ipify.org
curl --ipv4 --interface eth6 api.ipify.org

показывает следующее: с реального интерфейса получает мой реальный IP адрес (то есть теперь всё подряд не заворачивается в туннель), но второй зависает (таймаута не дождался). Записал всё в tcpdump - на интерфейсе eth6 поймано 0 пакетов. Хотя вот таким путём я, по идее, должен добиться желаемого: весь трафик идет через обычный интерфейс, и только если сделать bind() адреса присвоенного eth6 трафик пойдет через туннель.

Dima_228
() автор топика
Ответ на: комментарий от Bloody

Изменил на

ip link add eth6 type xfrm if_id 128

Принципиально ничего не изменилось, кроме того что в процессе точного повторения вчерашнего эксперимента tcpdump на интерфейсе eth6 записал 2 блока, которые в Network Monitor отображаются как

Frame: Number = 1, Captured Frame Length = 48, MediaType = Unhandled Media Type 57445 ProtocolWarning: Media Type not supported, please report to www.codeplex.com/nmparsers

Ну и ещё одна проблема: на eth6 выдался адрес 10.58.x.y. Из консоли пинг на 10.58.x.y проходит нормально и не фиксируется tcpdump’ом (это нормально), но ping 10.58.x.1 должен уходить с eth6, вместо этого пакеты уходят с другого интерфейса (локальной сети) и ответа нет.

Dima_228
() автор топика
Последнее исправление: Dima_228 (всего исправлений: 1)