Proč váš adaptér VPN zůstává ve veřejném profilu brány firewall
Přihlášení do domény nezařazuje síť jako doménovou a Privátní není náhradou. Přečtěte si profil pravidla a potom počítač, který ho vynucuje.
Tunel je navázán, účet se ověřil v doméně a Windows přesto označuje připojení jako veřejné. Pravidlo brány firewall napsané pro doménový profil se tedy nepoužije a sdílená složka zůstává nedostupná. Obvyklý pokus o opravu spočívá v nastavení adaptéru na privátní, což změní, která pravidla platí, ale na ověřování nemění nic. Označení i oprava jsou široce nepochopeny a jejich oddělení vyžaduje tři příkazy.
Účet, který se připojil, není kategorií sítě
Během připojení VPN se přijímají dvě různá rozhodnutí a snadno se zamění. Brána rozhoduje, zda se účet smí připojit. Windows rozhoduje, jak výslednou síť zařadit, a toto zařazení určuje, která pravidla brány firewall se na rozhraní použijí.
Úspěšné ověření v doméně na bráně je dokladem o účtu. Není to doklad o tom, že koncový bod ověřil síť vůči řadiči domény, což je přesně to, co doménová kategorie představuje.
Proto může být počítač připojen k doméně, připojovat se doménovým účtem a přesto zobrazovat veřejné. Zařazení je místní určení o síti, nikoli tvrzení o přihlašovacích údajích, které tunel otevřely. Účet může být zcela platný, zatímco označení zůstává tam, kde začalo.
Tři kategorie, z nichž jednu nemůžete nastavit
Windows nabízí tři kategorie a jen dvě z nich může správce přiřadit. Třetí určuje operační systém poté, co síť úspěšně ověří vůči řadiči domény.
| Category | How it is assigned | What it affects |
|---|---|---|
| Public | Default for unidentified networks, or set manually | Rules scoped to the public profile |
| Private | Set manually, or by the user on a trusted network | Rules scoped to the private profile |
| DomainAuthenticated | Determined by Windows after domain authentication | Rules scoped to the domain profile |
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated
Třetí příkaz selže a jde o dokumentované chování, nikoli o problém s oprávněním. Referenční dokumentace samotného cmdletu uvádí, že doménovou kategorii takto přiřadit nelze, protože ji Windows odvozuje z ověření v doméně. Vidět chybu je užitečné potvrzení, že kategorie je důsledek, nikoli nastavení.
Přečtěte první příkaz na koncovém bodu, jehož provoz je blokován. Zařazení vlastního rozhraní brány vám nic neřekne o tom, jak každá připojující se stanice zařadila svůj tunel.
Pravidla se drží profilu, pro který byla napsána
Jakmile kategorii znáte, chybějící přístup se obvykle sám vysvětlí. Každé pravidlo Windows Firewall nese rozsah profilu a pravidlo omezené na doménu neplatí, když je rozhraní veřejné. Tři příkazy z toho udělají odpověď místo teorie a třetí zachytí případ, kdy profil nikdy nebyl problémem:
(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction
Druhý příkaz je ten, který mění neurčitou zprávu v opravu. Pokud je pravidlo omezeno na rozsah vzdálených adres, který nezahrnuje fond VPN, nepomůže ani změna profilu.
Zkontrolujte také výchozí akci pro příchozí provoz. Na počítači, kde je příchozí provoz ve výchozím nastavení blokován, chybějící povolovací pravidlo vytváří ticho místo odmítnutí. Z pohledu klienta to vypadá stejně jako selhání směrování, a proto tolik těchto požadavků začíná nesprávným předpokladem.
Zjistěte, který počítač pravidlo vynucuje
Než změníte kategorii, zjistěte, kde k blokování dochází. Server, který hostuje sdílenou složku, může mít vlastní bránu firewall a její pravidla platí pro provoz přicházející z fondu VPN bez ohledu na to, jak klient označil svůj adaptér. Odmítnutí tam je neviditelné pro každý místní příkaz, který spustíte, a klientská strana hlásí jen to, že prostředek není dostupný. Otestujte vlastní pravidla cíle, než sáhnete na zařazení klienta.
Otestujte cestu z klienta na konkrétní port a poté ji porovnejte s testem z jiného hostitele ve stejné VPN. Pokud selžou oba, problém je v cíli nebo na cestě. Pokud selže jen jeden, rozdíl je místní pro daný počítač a kategorie profilu se stává pravděpodobnou příčinou.
Mějte na paměti i směr. Pravidlo, které povoluje příchozí SMB, neudělá nic pro klienta, jehož vlastní odchozí pravidlo blokuje stejný provoz. Z okna průzkumníka souborů jsou obě selhání nerozeznatelná, proto testujte každý směr zvlášť, než cokoli upravíte.
Co dělat místo přejmenování všeho
Převést neidentifikovanou síť na privátní, aby vyhověla širokému pravidlu, je skutečná změna se skutečnými důsledky. Privátní profil obvykle povoluje více zjišťování a více příchozího provozu než veřejný.
Pokud je cílem, aby se konkrétní služba dostala ke klientům VPN, omezte pravidlo vzdálenou adresou, nikoli profilem. Vyjadřuje to záměr přesně, funguje bez ohledu na zařazení a nezávisí na tom, zda Windows správně odhadne virtuální adaptér. Přežije také aktualizaci klienta, která rozhraní překlasifikuje. Zapište fond do pravidla a další člověk přečte záměr, aniž by se musel ptát.
Pokud je doménová kategorie skutečně očekávána a nikdy se neobjeví, jde o samostatné vyšetřování. Zkontrolujte, zda je počítač připojen k doméně, zda přes tunel dosáhne řadiče domény a zda je zabezpečený kanál v pořádku. Tyto tři příkazy to zodpoví bez jediné úpravy registru:
Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com
Tyto tři odpovídají na to, zda koncový bod mohl síť vůbec ověřit. Pokud nedosáhne na řadič, doménová kategorie nebude nikdy přiřazena, ať se adaptér resetuje sebevíc. Pravidlo brány firewall, za kterým jste pátrali, nikdy nebylo skutečným problémem a označení bylo příznakem rozbité cesty, nikoli příčinou.