Waarom jou VPN-adapter op die publieke firewallprofiel bly
Aanmelding by 'n domein klassifiseer nie die netwerk as domein nie, en Privaat is nie 'n plaasvervanger nie. Lees eers die profiel van die reël en dan die masjien wat dit afdwing.
Die tonnel is op, die rekening is by die domein geauthentiseer, en Windows noem die verbinding steeds Publiek. 'n Firewallreël wat vir die domeinprofiel geskryf is, geld dus nie, en die lêerdeling bly ontoeganklik. Die gewone poging tot 'n oplossing is om die adapter op Privaat te stel, wat verander watter reëls geld sonder om iets aan die verifikasie te verander. Beide die etiket en die oplossing word algemeen verkeerd verstaan, en om hulle te skei verg drie opdragte.
Die rekening wat ingeskakel het, is nie die netwerk se kategorie nie
Twee verskillende besluite word tydens 'n VPN-verbinding geneem, en dit is maklik om hulle te verwar. Die poort besluit of die rekening mag koppel. Windows besluit hoe om die resulterende netwerk te klassifiseer, en daardie klassifikasie bepaal watter firewallreëls op die koppelvlak geld.
'n Suksesvolle domeinverifikasie by die poort is bewyse oor die rekening. Dit is nie bewyse dat die eindpunt die netwerk teen 'n domeinkontroleerder geauthentiseer het nie, en dit is presies wat die domeinkategorie verteenwoordig.
Daarom kan 'n masjien by 'n domein aangesluit wees, met 'n domeinrekening koppel en steeds Publiek wys. Die klassifikasie is 'n plaaslike bepaling oor die netwerk, nie 'n verklaring oor die geloofsbriewe wat die tonnel oopgemaak het nie. Die rekening kan heeltemal geldig wees terwyl die etiket bly waar dit begin het.
Drie kategorieë, waarvan jy een nie kan stel nie
Windows bied drie kategorieë, en net twee daarvan kan deur 'n administrateur toegewys word. Die derde word deur die bedryfstelsel bepaal nadat dit die netwerk suksesvol teen 'n domeinkontroleerder geauthentiseer het.
| 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 DomainAuthenticatedDie derde opdrag misluk, en dit is die gedokumenteerde gedrag eerder as 'n toestemmingsprobleem. Die cmdlet se eie verwysing sê dat die domeinkategorie nie so toegewys kan word nie, want Windows lei dit uit domeinverifikasie af. Om die fout te sien, is 'n nuttige bevestiging dat die kategorie 'n gevolg is eerder as 'n instelling.
Lees die eerste opdrag op die eindpunt wie se verkeer geblokkeer word. Die klassifikasie van 'n poort se eie koppelvlak sê niks oor hoe elke werkstasie sy tonnel geklassifiseer het nie.
Reëls volg die profiel waarvoor hulle geskryf is
Sodra jy die kategorie ken, verklaar die ontbrekende toegang gewoonlik homself. Elke Windows Firewall-reël dra 'n profielomvang, en 'n reël wat op domein gerig is, geld nie wanneer die koppelvlak publiek is nie. Drie opdragte verander dit in 'n antwoord eerder as 'n teorie, en die derde een vang die geval waar die profiel nooit die probleem was nie:
(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionDie tweede opdrag is die een wat 'n vae verslag in 'n oplossing verander. As die reël op 'n afgeleë adresreeks gerig is wat nie die VPN-poel insluit nie, sal die verandering van die profiel ook nie help nie.
Kyk ook na die verstek inkomende aksie. Op 'n masjien waar inkomende verkeer by verstek geblokkeer word, lewer 'n ontbrekende toelaatreël stilte eerder as 'n weiering. Dit lyk van die kliënt se kant identies aan 'n roeteerfout, en daarom begin so baie van hierdie kaartjies met die verkeerde aanname.
Bepaal watter masjien die reël afdwing
Voordat jy 'n kategorie verander, stel vas waar die blokkering plaasvind. Die bediener wat die lêerdeling huisves, kan sy eie firewall hê, en sy reëls geld vir die verkeer wat uit die VPN-poel aankom, ongeag hoe die kliënt sy adapter benoem het. 'n Weiering daar is onsigbaar vir elke plaaslike opdrag wat jy uitvoer, en die kliëntekant meld net dat die hulpbron nie beskikbaar is nie. Toets die bestemming se eie reëls voordat jy aan die kliënt se klassifikasie raak.
Toets van die kliënt na die spesifieke poort en vergelyk dan met 'n toets van 'n ander gasheer op dieselfde VPN. As albei misluk, is die probleem by die bestemming of op die pad. As net een misluk, is die verskil plaaslik aan daardie masjien, en die profielkategorie word 'n waarskynlike oorsaak.
Hou ook die rigting in gedagte. 'n Reël wat inkomende SMB toelaat, doen niks vir 'n kliënt wie se eie uitgaande reël dieselfde verkeer blokkeer nie. Vanuit 'n lêerverkenner-venster is die twee mislukkings ononderskeibaar, so toets elke rigting afsonderlik voordat jy iets wysig.
Wat om te doen in plaas daarvan om alles te herbenoem
Om 'n ongeïdentifiseerde netwerk Privaat te maak om 'n breë reël te bevredig, is 'n werklike verandering met werklike gevolge. Die privaat profiel laat gewoonlik meer ontdekking en meer inkomende verkeer toe as die publieke een.
As die doel is om 'n spesifieke diens by die VPN-kliënte te laat uitkom, rig die reël op afgeleë adres eerder as op profiel. Dit druk die bedoeling presies uit, werk ongeag die klassifikasie en hang nie daarvan af dat Windows korrek raai oor 'n virtuele adapter nie. Dit oorleef ook 'n kliëntopdatering wat die koppelvlak herklassifiseer. Skryf die poel in die reël en die volgende persoon kan die bedoeling lees sonder om te vra.
As die domeinkategorie werklik verwag word en nooit verskyn nie, is dit 'n afsonderlike ondersoek. Kyk of die masjien by 'n domein aangesluit is, of dit 'n domeinkontroleerder oor die tonnel kan bereik en of die veilige kanaal gesond is. Daardie drie opdragte beantwoord dit sonder 'n enkele registerwysiging:
Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.comDaardie drie antwoord of die eindpunt die netwerk hoegenaamd kon authentiseer. As dit nie 'n kontroleerder kan bereik nie, sal die domeinkategorie nooit toegewys word nie, maak nie saak hoe dikwels die adapter herstel word nie. Die firewallreël agtervolg jy was nooit die regte probleem nie, en die etiket was 'n simptoom van 'n gebroke pad eerder as 'n oorsaak.