У меня проблема с маршрутизацией.
У меня есть 2 публичные подсети: 172.31.1.0/24 и 172.31.100.0/24
В каждом из них у меня есть экземпляр NAT. Каждый экземпляр NAT является одноранговым узлом OpenSwan VPN в удаленном месте. Это обеспечивает следующие возможности подключения к VPN:
172.31.1.0/24 -> 192.168.1.0/24
172.31.100.0/24 -> 192.168.100.0/24
Я установил одну таблицу маршрутов, связанную с обеими общедоступными подсетями. сюда входят следующие записи маршрута:
192.168.1.0/24 Target = NAT instance 1
192.168.100.0/24 Target = NAT instance 2
Для первого все работает нормально, но что бы я ни делал, запись в таблице маршрутов для второго не работает.
Ни один маршрут, который я установил для экземпляра NAT 2, не работает. Когда я отслеживаю маршрут до любого адреса в 192.168.100.0/24, пакеты отправляются напрямую на 192.168.100.0/24 (и поэтому терпят неудачу), а не маршрутизируются через NAT Instance 2.
Я подумал, что, возможно, существует ограничение на количество одновременных экземпляров NAT в таблице маршрутов, но даже когда я удаляю маршрут до 192.168.1.0, так что единственный существующий маршрут - это маршрут через экземпляр NAT 2, он все равно не т работать.
Я проверил все обычные вещи (проверка Src / Dst и т. Д.), Но, похоже, все в порядке. Все это было создано с помощью CloudFormation, поэтому ручная ошибка маловероятна.
Решение этого вопроса было довольно простым, но оно вызывает интересное наблюдение. использование traceroute для устранения проблем маршрутизации.
Источником проблемы было то, что я не включил переадресацию IP ни на одном хосте, кроме Nat Instance 1.
т.е.
echo 1 > /proc/sys/net/ipv4/ip_forward
Когда я занимался отладкой, я использовал команду traceroute, например
traceroute 192.168.100.1
Когда переадресация ip не была включена в экземпляре Nat 2, это давало следующий ответ:
[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
Когда я включил IP-переадресацию в Nat Instance 2, ответ изменился:
[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1 ip-172-31-100-102.ap-southeast-1.compute.internal (172.31.100.102) 0.528 ms 0.505 ms 0.491 ms
(172.31.100.102 = Натуральный экземпляр 2)
Это говорит о том, что хотя traceroute может знать конкретный маршрут к определенной сети, он будет сообщать только о попытке следовать по этому маршруту, если маршрутизация разрешена на шлюзе по умолчанию для этого маршрута.
В противном случае он попытается следовать маршруту по умолчанию и сообщит об успехе или неудаче только для маршрута по умолчанию. Я уверен, что это согласуется с дизайном traceroute, но, вероятно, сигналы о том, что traceroute может быть не лучшим инструментом для отладки проблем маршрутизации (это больше инструмент для отладки сетевых проблем).