Split tunneling nie zwalnia publicznego hosta z reguł NAT na ASA

Split tunneling jest zwykle opisywany jako sposób utrzymania ruchu firmowego wewnątrz tunelu, a reszty internetu poza zaporą. Obie połowy tego opisu są błędne w ten sam sposób. Split tunneling to decyzja o trasie podejmowana przez klienta, a decyzja o trasie nie mówi nic o tym, co dzieje się z pakietem po dotarciu do headendu.

Jedna usługa partnera na publicznym adresie, która upiera się, by widzieć adres twojej centrali, wystarczy, by zburzyć tę historię.

Mit: split tunneling usuwa zaporę z drogi

Przekonanie głosi, że każde miejsce docelowe poza zakresami prywatnymi pozostaje na lokalnym połączeniu internetowym, więc zapora nigdy go nie widzi i nigdy nie potrzebuje dla niego reguły. To prawda tylko tak długo, jak miejsce docelowe nie znajduje się na liście tunelu. W chwili, gdy operator dodaje publiczny host do ACL split-include, klient wysyła ten ruch do tunelu, a ASA musi go trasować, filtrować i tłumaczyć jak każdy inny odszyfrowany przepływ. Na kliencie nie zmieniło się nic poza listą miejsc docelowych.

Klient nie stał się routerem. Zastosował się do polityki, którą mu dałeś.

Co naprawdę robi trasa split-include

W konfiguracji zdalnego dostępu Cisco ASA polityka grupy niesie split-tunnel-policy tunnelspecified oraz split-tunnel-network-list, który nazywa standardową ACL. Każda linia permit w tej ACL to miejsce docelowe, które klient ma wysłać do tunelu, a wszystko inne nadal korzysta z lokalnej trasy domyślnej.

Dodanie jednego hosta to jedna linia i to jedyna część zmiany, którą klient może zobaczyć: access-list RA-SPLIT standard permit host 203.0.113.20.

Po tym połącz klienta ponownie. Polityka jest wymieniana przy połączeniu, więc istniejąca sesja zachowuje starą listę i sprawia, że zmiana wygląda, jakby nic nie zrobiła.

Pakiet przychodzi i wychodzi przez ten sam interfejs

Prześledź teraz przepływ po odszyfrowaniu. Pakiet wszedł przez interfejs zewnętrzny tunelem VPN, jego miejscem docelowym jest publiczny adres, a tabela routingu wysyła go z powrotem przez ten sam interfejs zewnętrzny w stronę internetu. Ruch, który wchodzi i wychodzi przez jeden interfejs, jest odrzucany, chyba że ASA ma na to pozwolenie, i właśnie to robi same-security-traffic permit intra-interface. Bez tego połączenie zawodzi w sposób, który wygląda na problem routingu, ale nim nie jest.

To ustawienie jest globalne. Pozwala na hairpinning dla każdego przepływu, który go potrzebuje, nie tylko dla tego hosta partnera, więc należy do przejrzanej zmiany, a nie do szybkiego testu.

Dlaczego PAT ograniczony do miejsca docelowego nie jest opcjonalny

Adres źródłowy odszyfrowanego pakietu to nadal adres VPN klienta, zwykle z puli takiej jak 10.77.0.0/24. Ten adres nie ma trasy w publicznym internecie, więc partner albo nigdy nie odpowiada, albo odpowiada donikąd.

Tłumaczenie poprawia źródło i pozostawia miejsce docelowe nietknięte. Ponieważ obiekty są już zdefiniowane gdzie indziej, ręczna reguła ograniczona do tego miejsca docelowego ma taki kształt:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Część destination static ma znaczenie. Jeśli ją pominiesz, reguła staje się szerokim tłumaczeniem, które może pasować do znacznie większego ruchu niż zamierzono, a szeroka reguła identity wcześniej w kolejności może ją całkowicie pokonać. Sprawdź show nat detail i kolejność sekcji, zanim uznasz, że twoja reguła jest tą pasującą.

PAT interfejsu oznacza też, że partner widzi adres interfejsu ASA, który może zostać ponownie przetłumaczony wyżej. Jeśli umowa wskazuje adres, potwierdź go od końca do końca, a nie na jednym przeskoku.

Udowodnij to właściwym celem testowym

Użyj samego hosta partnera, a nie ogólnej strony what-is-my-ip. Ta strona prawie na pewno jest poza listą split, więc zgłasza twój lokalny adres internetowy i nic nie mówi o tej ścieżce. Otwórz nowe połączenie do usługi partnera i zapytaj, jakie źródło zaobserwowali, albo uruchom packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed i czytaj etapy NAT i routingu linia po linii. Traceroute z klienta to słabsza kontrola, ponieważ pokazuje ścieżkę, która już się odbyła, a nie politykę, która ją wybrała.

Potem sprawdź, co nie powinno się zmienić. Zwykła strona internetowa nadal musi wychodzić przez lokalne połączenie, a prywatny zasób na liście tunelu nadal musi być osiągalny. Zmiana, która naprawia partnera i psuje jedno z tych dwóch, to inny błąd.

Działająca wersja tego projektu jest krótka: jeden host w ACL split, zgoda na hairpin, jedna reguła PAT ograniczona do miejsca docelowego. Wszystko inne w tej historii to mit.