Dlaczego zdalny użytkownik ASA dociera do podsieci, ale nie do aplikacji
Trasy dowodzą, że tunel działa, a nie że użytkownik może otworzyć aplikację. Przeczytaj filtr otrzymany przez sesję, a potem przetestuj połączenie dozwolone i odrzucone.
Twój użytkownik łączy się, otrzymuje adres, pinguje serwer w podsieci aplikacji i nadal nie może otworzyć na nim usługi. Taka kombinacja jest na ASA normalna, ponieważ udany tunel i użyteczne uprawnienie są rozstrzygane przez różne ustawienia. Lista tunelu dzielonego wybrała, które cele trafiły do tunelu; filtr VPN i własne reguły dostępu celu decydują, do czego może dotrzeć odszyfrowane żądanie. Przejdź trzy decyzje po kolei, zamiast rozszerzać listę tras, aż coś się zmieni.
Trzy decyzje, które łatwo pomylić
Dopuszczenie odpowiada, czy użytkownik może w ogóle zestawić tunel: poświadczenia, certyfikat i dowolny drugi czynnik. Wybór trasy odpowiada, które cele klient wysyła do tego tunelu. Autoryzacja odpowiada, czy odszyfrowane żądanie może dotrzeć do usługi. Tylko trzecia tworzy błąd, który zgłasza użytkownik.
Szybkim sposobem ich rozróżnienia jest pytanie, co zepsułaby zmiana. Usunięcie trasy z listy dzielonej zatrzymuje ruch do tej podsieci, nic nie przyznając; dodanie ACE do filtra VPN przyznaje cel bez zmiany tego, co klient tuneluje.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Przeczytaj filtr, który sesja faktycznie otrzymała
Zacznij od żywej sesji, a nie od konfiguracji, która według ciebie obowiązuje. show vpn-sessiondb detail anyconnect wypisuje przypisaną politykę grupy i nazwę filtra przypisanego do tej sesji. Jeśli pole jest puste, żaden filtr niczego nie egzekwuje, a blokada pochodzi z innego miejsca.
Następnie przeczytaj politykę, do której należy wartość, łącznie z wartościami domyślnymi, bo filtr może być odziedziczony, a nie zapisany tam, gdzie patrzysz:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Porównaj nazwę filtra w sesji z ACL, który właśnie edytowałeś. ACL o podobnej nazwie, którego użytkownik nigdy nie otrzymał, nie może zmienić polityki zasobów tej sesji, i to jest najczęstszy powód, dla którego poprawnie wyglądająca zmiana nie działa.
Pierwszeństwo wyjaśnia resztę. Dla ustawienia filtra rekord DAP ma pierwszeństwo przed atrybutami nazwy użytkownika, a atrybuty nazwy użytkownika przed polityką grupy. Gdy sesja pokazuje filtr, którego się nie spodziewałeś, poszukaj polityki DAP pasującej do tego użytkownika, zanim dotkniesz grupy.
Lista dzielona i filtr to osobne pola
Na ASA 9.x polityka grupy przechowuje split-tunnel-network-list i vpn-filter jako różne ustawienia, a przewodnik po politykach grupy 9.22 dokumentuje je osobno właśnie z tego powodu. Lista sieci to wskazówka routingu dla klienta; filtr to lista kontroli dostępu stosowana do odszyfrowanego ruchu.
To rozróżnienie ma znaczenie, gdy użytkownik potrzebuje jednej usługi HTTPS w podsieci. Umieść podsieć na liście dzielonej, aby pakiety weszły do tunelu, a potem zezwól w filtrze tylko na tę usługę. Rozszerzanie listy tras niczego nie autoryzuje, a jej zwężanie nie jest mechanizmem egzekwowania.
Sprawdź, czy ACL interfejsu w ogóle jest na ścieżce
Odszyfrowany ruch dostępu zdalnego nie zawsze przechodzi przez ACL interfejsu zewnętrznego tak, jak ludzie zakładają. Gdzie sysopt connection permit-vpn jest włączone, ASA stosuje swoje udokumentowane obejście VPN dla tego ruchu, a obowiązujące filtry VPN nadal działają później. Sprawdź ustawienie za pomocą show run all sysopt zamiast wnioskować ze schematu topologii.
Tak czy inaczej, zapora hosta docelowego i autoryzacja aplikacji pozostają na ścieżce. Reguła ASA zezwalająca na TCP 443 nie sprawia, że aplikacja akceptuje użytkownika.
Zaakceptuj zmianę także przy odrzuconym połączeniu
Sam dozwolony test dowodzi bardzo niewiele, bo działający tunel tworzy ten sam pierwszy pakiet niezależnie od tego, czy filtr istnieje. Otwórz zamierzoną usługę z klienta, potem spróbuj celu, który powinien pozostać zamknięty, i potwierdź, że zawodzi z właściwego powodu.
Zanotuj cztery fakty przy zamykaniu zgłoszenia: dopuszczoną tożsamość, politykę i filtr, które sesja faktycznie otrzymała, cele na liście dzielonej i zasób, do którego użytkownik miał prawo dotrzeć. Te cztery wyjaśniają, gdzie ruch jest kontrolowany, bez zamieniania listy tras w zaporę.
Jeśli usługa nadal odmawia po zezwoleniu przez filtr, przejdź do hosta: adres nasłuchu, zapora hosta i własne mapowanie użytkowników aplikacji. Tunel w tym momencie wykonał swoją pracę, a dalsze zmiany na ASA tylko dodają ryzyko.