Dlaczego karta VPN pozostaje w publicznym profilu zapory

Tunel jest aktywny, konto zostało uwierzytelnione w domenie, a Windows nadal oznacza połączenie jako publiczne. Reguła zapory napisana dla profilu domenowego nie obowiązuje, więc udział plików pozostaje nieosiągalny. Typowa próba naprawy polega na ustawieniu karty na prywatną, co zmienia to, które reguły obowiązują, ale nie zmienia niczego w uwierzytelnianiu. Zarówno etykieta, jak i naprawa są powszechnie źle rozumiane, a ich rozdzielenie wymaga trzech poleceń.

Konto, które się połączyło, nie jest kategorią sieci

Podczas połączenia VPN podejmowane są dwie różne decyzje i łatwo je pomylić. Brama decyduje, czy konto może się połączyć. Windows decyduje, jak sklasyfikować powstałą sieć, i ta klasyfikacja określa, które reguły zapory dotyczą interfejsu.

Udane uwierzytelnienie domenowe na bramie jest dowodem dotyczącym konta. Nie jest dowodem, że punkt końcowy uwierzytelnił sieć wobec kontrolera domeny, a właśnie to reprezentuje kategoria domenowa.

Dlatego maszyna może być przyłączona do domeny, łączyć się kontem domenowym i nadal wyświetlać publiczną. Klasyfikacja jest lokalnym ustaleniem dotyczącym sieci, a nie stwierdzeniem o poświadczeniach, które otworzyły tunel. Konto może być całkowicie ważne, podczas gdy etykieta pozostaje tam, gdzie się zaczęła.

Trzy kategorie, z których jednej nie można ustawić

Windows udostępnia trzy kategorie i tylko dwie z nich może przypisać administrator. Trzecią ustala system operacyjny po pomyślnym uwierzytelnieniu sieci wobec kontrolera domeny.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Trzecie polecenie kończy się niepowodzeniem i jest to udokumentowane zachowanie, a nie problem z uprawnieniami. Dokumentacja samego polecenia stwierdza, że kategorii domenowej nie można przypisać w ten sposób, ponieważ Windows wywodzi ją z uwierzytelnienia domenowego. Zobaczenie błędu to użyteczne potwierdzenie, że kategoria jest konsekwencją, a nie ustawieniem.

Odczytaj pierwsze polecenie na punkcie końcowym, którego ruch jest blokowany. Klasyfikacja własnego interfejsu bramy nic nie mówi o tym, jak każda łącząca się stacja robocza sklasyfikowała swój tunel.

Reguły podążają za profilem, dla którego zostały napisane

Gdy znasz kategorię, brakujący dostęp zwykle wyjaśnia się sam. Każda reguła zapory Windows ma zakres profilu, a reguła ograniczona do domeny nie obowiązuje, gdy interfejs jest publiczny. Trzy polecenia zamieniają to w odpowiedź, a nie teorię, a trzecie wyłapuje przypadek, w którym profil nigdy nie był problemem:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Drugie polecenie to to, które zamienia niejasny raport w naprawę. Jeśli reguła jest ograniczona do zakresu adresów zdalnych, który nie obejmuje puli VPN, zmiana profilu też nie pomoże.

Sprawdź także domyślną akcję dla ruchu przychodzącego. Na maszynie, na której ruch przychodzący jest domyślnie blokowany, brakująca reguła zezwalająca daje ciszę zamiast odmowy. Z perspektywy klienta wygląda to identycznie jak błąd routingu, dlatego tak wiele takich zgłoszeń zaczyna się od błędnego założenia.

Ustal, która maszyna egzekwuje regułę

Przed zmianą kategorii ustal, gdzie dochodzi do blokady. Serwer hostujący udział może mieć własną zaporę, a jego reguły dotyczą ruchu przychodzącego z puli VPN niezależnie od tego, jak klient nazwał swoją kartę. Odmowa tam jest niewidoczna dla każdego lokalnego polecenia, które uruchomisz, a strona klienta zgłasza tylko, że zasób jest niedostępny. Przetestuj własne reguły miejsca docelowego, zanim dotkniesz klasyfikacji klienta.

Przetestuj z klienta do konkretnego portu, a następnie porównaj z testem z innego hosta w tej samej sieci VPN. Jeśli oba się nie powiodą, problem jest w miejscu docelowym lub na ścieżce. Jeśli zawiedzie tylko jeden, różnica jest lokalna dla tej maszyny, a kategoria profilu staje się prawdopodobną przyczyną.

Miej na uwadze także kierunek. Reguła zezwalająca na przychodzący SMB nic nie daje klientowi, którego własna reguła wychodząca blokuje ten sam ruch. Z okna Eksploratora plików obu awarii nie da się odróżnić, więc testuj każdy kierunek osobno, zanim cokolwiek zmienisz.

Co zrobić zamiast ponownego etykietowania wszystkiego

Uczynienie nieznanej sieci prywatną, aby spełnić szeroką regułę, jest prawdziwą zmianą z prawdziwymi konsekwencjami. Profil prywatny zwykle zezwala na więcej wykrywania i więcej ruchu przychodzącego niż publiczny.

Jeśli celem jest umożliwienie konkretnej usłudze dotarcia do klientów VPN, ogranicz regułę według adresu zdalnego, a nie profilu. To precyzyjnie wyraża intencję, działa niezależnie od klasyfikacji i nie zależy od tego, czy Windows poprawnie odgadnie kartę wirtualną. Przetrwa też aktualizację klienta, która przeklasyfikuje interfejs. Zapisz pulę w regule, a następna osoba odczyta intencję bez pytania.

Jeśli kategoria domenowa jest naprawdę oczekiwana i nigdy się nie pojawia, to osobne śledztwo. Sprawdź, czy maszyna jest przyłączona do domeny, czy dociera do kontrolera domeny przez tunel i czy bezpieczny kanał jest zdrowy. Te trzy polecenia odpowiadają na to bez ani jednej zmiany w rejestrze:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Te trzy odpowiadają, czy punkt końcowy mógł w ogóle uwierzytelnić sieć. Jeśli nie może dotrzeć do kontrolera, kategoria domenowa nigdy nie zostanie przypisana, niezależnie od liczby resetów karty. Reguła zapory, której ścigaliście, nigdy nie była prawdziwym problemem, a etykieta była objawem zepsutej ścieżki, nie przyczyną.