Klienci VPN blokowani przez publiczny profil zapory Windows

Twój tunel działa, brama odpowiada na ping, a udział plików nadal kończy się przekroczeniem limitu czasu. Ta kombinacja rzadko jest problemem routingu: Windows umieścił podsieć adaptera VPN w profilu Publicznym, a każda reguła zezwalająca napisana dla profilu Prywatnego lub Domenowego nigdy nie została zastosowana. Spotkałem się z tym na laptopach, które bez problemu łączą się z biurem, oraz na serwerach RRAS obsługujących wszystkich pozostałych klientów, a naprawa jest krótka, gdy tylko nazwiesz profil, który jest w grze. Oto kolejność, w jakiej pracuję, wraz ze sprawdzeniem, które mówi, kiedy się zatrzymać przed następnym krokiem.

Ustal, na którym profilu ruch faktycznie dociera

Zapora Windows nie ma jednego trybu globalnego. Każdy podłączony interfejs ma kategorię, a pakiety przychodzące są filtrowane według kategorii interfejsu, przez który docierają, więc to profil adaptera VPN decyduje, do czego może dotrzeć klient w tunelu, a nie adapter Wi-Fi lub Ethernet obok. Przeczytaj oba fakty, zanim cokolwiek zmienisz:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Przy standardowej instalacji OpenVPN lub WireGuard adapter VPN pojawia się jako niezidentyfikowana sieć i trafia do profilu Publicznego, który jest domyślny dla każdej sieci, której Windows nie potrafi sklasyfikować: żaden kontroler domeny nie odpowiedział przez nią i żaden profil bramy nie pasował. Nazwa interfejsu nie ma tu znaczenia, więc nazwanie adaptera „VPN” lub „Corp” niczego nie zmienia. DomainAuthenticated wymaga komputera przyłączonego do domeny , który faktycznie może dotrzeć do kontrolera domeny przez ten interfejs; tunel dzielony, który przenosi tylko jedną podsieć, nie spełni tego warunku.

Jeśli potrzebna reguła jest już ograniczona do puli VPN i już dotyczy kategorii, którą właśnie przeczytałeś, zatrzymaj się tutaj: filtrowanie nie jest twoją warstwą, a następnym miejscem do sprawdzenia jest konfiguracja usługi. To sprawdzenie zajmuje dziesięć sekund i oszczędza godzinę edycji reguł. Nazwy kategorii i to, co każda obejmuje, są udokumentowane w dokumentacji referencyjnej Get-NetConnectionProfile.

Potwierdź filtrowanie, a nie routing, zanim edytujesz reguły

Ping to słaby test. ICMP może przechodzić, podczas gdy port usługi jest odrzucany, a host może odpowiadać z sieci LAN, odmawiając tego samego żądania przez tunel. Przetestuj port, którego potrzebuje klient, z klienta:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Jeśli test portu zawiedzie, rozdziel obie warstwy. Awaria tunelu lub trasy zwykle objawia się brakiem jakiejkolwiek odpowiedzi z adresu bramy, podczas gdy odrzucenie przez zaporę pokazuje bramę, która odpowiada, i port usługi, który nie odpowiada. Na serwerze Windows publikującym pulę przez RRAS uruchom ten sam test z klienta i odczytaj profil samego serwera: interfejs RAS może znajdować się w kategorii, której reguły przychodzące nigdy nie wspominają zakresu klientów, i dlatego maszyna obsługuje swoją sieć LAN, a odrzuca każdego klienta w tunelu.

Gdy wynik nadal jest niejednoznaczny, zarejestruj odrzucenia dla profilu, który jest w grze, i przeczytaj je:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Wpisy wymieniające adres i port klienta wraz z DROP są rozstrzygające i mówią też, której reguły brakowało. Dziennik bez żadnego wpisu, podczas gdy SYN klienta nigdy się nie pojawia, wskazuje na coś przed hostem, więc wróć do tunelu, reguły NAT lub trasy puli, zanim dotkniesz kolejnego obiektu zapory.

Ogranicz jedną regułę przychodzącą do puli klientów

Naprawa to jedna reguła zezwalająca dla ruchu przychodzącego, której adres zdalny to pula, a nie cały świat. Z sesji z podniesionymi uprawnieniami:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Gdy usługa to jeden plik binarny, preferuj regułę ograniczoną do programu z -Program zamiast listy portów; to ogranicza wyjątek zarówno do procesu, jak i do zakresu źródłowego.

Wybór profilu to miejsce, w którym ten sam błąd popełnia się w drugą stronę. -Profile Public wystarcza, gdy adapter jest Publiczny i pozostaje Publiczny. -Profile Any jest do obrony, gdy usługa musi działać niezależnie od tego, jak Windows klasyfikuje adapter, ale tylko dopóki zakres zdalny pozostaje. To, czego nigdy nie da się obronić, to -RemoteAddress Any w profilu Publicznym: ta reguła podąża za laptopem do każdej sieci kawiarni i hotelu, do której się podłącza, i otwiera port każdemu, kto dzieli tę podsieć.

Zapisz pulę obok reguły. -RemoteAddress 10.8.0.0/24 po cichu przestaje pasować w dniu, w którym pula VPN zostanie przenumerowana, a awaria wygląda dokładnie jak pierwotny błąd, dlatego kosztuje drugie popołudnie. Nazywaj reguły od usługi i zakresu źródłowego, trzymaj je razem z -Group, i czytaj je ponownie, gdy definicja puli się zmieni. Inwentarz reguł, który możesz przejrzeć na jednym ekranie, bije poprawną regułę, której nikt nie potrafi znaleźć.

Zmieniaj kategorię tylko wtedy, gdy kategoria jest decyzją

Przełączenie interfejsu na Prywatny też działa i jest złym ustawieniem domyślnym. Profil Prywatny niesie długą listę wbudowanych reguł zezwalających, obejmujących udostępnianie plików i drukarek, odnajdowanie sieci, pulpit zdalny i więcej w zależności od podstawy, więc przeklasyfikowanie adaptera VPN włącza je wszystkie naraz dla każdego klienta w tunelu. Jedna ograniczona reguła przyznaje jedną usługę jednemu zakresowi. Na laptopie, który łączy się także z niezaufanymi sieciami, ta różnica nie jest kosmetyczna.

Są przypadki, w których klasyfikacja jest naprawdę błędna: tunel zawsze włączony lub lokacja-lokacja przenoszący podsieć biurową to zaufana infrastruktura, a oznaczenie tego adaptera jako Prywatny jest uzasadnioną decyzją projektową, podejmowaną raz przez politykę, a nie na każde zgłoszenie. Gdy to robisz, zrób to jawnie:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Na zarządzanym urządzeniu sprawdź najpierw, czy ustawieniem zarządza zasada grupy lub linia bazowa MDM. Jeśli tak, lokalna zmiana zostanie cofnięta przy następnym odświeżeniu, a gpresult /h wskaże zasadę, która nią zarządza; napraw to tam, a nie na punkcie końcowym.

Zweryfikuj z obu stron i zostaw ślad

Zweryfikuj przepływ zgłoszony przez użytkownika, z klienta, po zmianie:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Następnie zamknij pętlę wokół rzeczy, które zepsują się w przyszłym tygodniu. Uruchom ponownie host i przetestuj ponownie, ponieważ reguła ograniczona do złego profilu działa dalej, dopóki adapter nie wróci w innej kategorii. Przetestuj z drugiego klienta, bo jeden klient z nieaktualną dzierżawą może ukryć niezgodność puli. Policz reguły dodane wobec usuniętych, ponieważ nakładające się wyjątki to sposób, w jaki poprawka z dwóch linii staje się polityką filtrowania, której nikt nie może przejrzeć.

Zanim uznasz to za zrobione:

• Profil wymieniony w regule to profil interfejsu, przez który dociera ruch.
• Zakres zdalny to pula VPN, a ta pula odpowiada temu, co serwer faktycznie przydziela.
• Żadna dodana przez ciebie reguła nie używa -RemoteAddress Any w profilu Publicznym.
• Niczego nie wyłączono, aby test przeszedł, a każda zmiana kategorii zapisuje, kto ją zatwierdził.