Ruch klienta VPN i stan firewalla: przepływ zewnętrzny i wewnętrzny

Uścisk dłoni VPN kończy się, klient dostaje adres, a usługa za bramą nadal odrzuca połączenie. Firewall często robi dokładnie to, co mu nakazano. Dopuścił zewnętrzny przepływ tunelu, który jest innym pakietem niż po dekapsulacji połączenie aplikacji. Wynikają z tego dwie decyzje: który przepływ dopuszczasz i czy granica w ogóle śledzi stan.

Dopóki nie rozdzielisz tych dwóch rzeczy, każda zmiana reguły jest zgadywaniem.

Firewall widzi dwa różne pakiety

Przed dekapsulacją firewall widzi ruch adresowany do punktu końcowego VPN: zewnętrzny przepływ UDP do nasłuchującego. Po dekapsulacji przekazywany pakiet niesie wewnętrzny adres klienta i cel usługi.

Zezwolenie na przepływ zewnętrzny nie upoważnia przekazywanego połączenia TCP. Można je oceniać w różnych łańcuchach, na różnych interfejsach i z różnymi adresami po translacji.

Porównaj przechwyty z równoważnych pozycji po obu stronach. Przechwyt na krawędzi tunelu i przechwyt na serwerze pokazują różne tuple dla tej samej sesji.

Pierwsza decyzja: dopuścić tunel czy usługę

Jeśli klient potrzebuje tylko samego punktu końcowego VPN, zewnętrzne zezwolenie może wystarczyć. Jeśli potrzebuje usługi za bramą, potrzebne jest zezwolenie na przekazywanie do tego celu i portu. Reguła tunelu, która dopuszcza też usługę, jest decyzją projektową, którą należy nazwać, a nie przypadkiem.

Utrzymuj zakres klienta i zasięg usługi wąskie. Zezwolenie z podsieci tunelu do całej sieci lokalnej to decyzja o zaufaniu każdemu hostowi, a nie skrót dla jednej aplikacji.

Zapisz obie reguły osobno. Reguła tunelu i reguła usługi zawodzą na różne sposoby i są diagnozowane różnymi dowodami. Gdy jedna zawiedzie, wiesz, którą warstwę sprawdzić najpierw.

Druga decyzja: ze stanem czy bez stanu na każdej granicy

Reguła dla ustalonego przepływu może przepuszczać odpowiedzi dozwolonej wymiany, ale jej zachowanie zależy od produktu. Grupa zabezpieczeń w chmurze zwykle śledzi stan; lista kontroli dostępu podsieci często go nie śledzi i wymaga jawnej obsługi w obu kierunkach. Nie zakładaj, że każda granica na ścieżce traktuje stan tak samo. Wymień każdą granicę i oznacz ją jako śledzącą stan lub bezstanową, zanim zaprojektujesz reguły.

Jeśli reguła się zmieni, istniejące śledzone przepływy mogą nadal działać, podczas gdy nowe zawodzą, albo odwrotnie. Ta różnica jest użyteczną wskazówką, a nie powodem do wyczyszczenia całego stanu połączeń na działającej bramie.

Testuj świeżym kontrolowanym żądaniem i sprawdź odpowiednie liczniki. Czysty test bije zakłócający reset. Zapisz nazwę licznika w zapisie zmiany, aby następny test użył tych samych dowodów.

Zweryfikuj ścieżkę powrotną w ramach tej samej polityki

Wyślij nowe żądanie od klienta do usługi, a następnie sprawdź liczniki ruchu w przód i powrotnego na każdej granicy. Potwierdź, że odpowiedź używa oczekiwanej ścieżki, zwłaszcza gdy w grę wchodzi translacja.

Utrzymuj zamierzony zakres klienta i zasięg usługi wąskie oraz zweryfikuj ścieżkę powrotną w ramach tego samego zestawu reguł, który dopuścił żądanie. Reguła, która działa tylko dlatego, że stary przepływ jest wciąż otwarty, nie jest działającą regułą.