VPN-klanten blokkearre troch it iepenbiere Windows-firewallprofyl

Windows klassifisearret de VPN-adapter as Iepenbier, dus jo LAN-regels jilde nea. Kontrolearje it profyl, behein ien yngeande regel ta de pool en ferifiearje dan de poarte.

Jo tunnel is omheech, de gateway antwurdet op ping, en de bestandieling rint noch altyd yn in time-out. Dy kombinaasje is selden in routeringsprobleem: Windows hat it subnet fan 'e VPN-adapter yn it Iepenbiere profyl set, en elke tastieningsregel dy't foar Privee of Domein skreaun is, is nea tapast. Ik bin dit tsjinkaam op laptops dy't it kantoar prima berikke en op RRAS-tsjinners dy't elke oare klant betsjinje, en de reparaasje is koart sadree't jo it profyl neame dat yn it spul is. Hjir is de folchoarder wêryn't ik wurkje, mei de kontrôle dy't jo seit wannear't jo stopje moatte foar de folgjende stap.

Sykje út hokker profyl it ferkear eins oankomt

De Windows-firewall hat gjin ien globale modus. Elk ferbûn ynterface draacht in kategory, en ynkommende pakketten wurde filtere tsjin de kategory fan it ynterface wêrop't se oankomme, dus it profyl fan 'e VPN-adapter beslút wat in klant yn 'e tunnel berikke kin, net de Wi-Fi- of Ethernet-adapter njonken. Lês beide feiten foardat jo wat feroarje:

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

By in standertynstallaasje fan OpenVPN of WireGuard ferskynt de VPN-adapter as in net-identifisearre netwurk en bedarret yn Iepenbier, dat is de standert foar elk netwurk dat Windows net klassifisearje kin: gjin domeinbehearder hat der antwurd op jûn en gjin gatewayprofyl kaam oerien. De namme fan it ynterface docht hjir net ta, dus de adapter "VPN" of "Corp" neame feroaret neat. DomainAuthenticated freget in masine dy't oan it domein keppele is dy't wirklik in domeinbehearder berikke kin oer dat ynterface; in splitst tunnel dy't mar ien subnet draacht, sil net oan 'e eask foldwaan.

As de regel dy't jo nedich hawwe al ta de VPN-pool beheind is en al jildt foar de kategory dy't jo krekt lêzen, stop hjir: filterjen is net jo laach, en it folgjende plak om te sjen is de tsjinstkonfiguraasje. Dy kontrôle duorret tsien sekonden en sparret in oere regelbewurking. De kategorynammen en wat elk beslacht binne dokumintearre yn 'e referinsje foar Get-NetConnectionProfile.

Befêstigje filterjen, net routering, foardat jo regels bewurkje

Ping is in swakke test. ICMP kin trochkomme wylst de tsjinstpoarte weilitten wurdt, en in host kin fan 'e LAN antwurdzje wylst er itselde fersyk oer de tunnel wegeret. Test de poarte dy't de klant nedich hat, fan 'e klant:

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

As de poartetest mislearret, skied dan de twa lagen. In tunnel- of rûteflater docht him meastentiids foar as gjin antwurd fan it gatewayadres, wylst in firewall-wurding in gateway sjen lit dy't antwurdet en in tsjinstpoarte dy't dat net docht. Op in Windows-tsjinner dy't de pool fia RRAS publisearret, rin dan deselde test fan in klant en lês it eigen profyl fan 'e tsjinner: it RAS-ynterface kin yn in kategory sitte waans yngeande regels nea it klantberik neame, en dêrom betsjinnet de masine syn LAN en wegeret elke klant yn 'e tunnel.

As it resultaat noch dûbelsinnich is, log dan de wurdingen foar it profyl yn 't spul en lês se:

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

Yngongen dy't it klantadres en de poarte mei DROP neame, binne beslissend, en se fertelle jo ek hokker regel miste. In log sûnder wat deryn, wylst de SYN fan 'e klant nea ferskynt, wiist boppe de host, dus gean werom nei de tunnel, de NAT-regel of de poolrûte foardat jo in oar firewallobjekt oanreitsje.

Behein ien yngeande regel ta de klantpool

De reparaasje is ien yngeande tastieningsregel wêrfan't it fiere adres de pool is, net de hiele wrâld. Fan in ferhege sesje:

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

As de tsjinst ien binêr bestân is, foarkies dan in programmabeheinde regel mei -Program ynstee fan in poartelist; dat beheint de útsûndering sawol ta it proses as ta it boarneberik.

Profylkar is wêr't deselde flater yn 'e oare rjochting makke wurdt. -Profile Public is genôch as de adapter Iepenbier is en Iepenbier bliuwt. -Profile Any is ferdigenber as de tsjinst wurkje moat, hoe't Windows de adapter ek klassifisearret, mar allinnich salang't it fiere berik bliuwt. Wat nea ferdigenber is, is -RemoteAddress Any op it Iepenbiere profyl: dy regel folget de laptop yn elk kafee- en hotelnetwurk dêr't er by oanslút en iepenet de poarte foar elkenien dy't dat subnet dielt.

Notearje de pool njonken de regel. -RemoteAddress 10.8.0.0/24 hâldt stilwei op mei oerienkomme op 'e dei dat de VPN-pool opnij nûmere wurdt, en de flater liket krekt op 'e oarspronklike bug, dêrom kostet it in twadde middei. Neam regels nei de tsjinst en it boarneberik, hâld se byinoar mei -Group, en lês se opnij as de pooldifyzje feroaret. In regelinventaris dy't jo op ien skerm kontrolearje kinne, ferslacht in korrekte regel dy't nimmen fine kin.

Feroarje de kategory allinnich as de kategory de beslissing is

It ynterface op Privee sette wurket ek, en it is de ferkearde standert. It Privee-profyl draacht in lange list mei ynboude tastieningsregels, dy't bestân- en printerdieling, netwurkûntdekking, ôfstânbuordsje en mear dekke ôfhinklik fan 'e basisline, dus it werklassifisearjen fan 'e VPN-adapter skeakelet se allegear tagelyk yn foar elke klant yn 'e tunnel. Ien beheinde regel jout ien tsjinst oan ien berik. Op in laptop dy't ek by netbetroubere netwurken oanslút, is dat ferskil net kosmetysk.

Der binne gefallen wêr't de klassifikaasje echt ferkeard is: in altyd-oan- of site-nei-site-tunnel dy't in kantoarsubnet draacht, is fertroude ynfrastruktuer, en it markearjen fan dy adapter as Privee is in legitime ûntwerpkar dy't ien kear troch belied makke wurdt, net per ticket. As jo it dogge, doch it eksplisyt:

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

Kontrolearje op in beheard apparaat earst oft in Groepsbelied of in MDM-basisline de ynstelling besit. As dat sa is, wurdt de lokale feroaring by de folgjende fernijing ûngedien makke, en gpresult /h sil it belied neame dat it besit; reparearje it dêr, net op it einpunt.

Ferifiearje fan beide kanten en lit in spoar efter

Ferifiearje de stream dy't de brûker rapporteare, fan 'e klant, nei de feroaring:

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

Slút dan de lus oer de dingen dy't folgjende wike brekke. Werstart de host en test opnij, want in regel dy't ta it ferkearde profyl beheind is, bliuwt wurkjen oant de adapter yn in oare kategory weromkomt. Test fan in twadde klant, want ien klant mei in ferâldere lease kin in poalôfwiking ferbergje. Tel de regels dy't jo tafoege hawwe tsjin dy't jo fuorthelle hawwe, want oerlapjende útsûnderingen binne de manier wêrop in twa-rigelige reparaasje in filterbelied wurdt dat nimmen besjen kin.

Foardat jo it klear neame:

  • It profyl dat yn 'e regel neamd wurdt, is it profyl op it ynterface wêr't it ferkear oankomt.
  • It fiere berik is de VPN-pool, en dy pool komt oerien mei wat de tsjinner eins útdielt.
  • Gjin regel dy't jo tafoege hawwe, brûkt -RemoteAddress Any op it Iepenbiere profyl.
  • Der is neat útskeakele om de test te slagjen, en elke kategoryferoaring registrearret wa't it goedkard hat.

Relatearre artikelen