VPN-klienter blokeret af Windows' offentlige firewallprofil

Din tunnel er oppe, gatewayen svarer på ping, og filudvekslingen går stadig i timeout. Den kombination er sjældent et ruteproblem: Windows har lagt VPN-adapterens undernet i profilen Offentlig, og enhver tilladelsesregel, der er skrevet til Privat eller Domæne, blev aldrig anvendt. Jeg har oplevet det på laptops, der fint når kontoret, og på RRAS-servere, der betjener alle andre klienter, og reparationen er kort, når først du navngiver profilen, der er i spil. Her er den rækkefølge, jeg arbejder i, med den kontrol, der fortæller dig, at du skal stoppe før næste trin.

Find ud af, hvilken profil trafikken faktisk ankommer på

Windows Firewall har ikke én global tilstand. Hver tilsluttet grænseflade bærer en kategori, og indgående pakker filtreres mod kategorien af den grænseflade, de ankommer på, så det er VPN-adapterens profil, der afgør, hvad en klient i tunnelen kan nå, og ikke Wi-Fi- eller Ethernet-adapteren ved siden af. Læs begge fakta, før du ændrer noget:

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

Ved en standardinstallation af OpenVPN eller WireGuard vises VPN-adapteren som et ikke-identificeret netværk og ender i Offentlig, som er standarden for ethvert netværk, Windows ikke kan klassificere: ingen domænecontroller svarede over det, og ingen gatewayprofil matchede. Grænsefladens navn er irrelevant her, så det ændrer intet at kalde adapteren “VPN” eller “Corp”. DomainAuthenticated kræver en maskine, der er tilknyttet domænet , som faktisk kan nå en domænecontroller over den grænseflade; en split tunnel, der kun bærer ét undernet, opfylder ikke kravet.

Hvis den regel, du har brug for, allerede er afgrænset til VPN-poolen og allerede gælder for den kategori, du netop har læst, så stop her: filtrering er ikke dit lag, og det næste sted at kigge er servicekonfigurationen. Den kontrol tager ti sekunder og sparer en times regelredigering. Kategorinavnene og det, hver kategori dækker, er dokumenteret i referencen for Get-NetConnectionProfile.

Bekræft filtrering, ikke routing, før du redigerer regler

Ping er en svag test. ICMP kan passere, mens serviceporten droppes, og en vært kan svare fra LAN'et, mens den afviser den samme anmodning over tunnelen. Test den port, klienten har brug for, fra klienten:

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

Hvis porttesten fejler, så skil de to lag ad. En tunnel- eller rutefejl viser sig normalt som slet intet svar fra gatewayadressen, mens et firewall-drop viser en gateway, der svarer, og en serviceport, der ikke gør. På en Windows-server, der publicerer poolen via RRAS, skal du køre den samme test fra en klient og læse serverens egen profil: RAS-grænsefladen kan sidde i en kategori, hvis indgående regler aldrig nævner klientområdet, og derfor betjener maskinen sit LAN og afviser enhver klient i tunnelen.

Når resultatet stadig er tvetydigt, så log drops for den profil, der er i spil, og læs dem:

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

Poster, der nævner klientadressen og porten med DROP, er afgørende, og de fortæller dig også, hvilken regel der manglede. En log uden noget i, mens klientens SYN aldrig vises, peger opstrøms for værten, så gå tilbage til tunnelen, NAT-reglen eller poolruten, før du rører et andet firewallobjekt.

Afgræns én indgående regel til klientpoolen

Reparationen er én indgående tilladelsesregel, hvis fjernadresse er poolen, ikke hele verden. Fra en forhøjet session:

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

Når tjenesten er én enkelt binær fil, så foretræk en programafgrænset regel med -Program frem for en portliste; det begrænser undtagelsen både til processen og til kildeområdet.

Profilvalget er der, hvor den samme fejl begås i den anden retning. -Profile Public er nok, når adapteren er Offentlig og forbliver Offentlig. -Profile Any er forsvarligt, når tjenesten skal virke, uanset hvordan Windows klassificerer adapteren, men kun så længe fjernområdet bliver. Det, der aldrig er forsvarligt, er -RemoteAddress Any på profilen Offentlig: den regel følger laptop'en ind i hvert café- og hotelnetværk, den tilslutter sig, og åbner porten for enhver, der deler det undernet.

Notér poolen ved siden af reglen. -RemoteAddress 10.8.0.0/24 holder stille op med at matche den dag, VPN-poolen omnummereres, og fejlen ser præcis ud som den oprindelige bug, og derfor koster den endnu en eftermiddag. Navngiv regler efter tjenesten og kildeområdet, hold dem sammen med -Group, og læs dem igen, hver gang pooldefinitionen ændres. Et regelkatalog, du kan revidere på én skærm, slår en korrekt regel, som ingen kan finde.

Skift kun kategorien, når kategorien er beslutningen

At skifte grænsefladen til Privat virker også, og det er den forkerte standard. Profilen Privat indeholder en lang liste indbyggede tilladelsesregler, der dækker fil- og printerdeling, netværksregistrering, fjernskrivebord og mere afhængigt af baseline, så omklassificering af VPN-adapteren aktiverer dem alle for hver klient i tunnelen på én gang. Én afgrænset regel giver én tjeneste til ét område. På en laptop, der også tilslutter sig ikke-betroede netværk, er den forskel ikke kosmetisk.

Der er tilfælde, hvor klassificeringen virkelig er forkert: en altid aktiv eller site-to-site-tunnel, der bærer et kontorundernet, er betroet infrastruktur, og at markere den adapter som Privat er et legitimt designvalg, truffet én gang efter politik og ikke per sag. Når du gør det, så gør det eksplicit:

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

Kontrollér først på en administreret enhed, om en gruppepolitik eller en MDM-baseline ejer indstillingen. Hvis den gør, bliver den lokale ændring rullet tilbage ved næste opdatering, og gpresult /h vil navngive den politik, der ejer den; ret det dér og ikke på slutpunktet.

Verificér fra begge ender, og efterlad et spor

Verificér den flow, brugeren rapporterede, fra klienten, efter ændringen:

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

Luk så kredsen om det, der går i stykker i næste uge. Genstart værten, og test igen, for en regel, der er afgrænset til den forkerte profil, virker, indtil adapteren kommer tilbage i en anden kategori. Test fra en anden klient, for én klient med et forældet lease kan skjule en afvigelse i poolen. Tæl de regler, du tilføjede, op mod dem, du fjernede, for overlappende undtagelser er måden, hvorpå en rettelse på to linjer bliver til en filtreringspolitik, som ingen kan gennemgå.

Før du kalder det færdigt:

• Profilen, der nævnes i reglen, er profilen på den grænseflade, trafikken ankommer på.
• Fjernområdet er VPN-poolen, og den pool svarer til det, serveren faktisk uddeler.
• Ingen regel, du tilføjede, bruger -RemoteAddress Any på profilen Offentlig.
• Intet blev deaktiveret for at få testen til at bestå, og enhver kategorieændring registrerer, hvem der godkendte den.