Sam zapora sieciowa Windows jako wyłącznik awaryjny VPN: wytrzyma?
Reguły według typu interfejsu mogą blokować karty fizyczne, ale tunel dostawcy zewnętrznego często wygląda jak przewodowy. Sprawdź klasyfikację, trasę do punktu końcowego, a potem DNS.
Zapytaj, czy zapora Windows może sama pełnić rolę wyłącznika awaryjnego, a otrzymasz dwie pewne siebie i sprzeczne odpowiedzi. Jedna mówi, że reguła według typu interfejsu robi całą robotę; druga, że bez skryptów się nie da. Obie opisują połowę tego samego mechanizmu. Zapora potrafi wyrazić blokadę, a to, czy wynik faktycznie zawodzi w stanie zamkniętym, zależy od trzech rzeczy: jak Windows klasyfikuje kartę tunelu, czy przetrwa wyjątek dla punktu końcowego i czy pokryte są rozwiązywanie nazw oraz IPv6. Pomylisz się w którymkolwiek i maszyna albo przecieka, albo traci całą łączność.
Trzy warunki, w tej kolejności
Pierwszy warunek to klasyfikacja, która decyduje, czy żądana reguła jest w ogóle wyrażalna. Reguły zapory Windows można ograniczać według typu interfejsu: przewodowy, bezprzewodowy lub dostęp zdalny. Zasada, która blokuje ruch wychodzący na typach fizycznych i pozwala na tunel, działa tylko wtedy, gdy Windows rozpoznaje tunel jako dostęp zdalny.
Drugi warunek to wyjątek dla punktu końcowego. Zanim powstanie tunel, klient musi dotrzeć do serwera VPN przez kartę fizyczną, więc pełna blokada tej karty uniemożliwia dokładnie to połączenie, które uczyniłoby blokadę zbędną. Wyjątek musi wskazać serwer i jego port, a pakiet musi wyjść przez bramę fizyczną, a nie do jeszcze niepodniesionego tunelu.
Trzeci to pokrycie. Zestaw reguł, który blokuje IPv4 i zapomina o IPv6, albo pozwala lokalnemu resolverowi szukać punktu końcowego i tym samym pozwala na każde inne wyszukiwanie, zawodzi otwarcie dokładnie w tym oknie, dla którego wyłącznik istnieje. To luka w projekcie, nie błąd zapory. To także luka, która przeżywa każdy test na biurku.
Klasyfikacja to pierwsza brama
Sprawdź, co Windows myśli o kartach, zanim napiszesz choć jedną regułę. Rodzime połączenie VPN w Windows zwykle pojawia się jako dostęp zdalny. Klient zewnętrzny, który tworzy własną kartę wirtualną, często pojawia się jako przewodowy, co oznacza, że blokada ograniczona do kart przewodowych blokuje także tunel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionTrzecie polecenie mówi, czy obowiązuje już domyślna blokada ruchu wychodzącego, co zmienia cały kształt projektu. Jeśli domyślnie jest już blokada, piszesz reguły zezwalające, a nie wyjątki od permisywnej podstawy, i to znacznie łatwiejsza postawa do przemyślenia.
Jeśli twoja karta tunelu zgłasza się jako przewodowa, sama zapora nie jest właściwym narzędziem do projektu z zamkniętym zawodem, i żadne strojenie reguł tego nie zmieni. To przypadek, w którym druga opinia w każdym wątku forum jest słuszna.
Wyjątek dla punktu końcowego potrzebuje trasy, nie tylko reguły
Załóżmy, że klasyfikacja działa. Wyjątek składa się z dwóch części, a one żyją w różnych podsystemach. Reguła zapory pozwala na ruch; trasa hosta wyprowadza go właściwym interfejsem, gdy tunel jest wyłączony.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Bez trasy wyjątek pomaga tylko dopóki domyślna trasa wskazuje jeszcze bramę fizyczną. Gdy klient zainstaluje własną trasę domyślną, a potem padnie, dozwolone pakiety nie mają sensownego miejsca, a połączenia nie da się odtworzyć. Ta awaria wygląda jak zepsuty klient, a naprawdę jest brakującą trasą.
Trzymaj wyjątek tak wąski, jak pozwala klient. Jeden adres i jeden port da się przejrzeć; zakres obejmujący całą sieć dostawcy już nie. Ta szersza reguła pozwala też na wszystko inne hostowane u tego samego dostawcy, co zwykle jest więcej, niż zamierzałeś.
DNS i IPv6 to miejsca, gdzie zawodzi otwarcie
Rozwiązywanie nazw to klasyczny wyciek. Jeśli punktem końcowym jest nazwa hosta, klient musi ją rozwiązać przed powstaniem tunelu, co oznacza, że karcie fizycznej trzeba pozwolić dotrzeć do resolvera. To samo pozwolenie wypuszcza każde inne zapytanie, gdy tunel jest wyłączony, a jedno zapytanie wystarczy, by ujawnić, co zamierzałeś odwiedzić.
IPv6 jest drugi. Reguły napisane dla IPv4 nie obejmują drugiej rodziny, a wiele klientów instaluje tylko trasy IPv4. Maszyna z rodzimą łącznością IPv6 może więc dalej rozmawiać z internetem, podczas gdy strona IPv4 jest mocno zablokowana, a wyłącznik przez cały czas zgłasza sukces.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
Trzeci wiersz warto zrozumieć, a nie obejść. Zapora decyduje o pakietach, a nie o tym, którego interfejsu zażądała aplikacja, a program, który wiąże się jawnie, bywa trudny do opanowania. To argument za wyłącznikiem po stronie klienta, działającym poniżej aplikacji, a nie za większą liczbą reguł.
Testuj, zatrzymując klienta, a nie wyrywając kabel
Jedyny sensowny test to ten, który naśladuje awarię, przed którą się chronisz. Zatrzymaj usługę, zabij proces albo wyłącz kartę utworzoną przez klienta, a potem spróbuj dotrzeć do internetu i nazwy:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Wszystkie trzy powinny zawieść. Jeśli pierwszy się uda, blokada nie obowiązuje; jeśli drugi uda się tam, gdzie pierwszy zawiódł, masz wyciek DNS; jeśli trzeci się uda, IPv6 nie jest pokryty. Każdy wynik wskazuje dokładnie jedną z powyższych luk.
Powtórz test po uśpieniu i wybudzeniu, bo profil zapory może się zmienić, gdy Windows uzna sieć za publiczną lub prywatną, a reguły ograniczone do profilu podążają za nim. Projekt, który trzyma się na biurku i zawodzi w pociągu, to projekt przetestowany raz.
Jeśli brama klasyfikacji albo wymóg DNS czynią podejście tylko-z-zaporą niewykonalnym, wyłącznik po stronie klienta jest uczciwą odpowiedzią. Jeśli tunel kończy się za to na routerze, polityka powinna należeć do routera, bo jedna reguła tam obejmuje każde urządzenie za nim i nie zależy od tego, jak Windows nazywa kartę.