Która reguła ASA widzi ruch po tym, jak VPN go odszyfruje

Pierwsze założenie, z którego trzeba zrezygnować, to że ACL kryptograficzna jest polityką dostępu. Nie jest. Na Cisco ASA ta lista odpowiada na jedno wąskie pytanie: które pakiety zasługują na ochronę, a ta odpowiedź nie mówi nic o tym, czy odszyfrowany pakiet może dotrzeć do serwera za zaporą. Dostęp jest rozstrzygany później, przez politykę interfejsu, filtr polityki grupowej lub oba, w zależności od tego, jak zbudowano tunel.

ACL kryptograficzna odpowiada na inne pytanie

ACL kryptograficzna to lista dopasowań. Mówi tunelowi, co szyfrować między dwiema stronami; pakiet, który do niej nie pasuje, po prostu nie jest chroniony. Poszerzenie jej zmienia zakres ochrony i nic więcej.

Dlatego dodanie tam podsieci może podnieść tunel, podczas gdy sama aplikacja nadal zawodzi. Tunel jest podniesiony, bo dopasowanie teraz istnieje. Aplikacja nadal zawodzi, bo nic na tej liście niczego nie zezwala. Dwa różne pytania, dwie różne listy.

Co naprawdę pomija ustawienie obejścia

sysopt connection permit-vpn pozwala chronionemu ruchowi pominąć kontrolę ACL interfejsu, która inaczej obowiązywałaby po stronie wejściowej. To udogodnienie dla wdrożeń VPN i jest globalne. Nie dotyka polityki grupowej ani filtra autoryzacji dla poszczególnych użytkowników.

Czytaj rzeczywistą wartość, a nie założenie: show running-config all sysopt wypisuje ustawienie nawet wtedy, gdy nigdy nie zostało jawnie skonfigurowane, i właśnie tam zaczyna się wiele zamieszania.

Ponieważ ustawienie jest globalne, testowanie go jako szybkiego eksperymentu na jednej niedziałającej podsieci to zły interes. Każdy inny tunel na tej zaporze dzieli wynik. Zachowaj je na świadomą zmianę z planem wycofania.

Czytaj filtr w kierunku odszyfrowania

ACL vpn-filter LAN-to-LAN pisze się z punktu widzenia tunelu, a nie interfejsu. Sieć zdalna trafia na pozycję źródła, a sieć lokalna na pozycję celu, bo tak wygląda pakiet po odszyfrowaniu. Ten sam filtr jest następnie ponownie oceniany w przeciwnym kierunku przed szyfrowaniem, z odwróconymi rolami adresów.

Warunki portów zasługują na więcej staranności niż skopiowana ACL interfejsu właśnie z tego powodu. Reguła zezwalająca na jeden port docelowy może mieć niezamierzony skutek w kierunku odwrotnym, gdzie nowe połączenie używa tego portu jako źródła. Zanim zbudujesz listę, zapisz, która strona może inicjować, jaka jest rzeczywista usługa i która strona przeciwna musi pozostać zamknięta.

Potwierdź, który filtr jest rzeczywiście dołączony: show running-config group-policy i show vpn-sessiondb detail l2l razem mówią, co odziedziczyła sesja. Edycja ACL, do której nie odwołuje się żadna polityka, niczego nie zmienia.

Nie używaj jednego obiektu ACL do dwóch zadań

ACL access-group interfejsu i vpn-filter wyglądają jak ten sam typ obiektu i są oceniane w różnych punktach z różną orientacją adresów. Przypisanie jednej listy do obu zaprasza zmianę, która naprawia tunel i po cichu poluzowuje interfejs fizyczny.

Trzymaj je osobno, nazywaj je według ich zadania i pozwól, by różnica kierunku była widoczna w nazwach.

Weryfikuj nowymi połączeniami, w obu kierunkach

Po zaplanowanej zmianie otwórz jedno nowe połączenie, które powinno zostać dozwolone, i jedno nowe połączenie, które powinno zostać odrzucone, a następnie zapisz adresy, kierunek i zgodność z polityką razem z wynikiem. Ustanowiona sesja niczego nie dowodzi w kwestii filtrowania nowych połączeń, bo została już wpuszczona na starych regułach.

Uwzględnij też inspekcję. Dokumentacja producenta zauważa, że filtr VPN sprawdza połączenie początkowe, a nie każde połączenie wtórne otwierane przez mechanizm inspekcji, więc kanał sterujący i powiązany z nim strumień mediów mogą otrzymać inne traktowanie. Jeśli aplikacja zna protokół, przetestuj rzeczywisty strumień, a nie pojedynczą sondę portu.

Tunel, który staje się użyteczny po szerokim obejściu, mówi, że ograniczenie zostało usunięte, a nie że zostało spełnione. Wynikiem wartym zachowania jest nazwany punkt egzekwowania, na który możesz wskazać przy następnym przeglądzie.