VPN-kliënte word deur die Windows se openbare firewallprofiel geblokkeer

Jou tonnel is op, die poort antwoord op ping, en die lêerdeling keer nog steeds uit. Dié kombinasie is selde 'n roeteringsprobleem: Windows het die VPN-adapter se subnet in die Openbare profiel gesit, en elke toelaatreël wat vir Privaat of Domein geskryf is, is nooit toegepas nie. Ek het dit al op skootrekenaars teëgekom wat die kantoor maklik bereik en op RRAS-bedienerase wat elke ander kliënt bedien, en die herstelling is kort sodra jy die betrokke profiel naamgee. Hier is die volgorde waarin ek werk, met die kontrole wat jou sê wanneer om voor die volgende stap te stop.

Bepaal op watter profiel die verkeer werklik aankom

Windows se firewall het nie een enkele globale modus nie. Elke gekoppelde koppelvlak dra 'n kategorie, en inkomende pakkette word teen die kategorie van die koppelvlak waarop hulle aankom gefiltreer, dus die VPN-adapter se profiel bepaal wat 'n kliënt in die tonnel kan bereik, nie die Wi-Fi- of Ethernet-adapter langsaan nie. Lees albei feite voordat jy enigiets verander:

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

By 'n standaard OpenVPN- of WireGuard-installasie verskyn die VPN-adapter as 'n ongeïdentifiseerde netwerk en beland in Openbaar, wat die verstek is vir enige netwerk wat Windows nie kan klassifiseer nie: geen domeinbeheerder het daaroor geantwoord nie en geen poortprofiel het gepas nie. Die koppelvlak se naam maak hier nie saak nie, so om die adapter "VPN" of "Corp" te noem, verander niks. DomainAuthenticated vereis 'n masjien wat aan die domein gekoppel is wat werklik 'n domeinbeheerder oor daardie koppelvlak kan bereik; 'n gesplete tonnel wat net een subnet dra, sal nie aan die vereiste voldoen nie.

As die reël wat jy nodig het reeds tot die VPN-poel beperk is en reeds op die kategorie van toepassing is wat jy pas gelees het, stop hier: filter is nie jou laag nie, en die volgende plek om te kyk is die dienskonfigurasie. Daardie kontrole neem tien sekondes en spaar 'n uur se reëlredigering. Die kategoriename en wat elkeen dek, is gedokumenteer in die verwysing vir Get-NetConnectionProfile.

Bevestig filtering, nie roetering nie, voordat jy reëls wysig

Ping is 'n swak toets. ICMP kan deurkom terwyl die dienspoort laat val word, en 'n gasheer kan uit die LAN antwoord terwyl hy dieselfde versoek oor die tonnel weier. Toets die poort wat die kliënt nodig het, vanaf die kliënt:

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

As die poorttoets misluk, skei die twee lae. 'n Tonnel- of roetefout wys gewoonlik as geen antwoord van die poortadres nie, terwyl 'n firewall-lating 'n poort wys wat antwoord en 'n dienspoort wat nie antwoord nie. Op 'n Windows-bediener wat die poel deur RRAS publiseer, hardloop dieselfde toets vanaf 'n kliënt en lees die bediener se eie profiel: die RAS-koppelvlak kan in 'n kategorie sit waarvan die inkomende reëls nooit die kliëntreeks noem nie, en dit is hoekom die masjien sy LAN bedien en elke kliënt in die tonnel weier.

Wanneer die resultaat nog dubbelsinnig is, teken die latings vir die betrokke profiel aan en lees hulle:

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

Inskrywings wat die kliëntadres en -poort met DROP noem, is beslissend, en hulle sê ook watter reël ontbreek het. 'n Log met niks in terwyl die kliënt se SYN nooit verskyn nie, dui op iets voor die gasheer, so gaan terug na die tonnel, die NAT-reël of die poelroete voordat jy aan 'n ander firewall-voorwerp raak.

Beperk een inkomende reël tot die kliëntpoel

Die herstelling is een inkomende toelaatreël waarvan die afgeleë adres die poel is, nie die hele wêreld nie. Vanaf 'n verhoogde sessie:

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

Wanneer die diens 'n enkele binêre lêer is, verkies 'n programbeperkte reël met -Program eerder as 'n poortlys; dit beperk die uitsondering sowel tot die proses as tot die bronreeks.

Profielkeuse is waar dieselfde fout in die ander rigting gemaak word. -Profile Public is genoeg wanneer die adapter Openbaar is en Openbaar bly. -Profile Any is verdedigbaar wanneer die diens moet werk ongeag hoe Windows die adapter klassifiseer, maar net terwyl die afgeleë omvang bly. Wat nooit verdedigbaar is nie, is -RemoteAddress Any op die Openbare profiel: daardie reël volg die skootrekenaar in elke kafee- en hotelnetwerk waarby hy aansluit en maak die poort oop vir elkeen wat daardie subnet deel.

Teken die poel langs die reël aan. -RemoteAddress 10.8.0.0/24 hou stilweg op om te pas op die dag wat die VPN-poel hernommer word, en die fout lyk presies soos die oorspronklike fout, daarom kos dit 'n tweede middag. Noem reëls na die diens en die bronreeks, hou hulle saam met -Group en lees hulle weer wanneer die poeldefinisie verander. 'n Reëlinventaris wat jy op een skerm kan ouditeer, klop 'n korrekte reël wat niemand kan vind nie.

Verander die kategorie net wanneer die kategorie die besluit is

Om die koppelvlak na Privaat te skakel werk ook, en dit is die verkeerde verstek. Die Privaat-profiel dra 'n lang lys ingeboude toelaatreëls wat lêer- en drukkerdeling, netwerkontdekking, afgeleë lessenaar en meer dek, afhangend van die basislyn, so om die VPN-adapter te herklassifiseer aktiveer hulle almal vir elke kliënt in die tonnel gelyktydig. Een beperkte reël verleen een diens aan een reeks. Op 'n skootrekenaar wat ook by onbetroubare netwerke aansluit, is daardie verskil nie kosmeties nie.

Daar is gevalle waar die klassifikasie werklik verkeerd is: 'n altyd-aan- of werf-tot-werf-tonnel wat 'n kantoorsubnet dra, is vertroude infrastruktuur, en om daardie adapter Privaat te merk is 'n wettige ontwerpkeuse wat een keer per beleid gemaak word, nie per kaartjie nie. Wanneer jy dit doen, doen dit uitdruklik:

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

Kontroleer eers op 'n bestuurde toestel of 'n groepsbeleid of 'n MDM-basislyn die instelling besit. As dit wel doen, word die plaaslike verandering by die volgende opdatering ongedaan gemaak, en gpresult /h sal die beleid noem wat dit besit; maak dit daar reg, nie op die eindpunt nie.

Verifieer van beide kante en laat 'n spoor

Verifieer die vloei wat die gebruiker gerapporteer het, vanaf die kliënt, ná die verandering:

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

Sluit dan die lus op die dinge wat volgende week breek. Herbegin die gasheer en toets weer, want 'n reël wat tot die verkeerde profiel beperk is, werk aan tot die adapter in 'n ander kategorie terugkom. Toets vanaf 'n tweede kliënt, want een kliënt met 'n verouderde huurkontrak kan 'n poelwanverhouding verberg. Tel die reëls wat jy bygevoeg het teen dié wat jy verwyder het, want oorvleuelende uitsonderings is hoe 'n tweereëlige regstelling 'n filterbeleid word wat niemand kan hersien nie.

Voordat jy dit klaar noem:

• Die profiel wat in die reël genoem word, is die profiel op die koppelvlak waarop die verkeer aankom.
• Die afgeleë omvang is die VPN-poel, en daardie poel stem ooreen met wat die bediener werklik uitdeel.
• Geen reël wat jy bygevoeg het, gebruik -RemoteAddress Any op die Openbare profiel nie.
• Niks is gedeaktiveer om die toets te laat slaag nie, en elke kategorieverandering teken aan wie dit goedgekeur het.