DMVPN с ответвлениями за NAT

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

Я разворачиваю DMVPN. Основная сложность заключается в том, что некоторые филиалы находятся за NAT, и они не могут передавать трафик напрямую друг к другу, поэтому требуется передавать его через хаб. Однако это не работает так, как ожидалось. Трафик все еще отправляется напрямую на другой филиал.

Топология состоит из одного облака и двух хабов. В тестовой лаборатории (GNS3) у меня четыре филиала: два из них имеют "прямой" доступ к филиалу (без трансляции адресов), а два других находятся за другим маршрутизатором, который выполняет NAT, каждый филиал имеет свой собственный (то есть нет двух филиалов за одним NAT).

Динамическая маршрутизация выполняется с использованием EIGRP, так как Cisco явно рекомендует это в последних документах, связанных с DMVPN, и говорит, что OSPF не подвергается чрезмерному тестированию. Тем не менее, я не уверен и мог бы использовать OSPF, если он может работать лучше.

(некоторые хосты показаны как отключенные на рисунке, этот рисунок сделан после того, как я провел все описанные тесты и анализ)

Соответствующие конфигурации:

hub1:

!
interface Tunnel0
 bandwidth 1000000
 ip address 10.100.255.253 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 65000
 no ip split-horizon eigrp 65000
 ip nhrp map multicast dynamic
 ip nhrp network-id 65000
 ip nhrp holdtime 300
 ip nhrp redirect
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
!
interface Ethernet0/0
 description internet.e0/0
 ip address 172.31.0.2 255.255.255.0
!
interface Ethernet0/3
 description service.e0/0
 ip address 10.100.200.253 255.255.255.240
 standby 1 ip 10.100.200.252
 standby 1 priority 110
 standby 1 preempt delay reload 60
 standby 1 name HSRP
!
router eigrp 65000
 network 10.100.200.176 0.0.0.15
 network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.0.1
!

hub2:

!
interface Tunnel0
 bandwidth 800000
 ip address 10.100.255.254 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 65000
 no ip split-horizon eigrp 65000
 ip nhrp map multicast dynamic
 ip nhrp map multicast 172.31.0.2
 ip nhrp map 10.100.255.253 172.31.0.2
 ip nhrp network-id 65000
 ip nhrp holdtime 300
 ip nhrp nhs 10.100.255.253
 ip nhrp shortcut
 ip nhrp redirect
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
!
interface Ethernet0/0
 description internet.e0/1
 ip address 172.31.0.3 255.255.255.0
!
interface Ethernet0/3
 description service.e0/1
 ip address 10.100.200.254 255.255.255.240
 standby 1 ip 10.100.200.252
 standby 1 preempt delay reload 60
 standby 1 name HSRP
!
router eigrp 65000
 network 10.100.200.240 0.0.0.15
 network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.0.1
!

spoke1 (прямой интернет):

!
interface Loopback0
 ip address 10.100.200.5 255.255.255.252
!
interface Tunnel0
 bandwidth 100000
 ip address 10.100.255.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 10.100.255.253 172.31.0.2
 ip nhrp map 10.100.255.254 172.31.0.3
 ip nhrp map multicast 172.31.0.2
 ip nhrp map multicast 172.31.0.3
 ip nhrp network-id 65000
 ip nhrp holdtime 300
 ip nhrp nhs 10.100.255.253
 ip nhrp nhs 10.100.255.254
 ip nhrp shortcut
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
!
interface Ethernet0/0
 description internet.e1/0
 ip address 172.31.1.2 255.255.255.0
!
router eigrp 65000
 network 10.100.200.4 0.0.0.3
 network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.1.1
!

spoke2 аналогичен 1, только адреса различаются. lo0 имеет 10.100.200.9/30.

spoke3 (за NAT):

!
interface Loopback0
 ip address 10.100.200.13 255.255.255.252
!
interface Tunnel0
 bandwidth 100000
 ip address 10.100.255.3 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 10.100.255.253 172.31.0.2
 ip nhrp map 10.100.255.254 172.31.0.3
 ip nhrp map multicast 172.31.0.3
 ip nhrp map multicast 172.31.0.2
 ip nhrp network-id 65000
 ip nhrp holdtime 300
 ip nhrp nhs 10.100.255.253
 ip nhrp nhs 10.100.255.254
 ip nhrp shortcut
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
!
interface Ethernet0/0
 description spoke3-gw.e0/3
 ip address 192.168.1.2 255.255.255.0
!
router eigrp 65000
 network 10.100.200.12 0.0.0.3
 network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!

spoke3-gw (тот, который делает NAT для spoke3):

!
interface Ethernet0/0
 description internet.e1/2
 ip address 172.31.3.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
!
interface Ethernet0/3
 description spoke3.e0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
ip nat inside source list 1 interface Ethernet0/0 overload
ip route 0.0.0.0 0.0.0.0 172.31.3.1
!
access-list 1 permit 192.168.1.0 0.0.0.255
!

spoke4 и spoke4-gw имеют аналогичную конфигурацию, lo0 имеет 10.100.200.17/30. "серые" адреса одинаковые 192.168.1.0/24. Cisco явно утверждает, что это допустимый случай и должен работать.

Интернет имеет все эти адреса 172.31.{0,1,2,3,4}.1 и просто пересылает пакеты между .2 и .0.3; сервис представляет собой систему, которая имеет адрес 10.100.200.241 и по умолчанию использует 10.100.200.252 (управляемый HSRP).

IPSEC не настроен. Я стараюсь делать всё постепенно, это слишком сложно пытаться сделать всё правильно с первого раза.

Я проводил тесты с командами типа "ping 10.100.200.13 source 10.100.200.17" (с spoke3 на spoke4) и так далее.

Это "кажется" работает. То есть, указанный ping работает. Но захват пакетов на линке "internet.e1/3 – spoke4-gw.e0/0" показал, что мы все еще имеем прямые пакеты от spoke3-gw к spoke4-gw и наоборот. Команда "show ip nhrp" на spoke3 и spoke4 показывает именно это (разрешено на "белый" адрес другого -gw). Проверка NAT с помощью команды "show ip nat translations" на шлюзах показала, что да, есть трансляция GRE с spoke3 на spoke4-gw на spoke3-gw (и аналогично на spoke4-gw). Вот почему указанный ping работает. Мне просто повезло в этой лаборатории, что Cisco делает NAT, который работает правильно.

В реальном мире NAT-устройствами могут быть любые устройства. Я не могу требовать использования какого-то конкретного оборудования (это незаконно). Я могу только требовать, чтобы оно корректно выполняло NAT для GRE к хабам и обратно (что является минимальным для запуска DMVPN).

Если я заблокирую прямой трафик между spoke3-gw и spoke4-gw (на интернет-системе, установив правила доступа, запрещающие трафик с 172.31.4.2 до 172.31.3.2 и обратно), я ожидаю, что система это увидит и будет пересылать всё между spoke3 и spoke4 через хаб. Тем не менее, это не работает.

Команда sh ip nhrp на spoke3 в этот раз показывает, что он не может разрешить 10.100.200.17:

10.100.200.12/30 via 10.100.255.3
   Tunnel0 created 00:00:39, expire 00:04:33
   Type: dynamic, Flags: router unique local 
   NBMA address: 192.168.1.2 
    (no-socket) 
10.100.200.17/32
   Tunnel0 created 00:00:39, expire 00:02:25
   Type: incomplete, Flags: negative 
   Cache hits: 2
10.100.255.3/32 via 10.100.255.3
   Tunnel0 created 00:01:34, expire 00:04:20
   Type: dynamic, Flags: router unique local 
   NBMA address: 192.168.1.2 
    (no-socket) 
10.100.255.4/32 via 10.100.255.4
   Tunnel0 created 00:00:39, expire 00:04:33
   Type: dynamic, Flags: router implicit used nhop 
   NBMA address: 172.31.4.2 
    (Claimed NBMA address: 192.168.1.2) 
10.100.255.253/32 via 10.100.255.253
   Tunnel0 created 03:24:10, never expire 
   Type: static, Flags: used 
   NBMA address: 172.31.0.2 
10.100.255.254/32 via 10.100.255.254
   Tunnel0 created 03:24:10, never expire 
   Type: static, Flags: used 
   NBMA address: 172.31.0.3 

Почему в этом случае пакеты не направляются через хаб? Этот путь всё равно открыт.

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

DMVPN с подсистемами за NAT: Решение проблемы

Введение

Развертывание DMVPN (Dynamic Multipoint Virtual Private Network) представляет собой сложную задачу, особенно когда части сети располагаются за NAT (Network Address Translation). В частности, в вашем сценарии существует основная проблема: подсистемы, находящиеся за NAT, не могут обмениваться трафиком напрямую. Все сообщения должны проходить через основную узловую точку (hub). В этом ответе мы будем рассматривать конфигурацию DMVPN и предложения по её оптимизации, чтобы решить проблему взаимодействия между узловыми точками, находящимися за NAT.

Обзор конфигурации DMVPN

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

Проблемы с конфигурацией

Ваша текущая конфигурация использует следующие параметры:

• Указание маршрутов на хабах через ip next-hop-self eigrp.
• Применение ip nhrp redirect и ip nhrp shortcut на хабах и подсистемах, которые могут приводить к неправильному маршрутизации между подсистемами.

По умолчанию, DMVPN фазу II предполагает прямое соединение между подсистемами. Когда эти подсистемы находятся за NAT, это соединение не будет установлено, и трафик должен передаваться через хаб. Включение ip nhrp shortcut может приводить к ситуации, когда системы, не знакомые с NAT, пытаются обойти хаб, устанавливая соединение напрямую.

Рекомендованная конфигурация

Чтобы изменить поведение вашей сети на DMVPN фазу I, которая подразумевает маршрутизацию трафика только через хаб, выполните следующие изменения в конфигурации:

Хаб 1

interface Tunnel0
 ip next-hop-self eigrp 65000
 no ip nhrp redirect

Хаб 2

interface Tunnel0
 ip next-hop-self eigrp 65000
 no ip nhrp shortcut
 no ip nhrp redirect

Спokes (Спутники)

Для всех подсистем, которые находятся в вашей конфигурации:

interface Tunnel0
 no ip nhrp shortcut

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

Проверка конфигурации

После внесения изменений выполните следующие проверки:

1. Команда show ip nhrp: Убедитесь, что все подсистемы видят адреса через хаб, и для всех маршрутов показана верная информация о полученных и отправленных пакетах.

2. Логи NAT: Проверьте, что NAT на шлюзах правильно обрабатывает GRE-трафик, чтобы любое сообщение от одной подсистемы передавалось через хаб, а не напрямую.

3. Тестирование: Осуществите пинг и другие проверки связности между подстанциями. Убедитесь, что ненаблюдаемый или некорректный трафик не вызывает падения связи.

Заключение

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

Удачи в развертывании вашей DMVPN и не забывайте о тщательном тестировании после внесения изменений!