DMVPN со спицами за NAT

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

Топология - одно облако, двойной концентратор. В тестовой лаборатории (GNS3) у меня четыре луча: два из них имеют «прямой» доступ к луче (без трансляции адресов), а два других находятся за другим роутером, который выполняет 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
!

Speak1 (прямой Интернет):

!
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

Speak3 (за 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
!

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

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

IPSEC не настроен. Я стараюсь делать что-то постепенно, мне сложно делать все сразу с первого кадра.

Я проводил тесты с такими командами, как «ping 10.100.200.13, источник 10.100.200.17» (от Spoke3 к Spoke4) и так далее.

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

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

Если я заблокирую прямой трафик между спицами 3-gw и спицами 4-gw (в интернет-системе, установив правила доступа, запрещающие с 172.31.4.2 до 172.31.3.2 и наоборот), я ожидаю, что система увидит это и переадресует все между спицами 3 и 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 

Почему в этом случае он не направляет пакеты через концентратор? Этот путь еще открыт.