ASA hairpin: wyjście do internetu czy odnoga VPN między lokacjami?
Pula klientów może wychodzić do internetu lub do VPN lokacji. Zdecyduj, której odnogi potrzebujesz, zanim napiszesz NAT, a potem sprawdź trasę, selektor i ścieżkę powrotną.
Dwaj użytkownicy dostępu zdalnego za tym samym ASA mogą wysyłać ruch przez ten sam interfejs zewnętrzny i być traktowani zupełnie inaczej. Jeden idzie do publicznej witryny, więc pakiet potrzebuje translacji źródła i trasy internetowej. Drugi idzie do serwera za tunelem między lokacjami, który również kończy się na tym interfejsie, więc pakiet potrzebuje tożsamości, pasującego selektora tunelu i ścieżki powrotnej do puli klientów. Zezwolenie na ten sam interfejs jest warunkiem dla obu i rozwiązaniem dla żadnego.
Dwie odnogi, jeden interfejs
Zdecyduj, którą odnogę budujesz, zanim wpiszesz regułę NAT, ponieważ reguły nie są wymienne. Odnoga A to klient do internetu: adres puli wchodzi, przetłumaczony adres publiczny wychodzi, powrót przez ten sam interfejs. Odnoga B to klient do prywatnego prefiksu po drugiej stronie innego peera IPsec: adres puli jest zachowany, ponownie szyfrowany i dostarczany do peera, który musi wiedzieć, jak odpowiedzieć puli.
To, czego obie potrzebują najpierw, to zezwolenie na ten sam interfejs. Bez niego ASA odmawia przesłania pakietu przez interfejs, na którym się pojawił, a awaria wygląda jak problem routingu, a nie polityki:
same-security-traffic permit intra-interface
Ta jedna linia zezwala na układ przekazywania, jak opisuje dokumentacja NAT ASA dla ścieżek przez ten sam interfejs. Nie dodaje trasy klienta, nie autoryzuje zasobu, nie tłumaczy adresu ani nie negocjuje selektora IPsec, więc spodziewaj się dodać po niej jeszcze trzy lub cztery rzeczy i nie czytaj jej akceptacji jako postępu.
Odnoga A: klient chce internetu
Dla wyjścia do internetu adres puli musi przestać być prywatny, zanim pakiet opuści urządzenie. W zwykłym projekcie PAT reguła tłumaczy pulę na adres interfejsu zewnętrznego, a stan powrotny przywraca przepływ do klienta:
object network VPN_POOL
subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup
Następnie potwierdź, że klient naprawdę poprosił ASA o przenoszenie tego ruchu. Wykluczenie z tunelu dzielonego wysyła publiczne miejsce docelowe przez własne połączenie telefonu, które nigdy nie dociera do ASA, i żadna reguła NAT nie naprawi pakietu, który nigdy nie został wysłany. Porównaj listę tunelu dzielonego z polityki grupowej z miejscem docelowym, które testujesz.
Reszta odnogi jest zwykła: użyteczna trasa domyślna lub konkretna z interfejsu zewnętrznego, polityka dostępu zezwalająca na przepływ i DNS obsługiwany zgodnie z wybraną polityką resolvera. Dodaj route-lookup tutaj z tego samego powodu co poniżej, ponieważ interfejs wejściowy i wyjściowy są identyczne.
Odnoga B: klient chce prywatnej lokacji
Ta odnoga zawodzi w więcej miejscach, więc pisz ją po kolei. Najpierw trasa klienta: prefiks docelowy musi być na liście tunelu dzielonego, inaczej klient nie umieści go w tunelu. Po drugie selektor tunelu: krypto-ACL między lokacjami musi obejmować adres puli do prefiksu zdalnego, nie tylko lokalny LAN do prefiksu zdalnego. Po trzecie tożsamość, aby adres puli nie został po drodze przetłumaczony na PAT internetowy.
nat (outside,outside) source static VPN_POOL VPN_POOL
destination static SITE_PREFIX SITE_PREFIX route-lookup
Strona zdalna to część, o której ludzie zapominają testować. Peer potrzebuje trasy powrotnej do puli i selektora, który ją obejmuje, oraz jego własna polityka musi zezwalać na adresy źródłowe, które zobaczy. Jeśli lokacja jest używana przez widok przetłumaczony, to poprawny projekt, ale wtedy oba peery, oba selektory i obie tablice routingu muszą się zgodzić co do przetłumaczonych adresów.
Sprawdź także kolejność reguł. Szeroka reguła PAT powyżej reguły tożsamości przetłumaczy prywatną wymianę, zanim reguła tożsamości zostanie w ogóle oceniona, a objawem jest tunel lokacji bez pasującego SA, a nie błąd NAT.
Test, który mówi, którą odnogę zbudowałeś
Użyj oceny ścieżki samego ASA zamiast czytać konfigurację i mieć nadzieję. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed pokazuje decyzję NAT, trasę i wynik ACL dla jednego przepływu; powtórz to z prywatnym miejscem docelowym. Jeśli faza NAT przepisuje przepływ prywatny do prywatnego, zbudowałeś odnogę A dla pakietu, który potrzebował odnogi B.
Dwie kolejne komendy zamykają lukę. show nat detail wypisuje kolejność reguł, której przestrzegał packet-tracer, i show crypto ipsec sa pokazuje, czy istnieje selektor dla oczekiwanej pary. Brakujący SA to kwestia konfiguracji selektora lub peera, a nie coś, co reguła NAT może naprawić.
Zweryfikuj każdą odnogę ruchem, któremu służy
Zaakceptuj odnogę A zwykłym publicznym żądaniem klienta, a odnogę B żądaniem do prywatnego zasobu, który naprawdę istnieje. Potem powtórz każdą z odmówionym zasobem, ponieważ „dozwolone” i „zatwierdzone przez politykę dostępu” nie są tym samym dowodem, a ping wychodzący z koncentratora nie ćwiczy żadnej ze ścieżek klienta.
Trzymaj dwa zapisy testu osobno w zgłoszeniu: adres źródłowy, miejsce docelowe, pasująca reguła NAT i wynik. Kiedy następny raport powie „VPN jest zepsuty”, ta para w ciągu minuty powie ci, która odnoga się cofnęła, a odpowiedzią jest zwykle trasa lub selektor, a nie linia tego samego interfejsu, którą wszyscy podejrzewają najpierw.