CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 18 gru 2017, 00:19

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 7 ] 
Autor Wiadomość
Post #1 : 15 wrz 2017, 10:53 
Offline
wannabe
wannabe

Rejestracja: 22 mar 2010, 12:11
Posty: 64
Witam,

Testuję na GNS (na bazie c3745-advipservicesk9-mz.124-25) mechanizm NAT-a w następującej konfiguracji:
Cytuj:
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?


Na górę
Post #2 : 19 wrz 2017, 08:18 
Offline
wannabe
wannabe

Rejestracja: 22 kwie 2009, 12:54
Posty: 90
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,

_________________
PROIDEA - najbliższe szkolenia


Na górę
Post #3 : 19 wrz 2017, 12:37 
Offline
wannabe
wannabe

Rejestracja: 22 mar 2010, 12:11
Posty: 64
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)
Cytuj:
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.


Na górę
Post #4 : 19 wrz 2017, 15:38 
Offline
wannabe
wannabe

Rejestracja: 22 kwie 2009, 12:54
Posty: 90
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.

_________________
PROIDEA - najbliższe szkolenia


Na górę
Post #5 : 21 wrz 2017, 10:57 
Offline
wannabe
wannabe

Rejestracja: 22 mar 2010, 12:11
Posty: 64
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
Cytuj:
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
Cytuj:
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.


Na górę
Post #6 : 24 wrz 2017, 20:37 
Offline
wannabe
wannabe

Rejestracja: 22 kwie 2009, 12:54
Posty: 90
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.

_________________
PROIDEA - najbliższe szkolenia


Na górę
Post #7 : 29 wrz 2017, 16:26 
Offline
wannabe
wannabe

Rejestracja: 22 mar 2010, 12:11
Posty: 64
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:
Cytuj:
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
Cytuj:
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.


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 7 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Yahoo [Bot] i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl