ASA VPN hairpin: routing dwóch tuneli przez jedno interfejs

Ruch użytkownika zdalnego może opuścić ten sam interfejs ASA, przez który przyszedł, ale zezwolenie hairpin, zakres tunelu, NAT i listy ACL to cztery odrębne decyzje.

Użytkownik zdalny łączy się z ASA, prosi o host za oddziałem, a ASA wysyła to żądanie przez dokładnie ten interfejs, przez który przyszedł użytkownik. Nic z tego nie wymaga drugiego fizycznego portu. Wymaga natomiast czterech niezależnych decyzji, które ludzie mają zwyczaj zlewać w jedną: zezwolenia na hairpin, tunelu chroniącego właściwe adresy, polityki NAT zachowującej obiecane źródło oraz polityki dostępu, która autoryzuje usługę.

Jeden pakiet, dwa tunele

Prześledź przepływ, a kolejność operacji przestaje być tajemnicza. Pakiet przychodzi wewnątrz tunelu dostępu zdalnego, zostaje odszyfrowany i staje się zwykłym pakietem IP ze źródłem z puli klientów. Następnie ASA kieruje go, dopasowuje do crypto ACL od oddziału do oddziału, szyfruje ponownie i wysyła przez interfejs zewnętrzny w stronę oddziału.

Adresy poniżej są przykładowe, ale kształt ma znaczenie: źródłem jest pula, a nie wewnętrzna sieć LAN ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Wynikają z tego dwie rzeczy. Klient potrzebuje trasy do prefiksu oddziału przez swoje połączenie dostępu zdalnego, co oznacza, że split-tunnel lub wysyłana lista tras musi go zawierać. A oddział musi wiedzieć, jak zwracać ruch na adres 10.77.0.20 lub na adres, który zastąpił projekt NAT.

Zezwolenie na hairpin jest globalne

Polecenie, po które sięgają ludzie, to same-security-traffic permit intra-interface. Pozwala ruchowi wchodzić i wychodzić przez ten sam interfejs, co jest dokładnie tym, czego potrzebuje ta ścieżka. Jest to również ustawienie globalne: włączenie go zmienia zachowanie innych przepływów, które przypadkiem przechodzą dwa razy przez ten sam interfejs.

Dlatego należy ono do rejestru zmian, a nie do sesji debugowania. Zapytaj, co jeszcze w urządzeniu może teraz wybrać ścieżkę przez ten sam interfejs i czy coś powinno. Na zajętej krawędzi z sieciami gości lub nakładającymi się tunelami partnerów odpowiedź nie jest automatycznie nie. Zapisz powód obok ustawienia, bo następny inżynier znajdzie polecenie, a nie rozmowę.

Zakres ochrony i NAT są oddzielne

Tunel od oddziału do oddziału chroni to, co wybiera jego crypto ACL. Jeśli ten ACL wskazuje wewnętrzną podsieć ASA jako źródło, pula dostępu zdalnego nie jest chroniona, a pakiet zostanie odrzucony lub wysłany jawnie, w zależności od zachowania platformy wobec ruchu niedopasowanego. Dodaj pulę do chronionego przepływu, gdy projekt zachowuje adresy puli.

Następnie NAT decyduje, czy adres puli przetrwa. Identity NAT zachowuje go, a oddział widzi 10.77.0.20 jako źródło. Tłumaczenie zmienia umowę: oddział zwraca teraz ruch na przetłumaczony adres, a jego własna polityka musi to zaakceptować. Kolejność reguł decyduje, czy crypto ACL dopasowuje się przed tłumaczeniem, czy po nim, więc czytaj rzeczywisty przepływ, zamiast zakładać, która wygrywa.

Nie usuwaj ogólnych reguł PAT dla internetu, aby zadziałał jeden przypadek tranzytu. Ukierunkowane wyłączenie lub celowa reguła identity są łatwiejsze do wyjaśnienia i wycofania niż dziura w polityce wychodzącej.

Szyfrowanie nie jest autoryzacją

Działający tunel dowodzi tylko, że dwie strony zgadzają się co do kluczy i selektorów. Nie mówi nic o tym, czy ten użytkownik może dotrzeć do tej usługi. Filtr VPN lub polityka grupy dołączona do połączenia dostępu zdalnego nadal musi zezwalać na cel i port oddziału, a ACL interfejsu na ścieżce zewnętrznej nadal obowiązuje.

Przetestuj odpowiedź w obu kierunkach. Połączenie, które się udaje, gdy sąsiednia usługa powinna zawieść, jest bardziej pouczające niż jeden udany ping, ponieważ pokazuje, że polityka jest selektywna, a nie otwarta szeroko. Jeśli test, który powinien zostać odrzucony, się udaje, winny nie jest tunel, lecz polityka. Zachowaj oba wyniki w rejestrze zmian, aby następna osoba wiedziała, jakie zachowanie było zamierzone.

Hairpin czy drugi interfejs

Tranzyt hairpin utrzymuje projekt w małej skali i kosztuje jedno ustawienie globalne. Osobny interfejs lub tunel oparty na routingu z własnym interfejsem wirtualnym izoluje ścieżkę tranzytu i daje politykę na interfejs, kosztem adresacji i kolejnej crypto map lub profilu. Żadne nie jest bardziej poprawne; zawodzą inaczej.

Projekty oparte na routingu to inny układ, a nie pole wyboru w tej samej konfiguracji. Jeśli na taki przejdziesz, powyższa dyskusja o crypto ACL opartym na politykach przestaje obowiązywać, a tabela routingu zaczyna wykonywać pracę wyboru.

Weryfikuj z rzeczywistego klienta

Sonda uruchomiona z ASA ma inny adres źródłowy i nie przejdzie ścieżki od puli do oddziału. Użyj packet-tracer do sprawdzenia piątki, a następnie otwórz prawdziwe połączenie z faktycznego klienta zdalnego, ponieważ tracer symuluje i nie zastępuje routingu ani polityki samego klienta.

Po planowanej zmianie połącz się z usługą, która powinna działać, potem z tą, która powinna zostać odrzucona, a następnie potwierdź trasę powrotną oddziału. przykłady NAT hairpin dla VPN firmy Cisco utrzymują zezwolenie intra-interface, NAT i ACL widocznie oddzielone, i to jest model mentalny wart skopiowania.

Powiązane artykuły