Dlaczego brama firewalla powiązana ze stanem VPN nie jest regułą ping tylko przez tunel

Wyobraźcie sobie regułę firewalla, która włącza ICMP echo dla publicznego adresu serwera za każdym razem, gdy połączony jest nazwany profil VPN. Czyta się to jak „ping tylko przez tunel”, a takie odczytanie jest błędne w sposób, który ma znaczenie. Reguła nie ogranicza, kto może dotrzeć do hosta; zmienia to, na co odpowiada publiczny interfejs, dopóki przypadkiem aktywne jest inne połączenie. To dwie różne polityki, a jedna z nich po cichu poszerza ekspozycję.

Reguła, którą według was napisaliście

Zamierzone wymaganie jest zwykle wąskie: system monitoringu albo jedyny administrator na VPN ma móc potwierdzić, że serwer żyje. Zapisane jako zdanie brzmi jak kontrola dostępu do tunelu. Zapisane jako obiekt firewalla zamienia się w warunek na profilu publicznym, bo właśnie tam trafia żądanie echo.

Gdy warunkiem staje się stan połączenia, a nie adres źródłowy, zbiór dozwolonych nadawców nie jest już zbiorem partnerów VPN. Każdy, kto dotrze do publicznego adresu, może wysłać żądanie echo, dopóki brama jest otwarta. Tunel nie stał się ścieżką; tunel stał się przełącznikiem.

Ludzie promujący ten pomysł zwykle nie kłamią co do efektu, którego chcieli. Potrzebowali sprawdzenia, które odpowiada tylko wtedy, gdy łącze jest zdrowe, a zdrowie łącza najłatwiej było obserwować przez VPN. Błąd polega na potraktowaniu sygnału dostępności jako decyzji o dostępie, a potem na automatyzacji.

Czym brama faktycznie steruje

Ten projekt scala dwie niezależne rzeczy, a ich rozdzielenie to większość poprawki. Pierwsza to zakres: który adres lokalny, które adresy zdalne, który protokół i który typ ICMP. Druga to warunek: czy obiekt reguły jest w tej chwili włączony. Zakres to coś, co firewall ocenia dla każdego pakietu; warunek to coś, co skrypt zapisuje w magazynie zasad, i oba są uzgadniane na zupełnie różnych zegarach.

Jeśli wymaganie naprawdę dotyczy tylko partnerów VPN, zakres załatwia to bez żadnej logiki stanu połączenia: przypnijcie regułę do interfejsu tunelu albo do zakresu adresów tunelu, ograniczcie adresy zdalne do puli klientów i podajcie typ echo zamiast „ICMP”. Ta reguła pozostaje poprawna, gdy żaden VPN nie jest aktywny, i nie może jej otworzyć niepowiązany profil.

Jeśli wymaganie naprawdę dotyczy publicznej bramy, powiedzcie to w tekście polityki, bo kryteria akceptacji się zmieniają. Publiczna brama musi nazwać dokładny profil, zdefiniować, co znaczy „połączony”, i stwierdzić, że publiczni nadawcy są w zakresie z założenia. Większość zamieszania znika w chwili, gdy ktoś jest zmuszony zapisać to zdanie.

Zbudujcie obiekt raz, potem go przełączajcie

Przygotujcie z góry jedną regułę ze stabilną tożsamością, wyłączoną, i pozwólcie kontrolerowi zmieniać tylko jej stan włączenia. Tworzenie reguł według nazwy wyświetlanej przy każdym uruchomieniu to droga, na której magazyn zasad kończy z pięcioma niemal identycznymi obiektami i bez niezawodnego sposobu ich usunięcia.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Nazwa jest trwałym identyfikatorem; nazwa wyświetlana to dokumentacja, którą człowiek może edytować. Uzgadniajcie według -Name, a skrypt przestanie tworzyć duplikaty. Ten sam kształt polecenia obejmuje przypadek IPv6 z -Protocol ICMPv6 -IcmpType 128, ale to osobna reguła, bo numery typu echo różnią się między dwiema rodzinami.

Utrzymujcie rodzinę adresów i typ ICMP jawnie z drugiego powodu: -Protocol ICMPv4 bez typu zezwala na każdy komunikat ICMPv4, który dopuszcza profil, w tym te, których nigdy nie zamierzaliście przyjmować. Nazwanie typu 8 zawęża regułę do żądania echo, a tylko to wysyła sprawdzenie osiągalności.

Gdzie automatyzacja przeczy zamiarowi

Odpytywanie profilu klienta co kilka minut nie może dać natychmiastowej granicy. Między spadkiem połączenia a następnym odpytaniem reguła wciąż odpowiada na publicznym adresie; między podniesieniem połączenia a następnym odpytaniem nie odpowiada. Przyznać to opóźnienie jest uczciwe, a twierdzić, że projekt wymusza ścisły niezmiennik, nie jest.

W samym sprawdzeniu stanu jest pułapka zakresu. Get-VpnConnection raportuje profile klienta skonfigurowane na maszynie, domyślnie dla bieżącego użytkownika, a dla wszystkich użytkowników z -AllUserConnection. Nie raportuje użytkowników zdalnych aktualnie połączonych z serwerem RRAS; to jest inne obserwacja z innym poleceniem. Brama zbudowana na niewłaściwym nie jest z niczym połączona.

Potem pokryjcie stany, których nikt nie skryptuje: start z regułą już włączoną z poprzedniego uruchomienia, awaria kontrolera przy otwartej bramie i usunięty profil, którego reguła pozostaje aktywna. Każdy wymaga zdefiniowanej wartości domyślnej, a bezpieczną wartością domyślną dla publicznego zezwolenia jest wyłączenie. Jeśli wymaganie naprawdę nie znosi okna odpytywania, reguła powiązana ze stanem jest złym narzędziem, a egzekwowanie należy do tunelu, nie do publicznego interfejsu.

Na koniec przetestujcie publiczne żądanie dwa razy: raz z podniesionym wybranym połączeniem i raz z opuszczonym, z hosta, który nie jest w VPN. Udany ping z wnętrza tunelu niczego o tej polityce nie dowodzi, i właśnie ten pomiar większość wdrożeń pomija.