Wêrom't jo VPN-adapter op it iepenbiere firewallprofyl bliuwt

De tunnel is aktyf, it akkount is by it domein ferifiearre, en Windows labelt de ferbining noch hieltyd as Iepenbier. Dêrom jildt in firewallregel skreaun foar it domeinprofyl net, en de bestandieling bliuwt ûnberikber. De gebrûklike besykjen ta reparaasje is de adapter op Privee sette, wat feroaret hokker regels jilde sûnder eat oan 'e ferifikaasje te feroarjen. Sawol it label as de reparaasje wurde breed ferkeard begrepen, en har skiede freget trije opdrachten.

It akkount dat ynbelle hat is net de kategory fan it netwurk

By in VPN-ferbining wurde twa ferskate besluten nommen en dy binne maklik te betiizjen. De gateway beslút oft it akkount ferbine mei. Windows beslút hoe't it ûntstiene netwurk klassifisearre wurdt, en dy klassifikaasje bepaalt hokker firewallregels foar de ynterface jilde.

In suksesfolle domeinferifikaasje by de gateway is bewiis oer it akkount. It is gjin bewiis dat it einpunt it netwurk by in domeincontroller ferifiearre hat, en dat is krekt wat de domeinkategory foarstelt.

Dêrom kin in masine oan in domein keppele wêze, ferbine mei in domeinakkount en dochs Iepenbier sjen litte. De klassifikaasje is in lokale bepaling oer it netwurk, gjin útspraak oer de oanmeldgegevens dy't de tunnel iepene hawwe. It akkount kin folslein jildich wêze wylst it label bliuwt dêr't it begon.

Trije kategoryen, wêrfan jo ien net ynstelle kinne

Windows biedt trije kategoryen en mar twa dêrfan kin in behearder tawize. De tredde wurdt bepaald troch it bestjoeringssysteem neidat it it netwurk mei súkses by in domeincontroller ferifiearre hat.

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

De tredde opdracht mislearret, en dat is it dokumintearre gedrach en gjin tastimmingsprobleem. De referinsje fan 'e opdracht sels stelt dat de domeinkategory net sa tawizze kin, om't Windows dy út domeinferifikaasje ôfliedt. De flater sjen is in nuttige befêstiging dat de kategory in gefolch is en gjin ynstelling.

Lês de earste opdracht op it einpunt waans ferkear blokkearre wurdt. De klassifikaasje fan 'e eigen ynterface fan in gateway fertelt jo neat oer hoe't elke ferbinende wurkstasjon syn tunnel klassifisearre hat.

Regels folgje it profyl dêr't se foar skreaun binne

As jo de kategory kenne, ferklearret de ûntbrekkende tagong himsels meastentiids. Elke Windows Firewall-regel draacht in profylberik, en in regel dy't op domein rjochte is jildt net as de ynterface iepenbier is. Trije opdrachten meitsje dêrfan in antwurd ynstee fan in teory, en de tredde fangt it gefal wêryn't it profyl nea it probleem wie:

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

De twadde opdracht is dy't in ûnbeskaat rapport yn in reparaasje feroaret. As de regel beheind is ta in berik fan ôfstân adressen dat de VPN-pool net omfettet, sil it feroarjen fan it profyl ek net helpe.

Kontrolearje ek de standert aksje foar ynkommend ferkear. Op in masine dêr't ynkommend standert blokkearre is, jout in ûntbrekkende tastimmingregel stilte ynstee fan in ôfwizing. Fan 'e kliïntkant liket dat identyk oan in rûtflater, en dêrom begjinne safolle fan dizze tickets mei de ferkearde oanname.

Bepaal hokker masine de regel hanthavenet

Foardat jo in kategory feroarje, stel fêst wêr't de blokkade bart. De server dy't de dieling hostet, kin syn eigen firewall hawwe, en syn regels jilde foar it ferkear dat út 'e VPN-pool komt, hoewol't de kliïnt syn adapter neamd hat. In ôfwizing dêr is ûnsichtber foar elke lokale opdracht dy't jo útfiere, en de kliïntkant meldt allinnich dat de boarne net beskikber is. Test de eigen regels fan 'e bestimming foardat jo de klassifikaasje fan 'e kliïnt oanreitsje.

Test fan 'e kliïnt nei de spesifike poarte en fergelykje dan mei in test fan in oare host yn deselde VPN. As beide mislearje, leit it probleem by de bestimming of op 'e rûte. As mar ien mislearret, is it ferskil lokaal foar dy masine, en wurdt de profylkategory in oannimlike oarsaak.

Hâld ek de rjochting yn 't each. In regel dy't ynkommend SMB tastiet, docht neat foar in kliïnt waans eigen útgeande regel itselde ferkear blokkearret. Fan in finster fan 'e bestandsferkenner binne de beide mislearrings net te ûnderskieden, dus test elke rjochting apart foardat jo eat bewurkje.

Wat te dwaan ynstee fan alles opnij te labeljen

In ûnbekend netwurk Privee meitsje om oan in brede regel te foldwaan is in echte feroaring mei echte gefolgen. It priveeprofyl lit meastentiids mear ûntdekking en mear ynkommend ferkear ta as it iepenbiere.

As it doel is in spesifike tsjinst de VPN-kliïnten berikke te litten, behein de regel dan op ôfstân adres ynstee fan op profyl. Dat drukt de bedoeling krekt út, wurket ûnôfhinklik fan 'e klassifikaasje en hinget net ôf fan it al of net goed rieden fan Windows oer in firtuele adapter. It oerlibbet ek in kliïntfernijing dy't de ynterface opnij klassifisearret. Skriuw de pool yn 'e regel en de folgjende persoan kin de bedoeling lêze sûnder te freegjen.

As de domeinkategory echt ferwachte wurdt en nea ferskynt, is dat in apart ûndersyk. Kontrolearje dat de masine oan in domein keppele is, dat it in domeincontroller troch de tunnel berikke kin en dat it befeilige kanaal sûn is. Dy trije opdrachten beantwurdzje dat sûnder ien registerbewurking:

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

Dy trije beantwurdzje oft it einpunt it netwurk hielendal ferifiearje kinnen hie. As it gjin controller berikke kin, sil de domeinkategory nea tawiisd wurde, hoefolle kearen de adapter ek weromset wurdt. De firewallregel dy't jo efterfolgen wie nea it echte probleem, en it label wie in symptoom fan in brutsen paad en gjin oarsaak.