Вопросы Теги

Ipsec VPN to AWS:Не удается пропинговать конец AWS внутри туннеля

Резюме:Я думаю, что мне не хватает некоторых маршрутов на моем сервере Ubuntu, подключающемся к AWS VPN с помощью Strongswan Ipsec. Есть идеи, какие маршруты мне нужны на моем сервере?

Я пытаюсь настроить VPN с маршрутизацией BGP с сервера на AWS. У меня это работало со статически маршрутизируемой VPN, поэтому я знаю, что моя сторона AWS-и ipsec верны. Однако BGP оказывается сложным.

Я использую Strongswan на Ubuntu в качестве «клиентской» стороны. Мои туннели ipsec работают (, что подтверждается ipsec statusи в консоли AWS). Проблема заключается в том, что мой клиент BGP (frr)не может подключиться к процессу BGP в AWS (и наоборот-наоборот).

Взяв один из двух туннелей, ip aвыглядит так:

5: tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 1.2.3.4 peer 2.3.4.5
    inet 169.254.10.146 peer 169.254.10.145/30 scope global tunnel1
       valid_lft forever preferred_lft forever

Интерфейс создан с помощью скрипта, называемого Strongswan, который выглядит так:

ip tunnel add ${VTI_INTERFACE} local ${PLUTO_ME} remote ${PLUTO_PEER} mode vti key ${PLUTO_MARK_IN_ARR[0]}
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.disable_policy=1
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=2 || sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=0
ip addr add ${VTI_LOCALADDR} remote ${VTI_REMOTEADDR} dev ${VTI_INTERFACE}
ip link set ${VTI_INTERFACE} up mtu ${MTU}
iptables -t mangle -I FORWARD -o ${VTI_INTERFACE} -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -I INPUT -p esp -s ${PLUTO_PEER} -d ${PLUTO_ME} -j MARK --set-xmark ${PLUTO_MARK_IN}

У меня есть такой маршрут:

169.254.10.144/30 dev tunnel1 proto kernel scope link src 169.254.10.146

Я могу пропинговать свой локальный (клиент)конец (169.254.10.146), но проверка связи с удаленным концом говорит:

PING 169.254.10.145 (169.254.10.145) 56(84) bytes of data.
From 169.254.10.146 icmp_seq=1 Destination Host Unreachable

Несмотря на то, что он недоступен, я вижу пакет на туннельном интерфейсе, хотя не похоже, что это фактически отправлены по туннелю в AWS (, по крайней мере, статистика AWS Cloudwatch не показывает дополнительной активности).

Одним из шагов отладки BGP является попытка «телнета» к соседу (169.254.10.145)через порт 179 -, но это не удается с «нет маршрута к хосту». Любопытно, однако, что я вижу, как AWS пытается подключиться к моему BGP-клиенту в tcpdump на туннельном интерфейсе :

12:49:45.860899 IP 169.254.10.145.43731 > 169.254.10.146.179: Flags [S], seq 857645259, win 26880, options [mss 1375,sackOK,TS val 3261400514 ecr 0,nop,wscale 7], length 0
12:49:45.860931 IP 169.254.10.146.179 > 169.254.10.145.43731: Flags [S.], seq 2284055933, ack 857645260, win 64249, options [mss 1379,sackOK,TS val 936428713 ecr 3261400514,nop,wscale 7], length 0

. Похоже, мой сервер возвращает пакет ACK, но соединение так и не установлено. Если я остановлю службу BGP, мы начнем отправлять ответы RST :

12:52:02.055473 IP 169.254.10.145.43679 > 169.254.10.146.179: Flags [S], seq 2280717367, win 26880, options [mss 1375,sackOK,TS val 3261536708 ecr 0,nop,wscale 7], length 0
12:52:02.055498 IP 169.254.10.146.179 > 169.254.10.145.43679: Flags [R.], seq 0, ack 1, win 0, length 0

. Исходя из этого, я предполагаю, что пакет ACK ядра и мой пакет ping отправляются на туннельный интерфейс,но на самом деле не входят в ipsec или идут в AWS.

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

1
задан 30 September 2021 в 13:27
1 ответ

Оказывается, решение — дополнительная политика xfrm. Идея, стоящая за этим, заключается в том, что, пока пакеты попадают на интерфейс, трафик не «подхватывается» ipsec. Для решения проблемы, кажется, нам нужно пометить пакеты (так же, как мы это делаем в конфиге ipsec и iptables ), а также специально «активировать» xfrm политикой. В моем случае это было так:

ip xfrm policy add dst 169.254.10.144/30 src 169.254.10.144/30 dir out tmpl src 1.2.3.4 dst 2.3.4.5 proto esp spi 0xc0f93fba reqid 1 mode tunnel mark 0x64

Это делает политику, которая выглядит вот так:

src 169.254.10.144/30 dst 169.254.10.144/30
    dir out priority 0
    mark 0x64/0xffffffff
    tmpl src 1.2.3.4 dst 2.3.4.5
        proto esp spi 0xc0f93fba reqid 1 mode tunnel

Это содержит некоторую магию, которую, кажется, мы должны получить от существующей политики. Во-первых, это «число spi». Это устанавливается Strongswan, и я не думаю, что это предсказуемо и недоступно в среде, переданной в ipsec-vti.sh. Вместо этого вам нужно выполнить команду grep и awk, чтобы извлечь его из вывода ip xfrm policy. Точно так жеreqid-этот набор с 1 для первого интерфейса и 2 для второго, который создается -, к сожалению, туннель1 не всегда является первым, поэтому вам также нужно будет извлечь это число.

0
ответ дан 4 October 2021 в 20:02

Теги

Похожие вопросы