Маршрутизация через NAT и VPN

Вопрос или проблема

Я думаю, я близок к решению, но не уверен, как дальше отлаживать. Моя настройка выглядит так:

10.241.1.11 — (LAN) — 10.241.1.9/10.8.0.2 — (VPN) — 10.8.0.1

Я хочу иметь возможность подключиться к 10.8.0.1 с 10.241.1.11. Это в IBM cloud, и две стороны VPN находятся в разных VPC, так что с каждой стороны VPN также есть маршрутизатор, контролируемый облачным провайдером.

Вывод tcpdump выглядит хорошо, как я считаю? Это с 10.241.1.9, когда выполняется ping 10.8.0.1 с 10.241.1.11:

[10.241.1.9]# tcpdump -n -i any not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
18:59:14.903255 IP 10.241.1.11 > 10.8.0.1: ICMP echo request, id 19, seq 1, length 64
18:59:14.903313 IP 10.8.0.2 > 10.8.0.1: ICMP echo request, id 19, seq 1, length 64
18:59:14.903374 IP 10.241.1.9.45254 > [10.8.0.1's public IP].1194: UDP, length 108
18:59:14.904159 IP [10.8.0.1's public IP].1194 > 10.241.1.9.45254: UDP, length 108
18:59:14.904218 IP 10.8.0.1 > 10.8.0.2: ICMP echo reply, id 19, seq 1, length 64
18:59:14.904243 IP 10.8.0.1 > 10.241.1.11: ICMP echo reply, id 19, seq 1, length 64

Выглядит так, что 10.241.1.9 получает ICMP-запрос от 10.241.1.11, пересылает его на 10.8.0.1 через VPN, затем отправляет ICMP-ответ обратно на 10.241.1.11. Но 10.241.1.11 никогда не получает ответ.

Информация о интерфейсах/маршрутизации/iptables:

[10.241.1.11]# ip ro
default via 10.241.1.1 dev eth0
default via 10.241.1.1 dev eth0 proto dhcp src 10.241.1.11 metric 100
10.8.0.0/24 via 10.241.1.9 dev eth0
10.241.1.0/24 dev eth0 proto kernel scope link src 10.241.1.11
10.241.1.0/24 dev eth0 proto kernel scope link src 10.241.1.11 metric 100

[10.241.1.9]# ip -4 -o a
1: lo    inet 127.0.0.1/8 scope host lo ...
2: ens3    inet 10.241.1.9/24 brd 10.241.1.255 scope global dynamic ens3 ...
3: tun0    inet 10.8.0.2/24 brd 10.8.0.255 scope global tun0 ...

[10.241.1.9]# iptables -t nat -L
 sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             10.8.0.0/24

[10.241.1.9]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             10.8.0.0/24
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ответ или решение

Безопасное и стабильное соединение между сетями в облачных средах, таких как IBM Cloud, требует точной настройки маршрутизации, использования NAT и VPN. При решении вашей задачи критическими аспектами, которые необходимо учитывать, являются маршрутизация пакетов и управление трафиком через VPN.

Ваш текущий сценарий предполагает, что устройство с адресом 10.241.1.11 должно подключаться к 10.8.0.1 через промежуточный сервер 10.241.1.9, который также является точкой выхода в VPN. Ваши команды tcpdump показывают, что ICMP-запрос от 10.241.1.11 корректно передается через 10.8.0.2 к целевому адресу 10.8.0.1 и возвращается как ответ ICMP обратно на 10.241.1.9. Однако ключевая проблема заключается в том, что 10.241.1.11 не получает ICMP-ответ, что может быть вызвано ошибками в маршрутизации или правилах Firewall.

Возможные причины и решения:

Ошибки Маршрутизации:
Убедитесь, что маршрутизация настроена правильно. Согласно предоставленным данным, маршрут от 10.241.1.11 через 10.241.1.9 к сети 10.8.0.0/24 существует. Убедитесь, что этот маршрут действительно используется и трафик корректно возвращается к 10.241.1.11. Проверьте конфигурацию роутеров VPC обоих облачных сред на корректность настройки маршрутов.
Настройка Iptables:
Проверьте правила iptables на обоих устройствах (10.241.1.9 и 10.8.0.2) для получения ICMP-пакетов. Обратите внимание на цепочку FORWARD на 10.241.1.9: политика ‘ACCEPT’ должна обеспечивать прохождение трафика. Убедитесь, что правила для NAT и форвардинга ICMP отвечают требованиям: рекомендуется проверка/добавление явных правил (например, ACCEPT icmp --anywhere to any) для подтверждения того, что ICMP-ответы не блокируются.
Настройка NAT:
Проверьте, правильно ли настроен механизм NAT. Ваш текущий NAT работает для преобразования исходящих пакетов из сети 10.8.0.0/24, но убедитесь, что для обратных пакетов настройка также верна.
VPN Конфигурация:
Проверьте настройку VPN-сервера и клиента, убедитесь в справедливой обработке возврата трафика и отсутствии конфликтов в конфигурации маскирования адреса или политики управления трафиком.
Диагностика сети:
Используйте утилиты traceroute или mtr с обоих концов (из обеих VPC) для отладки и выявления возможных узких мест в передаче пакетов. Эти инструменты помогут определить, где именно останавливается трафик пересылки.

Проверка всех вышеперечисленных компонентов должна помочь изолировать проблему и восстановить корректную маршрутизацию ICMP-пакетов. Ваша ситуация уникальна из-за участия двух облачных сред, и на каждом этапе стоит учитывать детали конфигурации роутеров VPC, чтобы гарантировать, что все маршруты и NAT согласуются между собой.