Który interfejs dostaje rolę NAT wewnątrz i na zewnątrz na wyjściu IOS VPN
Prześledź odszyfrowany pakiet klienta od interfejsu wirtualnego do łącza nadrzędnego. Translacja należy do tego wewnętrznego przepływu, a nie do zewnętrznego transportu tunelu.
Routery zapewniające wyjście do internetu przez pełny tunel wykonują dwie czynności, które wyglądają jak jedna. Kończy tunel i przekazuje odszyfrowany pakiet klienta do internetu. Translacji wymaga tylko druga czynność, a translacja musi odpowiadać przepływowi wewnętrznemu. To rozróżnienie decyduje, które interfejsy pełnią role NAT i jaki zakres adresów występuje w regule.
Prześledź jeden pakiet przez router
Weź klienta pod adresem 10.90.0.25, który otwiera publiczną usługę HTTPS. Czy ten cel w ogóle wchodzi do tunelu, jest decyzją polityki samego klienta. Gdy wchodzi, router odszyfrowuje pakiet i dostarcza go do interfejsu wirtualnego, skąd jest trasowany do publicznego łącza nadrzędnego.
Ten interfejs wirtualny to wewnętrzna strona translacji. Publiczne łącze nadrzędne to strona zewnętrzna. Jeśli role są odwrócone lub ich brakuje, pakiet albo wychodzi z prywatnym źródłem, albo jest odrzucany przed translacją.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
Dopasuj politykę translacji do puli klientów
Reguła NAT musi wskazywać zakres, który klienci faktycznie otrzymują, a nie biurowy LAN, który akurat dzieli łącze nadrzędne. Reguła obejmująca tylko lokalną podsieć pomija klientów zdalnych, nawet gdy oba wychodzą przez ten sam interfejs.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadWyjątki dla witryn prywatnych trzymaj osobno. Ruch do celów wewnętrznych musi zachować swoje pierwotne źródło, inaczej cel odpowie na adres, do którego nie może dotrzeć, a odnoga powrotna zawiedzie w sposób przypominający pętlę routingu.
Zastosuj role do rzeczywistych interfejsów we wdrożonym projekcie. Fragment Virtual-Template skopiowany ze starej odpowiedzi Easy VPN nie jest pełną bieżącą konfiguracją, a używany typ tunelu decyduje, który interfejs odbiera odszyfrowany pakiet.
Trzymaj zewnętrzny transport i wewnętrzną translację osobno
Translacja odszyfrowanego źródła aplikacji to nie ta sama operacja co przepychanie pakietów IKE lub chronionych przez urządzenie NAT powyżej. Pierwsza zmienia to, co internet widzi jako źródło żądania klienta; druga utrzymuje tunel przy życiu przez urządzenie pośredniczące.
Pomieszanie ich daje dwa klasyczne błędy. Router, który transluje własny transport tunelu, psuje relację z peerem, natomiast router, który nigdy nie transluje przepływu wewnętrznego, wysyła prywatne adresy do internetu. Przeczytaj, na który przepływ patrzysz, zanim edytujesz regułę, i sprawdź, czy tunel pozostał podniesiony po zmianie. Reguła, która naprawia przeglądanie, ale obala tunel, przeniosła problem zamiast go rozwiązać.
Żadnego z błędów nie naprawia się zmianą drugiego. Przeczytaj, na który przepływ patrzysz, zanim edytujesz regułę.
Sprawdź na obu granicach
Odczytaj źródło aplikacji na granicy internetu i przywrócony cel na odnodze powrotnej. Pierwsze mówi, czy translacja nastąpiła; drugie mówi, czy odwrotne mapowanie wróciło do właściwego klienta.
Następnie przetestuj klienta korzystającego z zatwierdzonej ścieżki tunelu dzielonego. Ten klient nigdy nie korzysta z translacji internetowej tego routera, więc powinien zachowywać się inaczej, a różnica potwierdza, którą ścieżką poszedł ruch.
Jeśli obaj klienci zachowują się identycznie, polityka tunelu dzielonego nie robi tego, co zakłada projekt. Napraw to, zanim dodasz kolejne reguły translacji, ponieważ reguła napisana dla nieużywanej ścieżki ukrywa prawdziwy problem.