Profile zapory a wyjście VPN: dlaczego publiczny to nie ścieżka
Profil zapory wybiera, który zestaw reguł obowiązuje. Nie mówi nic o tym, która karta sieciowa przeniosła pakiet, a jawne zablokowanie wygrywa z węższym zezwoleniem.
Reguła brzmi precyzyjnie: zezwól na ruch lokalny w profilu prywatnym i tylko na ruch VPN w publicznym. Tak nie jest, bo profil sieci wybiera, który zestaw reguł zapory obowiązuje, i nie mówi nic o tym, która karta sieciowa przeniosła pakiet. Traktowanie nazwy profilu jako wymogu ścieżki to błąd, przez który projekt ograniczonego wyjścia wygląda na ukończony, choć nim nie jest.
Najpierw zapisz przepływy, potem zdecyduj, który mechanizm może naprawdę wymusić każdy z nich. Ta lista przepływów jest jedynym artefaktem, który przetrwa następną zmianę reguł.
Kategoria wybiera reguły, a nie trasy
Gdy Windows klasyfikuje sieć jako publiczną lub prywatną, zapora stosuje zestaw reguł skonfigurowany dla tego profilu. Klasyfikacja podąża za siecią, do której dołączyła karta sieciowa, a zestaw reguł decyduje, co jest w niej dozwolone. Żaden z tych faktów nie zależy od tego, czy ruch aplikacji korzystał z tunelu. Właśnie ta niezależność jest całą trudnością.
Wybór ścieżki należy do routingu, przez metrykę interfejsu i prefiks instalowany przez tunel. Profil może więc być oznaczony jako publiczny, gdy połączenie aplikacji idzie ścieżką fizyczną, a zapora nadal zgłosi, że zastosowano publiczny zestaw reguł.
Dlatego reguła ograniczona do profilu nie może oznaczać tylko tunelu. Te dwie właściwości rozstrzygają różne komponenty i jedna nie może zastąpić drugiej.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Jawne zablokowanie ma pierwszeństwo przed węższym zezwoleniem
Wskazówki Microsoftu dotyczące reguł zapory odróżniają zezwolenie jako wyjątek od domyślnej akcji blokowania od jawnego zablokowania, które jest sprzeczne z zezwoleniem. Jawne zablokowania wygrywają ten konflikt, a reguły wychodzące podlegają temu samemu pierwszeństwu.
Zatem popularny przepis, by dodać regułę blokującą wszystko i liczyć na węższe zezwolenie umieszczone nad nią, nie robi tego, czego oczekuje jego autor. Zapora systemu Windows nie rozstrzyga konfliktu według kolejności reguł nadanej przez administratora. Zablokowanie po prostu działa, a łącząca się aplikacja zgłasza przekroczenie limitu czasu. Reguła, która wyglądała na wyjątek, nigdy nie była w grze.
Obsługiwana forma to zasada domyślnego odmawiania z zatwierdzonymi regułami zezwolenia, w której każde zezwolenie nazywa program, usługę lub cel wystarczająco precyzyjnie, by można je było przejrzeć. Taki projekt przechodzi audyt, ponieważ każdy wyjątek jest widoczny i żaden nie zależy od kolejności utworzenia.
Dwie sprzeczne reguły są gorsze niż jedna reguła, bo wynikowe zachowanie jest jednocześnie poprawne i niewyjaśnialne.
Daj polityce wychodzącej jednego właściciela
Obsługiwany klient VPN już utrzymuje własne zachowanie blokujące i własne wyjątki dla punktów końcowych. Dodanie niekoordynowanych reguł ręcznych może pozostawić tego klienta poza tunelem potrzebnym do konfiguracji albo zostawić otwartą drugą ścieżkę, której nikt nie zauważył.
Zdecyduj, do kogo należy polityka wychodząca, zanim napiszesz reguły: do konfiguracji samego klienta, do zarządzanej polityki zapory czy do udokumentowanej lokalnej listy wyjątków z właścicielem. Potem uzgodnij warstwy, zamiast piętrzyć eksperymenty, aż coś się połączy. Nazwany właściciel to także osoba, której pyta się, gdy dwie warstwy się nie zgadzają.
Zachowaj kanał odzyskiwania, zanim cokolwiek zmienisz. Zdalna maszyna zablokowana poza własną ścieżką zarządzania to gorszy wynik niż luka w polityce, którą zamykałeś. Regułę odzyskiwania łatwiej uzasadnić, gdy jest zapisana z góry, i łatwiej znaleźć, gdy zmiana pójdzie źle o godzinie, której nikt nie lubi.
Przetestuj cztery wyniki zamiast czytać etykietę
Polityka jest tak dobra, jak przypadki, które rozróżnia, więc traktuj etykietę profilu jako punkt wyjścia, a nie wynik. Cztery wyniki mówią, czy działa: zamierzone żądanie LAN się udaje, objęte żądanie internetowe się udaje, zabronione żądanie bezpośrednie zawodzi, a przypadek awarii tunelu zachowuje się zgodnie z projektem, zamiast po cichu się wycofywać. Zapisz cztery wyniki obok zmiany reguł. Plan testów z czterema nazwanymi przypadkami jest dość krótki, by uruchamiać go za każdym razem, i dość konkretny, by głośno zawieść.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Pierwsze polecenie pokazuje, jak sklasyfikowana jest każda podłączona sieć, co często nie jest tym, czego spodziewała się osoba pisząca regułę. Drugie pokazuje domyślną akcję dla każdego profilu, a trzecie wymienia włączone blokady wychodzące, w tym te, które po cichu unieważnią węższe zezwolenie.
Uruchom cztery przypadki ponownie po zmianie sieci, bo profil może zostać przeklasyfikowany, gdy maszyna dołączy do innej sieci. Zgodna etykieta profilu nie jest dowodem, że ścieżka była tą, którą zamierzałeś.