VPN-klienter blokkert av den offentlige Windows-brannmurprofilen

Windows klassifiserer VPN-adapteren som Offentlig, så LAN-reglene dine gjelder aldri. Kontroller profilen, begrens én innkommende regel til poolen, og verifiser deretter porten.

Tunnelen din er oppe, gatewayen svarer på ping, og filutvekslingen gir fortsatt tidsavbrudd. Den kombinasjonen er sjelden et ruteproblem: Windows har lagt undernettet til VPN-adapteren i profilen Offentlig, og hver tillatelsesregel som er skrevet for Privat eller Domene, ble aldri brukt. Jeg har møtt dette på bærbare maskiner som når kontoret fint, og på RRAS-servere som betjener alle andre klienter, og reparasjonen er kort når du først navngir profilen som er i spill. Her er rekkefølgen jeg arbeider i, med kontrollen som forteller deg at du skal stoppe før neste trinn.

Finn ut hvilken profil trafikken faktisk ankommer på

Windows-brannmuren har ikke én global modus. Hvert tilkoblede grensesnitt bærer en kategori, og innkommende pakker filtreres mot kategorien til grensesnittet de ankommer på, så det er profilen til VPN-adapteren som avgjør hva en klient i tunnelen kan nå, ikke Wi-Fi- eller Ethernet-adapteren ved siden av. Les begge fakta før du endrer noe:

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

Ved en standardinstallasjon av OpenVPN eller WireGuard vises VPN-adapteren som et uidentifisert nettverk og havner i Offentlig, som er standarden for alle nettverk Windows ikke kan klassifisere: ingen domenekontroller svarte over det, og ingen gatewayprofil passet. Navnet på grensesnittet er irrelevant her, så å kalle adapteren «VPN» eller «Corp» endrer ingenting. DomainAuthenticated krever en maskin som er tilknyttet domenet , som faktisk kan nå en domenekontroller over det grensesnittet; en delt tunnel som bare fører ett undernett, oppfyller ikke kravet.

Hvis regelen du trenger allerede er begrenset til VPN-poolen og allerede gjelder for kategorien du nettopp leste, stopp her: filtrering er ikke ditt lag, og neste sted å se er tjenestekonfigurasjonen. Den kontrollen tar ti sekunder og sparer en time med regleredigering. Kategorinavnene og hva hver kategori dekker, er dokumentert i referansen for Get-NetConnectionProfile.

Bekreft filtrering, ikke ruting, før du redigerer regler

Ping er en svak test. ICMP kan passere mens tjenesteporten droppes, og en vert kan svare fra LAN-et mens den avviser den samme forespørselen over tunnelen. Test porten klienten trenger, fra klienten:

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

Hvis porttesten feiler, skill de to lagene. En tunnel- eller rutefeil viser seg vanligvis som ingen svar fra gatewayadressen i det hele tatt, mens en brannmurblokkering viser en gateway som svarer og en tjenesteport som ikke gjør det. På en Windows-server som publiserer poolen via RRAS, kjør den samme testen fra en klient og les serverens egen profil: RAS-grensesnittet kan sitte i en kategori der de innkommende reglene aldri nevner klientområdet, og det er derfor maskinen betjener LAN-et sitt og avviser hver klient i tunnelen.

Når resultatet fortsatt er tvetydig, loggfør droppene for profilen som er i spill og les dem:

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

Oppføringer som navngir klientadressen og porten med DROP er avgjørende, og de forteller deg også hvilken regel som manglet. En logg uten noe i, mens klientens SYN aldri vises, peker oppstrøms for verten, så gå tilbake til tunnelen, NAT-regelen eller poolruten før du rører et annet brannmurobjekt.

Begrens én innkommende regel til klientpoolen

Reparasjonen er én innkommende tillatelsesregel der fjernadressen er poolen, ikke hele verden. Fra en forhøyet økt:

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ærfil, foretrekk en programbegrenset regel med -Program fremfor en portliste; det begrenser unntaket både til prosessen og til kildeområdet.

Profilvalget er der den samme feilen gjøres i motsatt retning. -Profile Public er nok når adapteren er Offentlig og forblir Offentlig. -Profile Any er forsvarlig når tjenesten må virke uansett hvordan Windows klassifiserer adapteren, men bare så lenge fjernområdet blir stående. Det som aldri er forsvarlig, er -RemoteAddress Any på profilen Offentlig: den regelen følger den bærbare maskinen inn i hvert kafé- og hotellnettverk den kobler seg til og åpner porten for alle som deler det undernettet.

Noter poolen ved siden av regelen. -RemoteAddress 10.8.0.0/24 slutter stille å passe den dagen VPN-poolen nummereres på nytt, og feilen ser nøyaktig ut som den opprinnelige feilen, og derfor koster den en ekstra ettermiddag. Navngi regler etter tjenesten og kildeområdet, hold dem sammen med -Group, og les dem på nytt når pooldefinisjonen endres. En regelinventar du kan revidere på én skjerm, slår en korrekt regel ingen kan finne.

Endre kategorien bare når kategorien er beslutningen

Å sette grensesnittet til Privat fungerer også, og det er feil standard. Profilen Privat har en lang liste innebygde tillatelsesregler som dekker fil- og skriverdeling, nettverksgjenkjenning, eksternt skrivebord og mer avhengig av basislinjen, så å omklassifisere VPN-adapteren aktiverer dem alle for hver klient i tunnelen samtidig. Én begrenset regel gir én tjeneste til ett område. På en bærbar maskin som også kobler seg til utrygge nettverk, er den forskjellen ikke kosmetisk.

Det finnes tilfeller der klassifiseringen virkelig er feil: en alltid på eller site-to-site-tunnel som fører et kontorundernett, er klarert infrastruktur, og å merke den adapteren som Privat er et legitimt designvalg, tatt én gang etter policy og ikke per sak. Når du først gjør det, gjør det eksplisitt:

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

På en administrert enhet, kontroller først om en gruppepolicy eller en MDM-basislinje eier innstillingen. Hvis den gjør det, blir den lokale endringen rullet tilbake ved neste oppdatering, og gpresult /h vil navngi policyen som eier den; rett det der, ikke på endepunktet.

Verifiser fra begge ender og legg igjen et spor

Verifiser flyten brukeren rapporterte, fra klienten, etter endringen:

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

Lukk så sløyfen på det som ryker neste uke. Start verten på nytt og test igjen, fordi en regel begrenset til feil profil fortsetter å virke til adapteren kommer tilbake i en annen kategori. Test fra en annen klient, siden én klient med en gammel lease kan skjule et avvik i poolen. Tell reglene du la til mot reglene du fjernet, fordi overlappende unntak er måten en rettelse på to linjer blir en filtreringspolicy ingen kan gjennomgå.

Før du kaller det ferdig:

  • Profilen som er navngitt i regelen, er profilen på grensesnittet trafikken ankommer på.
  • Fjernområdet er VPN-poolen, og den poolen samsvarer med det serveren faktisk deler ut.
  • Ingen regel du la til bruker -RemoteAddress Any på profilen Offentlig.
  • Ingenting ble deaktivert for å få testen til å bestå, og enhver kategorieendring registrerer hvem som godkjente den.

Relaterte artikler