NAT + tunnel GRE typu unnumbered

Problemy związane z routingiem
Wiadomość
Autor
-Tomek-
wannabe
wannabe
Posty: 83
Rejestracja: 22 mar 2010, 12:11

NAT + tunnel GRE typu unnumbered

#1

#1 Post autor: -Tomek- »

Witam,

Testuję na GNS (na bazie c3745-advipservicesk9-mz.124-25) mechanizm NAT-a w następującej konfiguracji:
interface Loopback0
ip address 10.5.5.1 255.255.255.255
ip virtual-reassembly
!
interface Tunnel1
ip unnumbered Loopback0
ip nat outside
ip pim sparse-dense-mode
keepalive 5 5
tunnel source FastEthernet0/1
tunnel destination 10.5.7.1
!
interface Tunnel2
ip unnumbered Loopback0
ip nat outside
ip pim sparse-dense-mode
keepalive 5 5
tunnel source FastEthernet0/1
tunnel destination 10.5.8.1
!
interface Tunnel3
ip unnumbered Loopback0
ip nat outside
ip pim sparse-dense-mode
keepalive 5 5
tunnel source FastEthernet0/1
tunnel destination 10.5.9.1
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip pim sparse-dense-mode
ip nat inside
!
interface FastEthernet0/1
ip address 10.5.20.1 255.255.255.252
!
router eigrp 1
passive-interface Loopback0
network 10.5.5.1 0.0.0.0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.5.20.2
!
!
ip pim autorp listener
ip nat inside source list 1 interface Loopback0 overload
!
access-list 1 permit 192.168.1.0 0.0.0.255

W pierwszym podejściu chciałbym NAT-ować cały ruch wychodzący z FastEthernet0/0 (192.168.1.0/24) w stronę dowolnego tunelu.
Niestety przy klasycznej konfiguracji nie udało mi się zaobserwować działania NATa - tzn. IP nadawcy pozostawało niezmienione (192.168.1.0/24).

Dodam, że robiłem też testy z tylko jednym tunelem i wpisem "ip nat inside source list 1 interface tunnel1 overload" oraz dodawałem "ip nat outside" do loopback0, niestety nic nie pomagało.

Zastanawiam się, czy popełniłem jakiś błąd, czy to raczej ograniczenie tego, że tunel ma adres typu unnumbered?

ms
wannabe
wannabe
Posty: 112
Rejestracja: 22 kwie 2009, 12:54
Kontakt:

Re: NAT + tunnel GRE typu unnumbered

#2

#2 Post autor: ms »

Cześć,
Potwierdzam, że NAT i 'ip unnumbered' generalnie nie działa. Ale zasadnicze pytanie dlaczego stosujesz 'ip unnumbered', a nie dowolną adresacja prywatną, choćby nawet nie miała być nigdzie później rozgłaszana?

Jeśli z jakiegoś powodu potrzebujesz jednak 'ip unnumbered' i NAT, to możesz to rozwiązać tak, że NATował będziesz na interfejs loopback0 (a nie na tunnel0), ale żeby to zadziałało ruch musi "chcieć wyjść" przez loopback0, co z kolei osiągniesz PBRem na interfejsie Fa0/0. Czyli:
Fa0/0 to inside,
loopback0 to outside,
PBR na Fa0/0 kieruje ruch na loopback0,
Ruch przychodzący Fa0/0 i wychodzący loopback0 jest NATowany na adres loopback0,
Następnie ruch zawija się na loopback0 i jest już routowany tak, jak mówi tablica routingu przez tunnel0


Pozdrawiam,

-Tomek-
wannabe
wannabe
Posty: 83
Rejestracja: 22 mar 2010, 12:11

Re: NAT + tunnel GRE typu unnumbered

#3

#3 Post autor: -Tomek- »

Więc tak...
Ogólnie to jednak NAT działa w tej konfiguracji co podałem, ale dopiero po restarcie routera.
Nie wiem jeszcze, czy to bug GNSa, czy raczej IOSa - sprawdzę później na realnym sprzęcie.

Jeżeli chodzi o zastosowanie w tym rozwiązaniu interfejsów typu unnumbered, to było to, podyktowane m.in. maksymalnym uproszczeniem konfiguracji tuneli. Dana sieć jest dosyć mobilna lub zestawiana adhoc, dlatego w tym rozwiązaniu jedynym zmiennym parametrem jest adres 'tunnel destination', a pozostała konfiguracja każdego z tuneli jest stała.

Zainteresowałem się też rozwiązaniem z PBR.

Przeniosłem 'ip nat outside" z tuneli na loopback0.

dodałem route-map i dopisałem ją do Fa0/0 (ip policy route-map NAT-Forward)
route-map NAT-Forward permit 10
match ip address 1
set interface Loopback0
Efekt jest taki, że NAT niby działa, bo ruch na zewnątrz wychodzi z podmienionym adresem nadawcy (na loopback), ale pakiet zwrotny (np. ping reply) już nie dociera do inicjatora. Wygląda, jakby nie obsługiwała go reguła powrotna NATa.

ms
wannabe
wannabe
Posty: 112
Rejestracja: 22 kwie 2009, 12:54
Kontakt:

Re: NAT + tunnel GRE typu unnumbered

#4

#4 Post autor: ms »

Przyznaje, że powyższe pisałem z głowy, bo nie sprawdzałem tego teraz, a po prostu kiedyś w ten sposób obchodziłem problem NATa na interfejsie, gdzie było 'unnumbered', bo też mi nie chciało działać. Jeśli masz to jeszcze złożone/skonfigurowane to możesz sprawdzić czy pomoże dopisanie 'ip nat outside' na interfejsie tunnel, aby pakiet powrotny wszedł interfejsem outside i wyszedł inside.


Pozdr.

-Tomek-
wannabe
wannabe
Posty: 83
Rejestracja: 22 mar 2010, 12:11

Re: NAT + tunnel GRE typu unnumbered

#5

#5 Post autor: -Tomek- »

Rzeczywiście dopisanie "ip nat outside" na tunelu pomogło, ale na razie wróciłem do pierwotnego rozwiązania (bez PBR) skoro jakoś ono działa.

Zmodyfikowałem nieco topologię sieci i pojawił mi się kolejny problem do rozwiązania.
Do routera obsługującego LAN (nat inside) dołączyłem równolegle drugi router i wprowadziłem następujące zmiany:

- dodałem static NATa na jeden z hostów w LAN (192.168.1.10), który ma być widoczny w WANie pod adresem loopback1 (10.5.6.1), uruchomiłem też EIGRP na tym interfejsie, aby był rozgłaszany.

- uruchomiłem też EIGRP na LANie, aby oba routery "widziały się", oczywiście dodałem filtr (PRIV_FILTER), by sieć prywatna (192.168.1.0/24) nie była rozgłaszana

i ich konfiguracja wygląda następująco (podkreśliłem różnice):

Router R1
interface Loopback0
ip address 10.5.5.2 255.255.255.255
!
interface Loopback1
ip address 10.5.6.1 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
ip nat outside
ip pim sparse-dense-mode
keepalive 5 5
tunnel source FastEthernet0/1
tunnel destination 10.5.8.1
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip pim sparse-dense-mode
ip nat inside
!
interface FastEthernet0/1
ip address 10.5.20.1 255.255.255.252
!
router eigrp 1
passive-interface Loopback0
network 10.5.5.0 0.0.0.255
network 10.5.6.0 0.0.0.255
network 192.168.1.0 0.0.0.255
distribute-list PRIV_FILTER out
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.5.20.2
!
!
ip pim autorp listener
ip nat inside source list 1 interface Loopback0 overload
ip nat inside source static 192.168.1.10 interface Loopback1
!
ip access-list standard PRIV_FILTER
deny 192.168.1.0 0.0.0.255
permit any
!
access-list 1 permit 192.168.1.0 0.0.0.255

Router R2
interface Loopback0
ip address 10.5.5.2 255.255.255.255
!
interface Loopback1
ip address 10.5.6.1 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
ip nat outside
ip pim sparse-dense-mode
keepalive 5 5
tunnel source FastEthernet0/1
tunnel destination 10.5.11.1
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
ip pim sparse-dense-mode
ip nat inside
!
interface FastEthernet0/1
ip address 10.5.22.1 255.255.255.252
!
router eigrp 1
passive-interface Loopback0
network 10.5.5.0 0.0.0.255
network 10.5.6.0 0.0.0.255
network 192.168.1.0 0.0.0.255
distribute-list PRIV_FILTER out
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.5.22.2
!
!
ip pim autorp listener
ip nat inside source list 1 interface Loopback0 overload
ip nat inside source static 192.168.1.10 interface Loopback1
!
ip access-list standard PRIV_FILTER
deny 192.168.1.0 0.0.0.255
permit any
!
access-list 1 permit 192.168.1.0 0.0.0.255
Chciałbym, aby publiczny adres 10.5.6.1 (inside global) statycznie NATowanego hosta (192.168.1.10) był dostępny w WANie nie zależnie od tego, czy działają oba routery, czy tylko jeden z nich.
Tymczasowo wymyśliłem, że oba routery mają ten sam adres loopback1 i oba jednocześnie go rozgłaszają, tylko zastanawiam się, czy to rozwiązanie nie ma jakiś efektów ubocznych.
Może jest jakiś inny, bardziej elegancki sposób?

Rozwiązanie powinno być łatwo skalowalne, czyli zakładam możliwość, że do LANu mogą być podpięte równolegle więcej niż 2 routery.

ms
wannabe
wannabe
Posty: 112
Rejestracja: 22 kwie 2009, 12:54
Kontakt:

Re: NAT + tunnel GRE typu unnumbered

#6

#6 Post autor: ms »

IMO jest (raczej :)) ok. Ewentualnie może Ci się w sieci pojawić routing asymetryczny a widzę, że korzystasz z multicastów, co czasami może sprawiać problemy (RPF fialure). Także tej sprawie bym się przyglądnął.

To, że 2 routery rozgłaszają tą samą sieć/adres przecież co do zasady nie jest złe. Ale może ktoś coś jeszcze doradzi.

Pozdr.

-Tomek-
wannabe
wannabe
Posty: 83
Rejestracja: 22 mar 2010, 12:11

Re: NAT + tunnel GRE typu unnumbered

#7

#7 Post autor: -Tomek- »

W trakcie testów wykryłem niedoskonałość powyższego rozwiązania, która ujawniła się m.in. dla multicastów.

Router R2 staje się PIM DR w LAN, a z kolei PIM RP jest dostępny przez R1 (via tunnel1).
W takim wypadku, pakiety multicastowe generowane przez kompa w LAN, odebrane przez R2 i forwardowane (jako PIM register) przez LAN do R1, nie są prawidłowo NATowane i nie docierają do PIM RP.

Rozwiązaniem było stworzenie dodatkowego subinterfejsu na LANie, który byłyby używany do NATowania ruchu oraz przy okazji do zestawiania sąsiedztwa EIGRP.
Jak już pisałem wcześniej, priorytetem było stworzenie rozwiązania szablonowego (łatwego do powielania) i bez konieczności wprowadzania dodatkowej adresacji IP.

Wprowadzone zmiany (w stosunku do w/w konfiguracji) są następujące:

- usuwamy EIGRP z LANu (z interfejsu fizycznego) - no network 192.168.1.0 0.0.0.255
- w każdym z routerów tworzymy nowy subinterfejs na interfejsie fizycznym LAN - np. VLAN 10 z adresem typu unnumbered oraz z uruchomionym PIM oraz NATem:
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip unnumbered Loopback0
ip pim sparse-dense-mode
ip nat outside
Niestety, aby w pełni zestawiło się sąsiedztwo pomiędzy EIGRP, należy jeszcze dopisać statica do wszystkich możliwych sąsiadów w LAN
ip route 10.5.5.0 255.255.255.248 FastEthernet 0/0.10
Po wprowadzeniu tych zmian, multicasty w końcu zaczęły przechodzić. :)
Spróbuję jeszcze nieco skomplikować topologię, by sprawdzić, czy nie wyjdą jakieś inne efekty uboczne (m.in. asymetryczny routing).
Gdyby ktoś miał jakieś uwagi, to chętnie poczytam.

ODPOWIEDZ