☰

Маршрутизация трафика между двумя туннелями IPsec

tag-icon • tag-icon vpn ipsec strongswan backend libreswan
Маршрутизация трафика между двумя туннелями IPsec

Я запускаю бэкэнд на инфраструктуре DO, назову его сайтомИви, который подключается к стороннему сайтуПровчерез туннель IPsec с помощью этой конфигурации libreswan:

conn prov-client
  ...
  right=$YVI_IP
  rightsourceip=10.31.3.1
  rightsubnet=10.31.3.0/28
  left=$PROV_IP
  leftsubnet=10.70.0.36/28

Провимеет работающий сервер 10.70.0.37, и я могу взаимодействовать с ним изИви.

Моя проблема в том, что я настраиваю локальную среду разработки (Ubuntu box в другой сети), и каждый раз, когда я вношу изменения, мне приходится выполнять развертывание вИвипотому что только оттуда я могу получить доступ к API вПров. Я хотел бы избежать этого, подключивМестныйкИвии направить этот трафик наПровчтобы иметь возможность достичь API вПровотМестныйи облегчить разработку.

Я подключаюсьМестныйкИвикак дорожный воин со следующей конфой:

conn remote-dev-client
  ...
  left=$YVI_IP
  leftsubnet=10.31.3.0/28
  right=%any
  rightaddresspool=10.31.4.1-10.31.4.254

Соединение установлено успешно и изМестныйЯ могу дотянуться 10.31.3.1доИви. Я хочу достичь 10.70.0.37вПровотМестный. Маршрут к 10.70.0.36/28сети не добавляется автоматически, поэтому я попробовал настроить некоторые ip xfrmправила ip routeвручную наМестный:

# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000

# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000

ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static

Я теперь бегу ip xfrm monitorнаИвии затем изМестныйping 10.70.0.37; Я вижу пакеты, прибывающие наИви(из монитора xfrm вИви), но только исходящий, а не ответный (как это видно, если я пингую 10.31.3.1, например), что говорит о том, чтоИвиполучает трафик, но не направляет егоПров? Я действительно не знаю, как это интерпретировать.

Я думаю, мне нужно добавить маршруты вИвидля маршрутизации трафика кПровAPI правильно, но добавление подобных правил к тем, что выше, не сработало. Я был бы признателен за помощь в понимании того, что я упускаю, и что я делаю неправильно.

Предложения по другому подходу также приветствуются, хотя единственный способ подключиться кПров, который я не контролирую, проходит через туннель IPsec отИви, который я контролирую.

решение1

Я смог решить это с помощью правил NAT iptables. ip xfrmПолитики не были нужны. Вот небольшое объяснение того, что я сделал, для тех, кто, как и я, не является экспертом:

ОтИвиЯ назначаю дорожным воинам 10.31.4.0/24подсеть, поэтому маршрут для этой сети автоматически устанавливается демоном управления ключами (libreswan в моем случае), поэтому я добавил правила NAT вИви( /etc/ufw/before.rulesтак как я использую UFW, но вы можете добиться того же самого iptablesнапрямую):

*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# PRE 
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37


# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1

COMMIT

Сообщает *natiptables о необходимости применения правил к таблице NAT, а COMMITфактически сохраняет правила. -FЗдесь просто для удобства, так как UFW добавляет правила, ufw enableно не удаляет их, ufw disableпоэтому в итоге у вас будут дубликаты, отсюда и флаг очистки -F.

Правило PREROUTINGприменяется к пакетам, входящим из подсети Road Warrior, предназначенным для 10.31.3.2, и оно изменяет адрес назначения на 10.70.0.37, 10.31.3.2фактически назначая этот IP-адресПровсервер, с точки зрения дорожных воинов.

Правило POSTROUTINGприменяется к пакетам, входящим из подсети Road Warrior, которые собираются выйти 10.70.0.37(то есть, к пакетам, которые только что попали в правило предварительной маршрутизации), и изменяет их адрес назначения с адреса в 10.31.4.0/0на 10.31.3.1. Это необходимо, поскольку я не контролирую маршруты, сервер или что-либо вПров, так что еслиПровполучает запрос из 10.30.4.0/24подсети, он не знает, как ответить. Но он знает 10.31.3.1.

И все! Теперь я могу дотянутьсяПровотМестныйс помощьюИвив 10.31.3.2.

Связанный контент