VPN-klientar blokkerte av den offentlege Windows-brannmurprofilen

Windows klassifiserer VPN-adapteren som Offentleg, så LAN-reglane dine gjeld aldri. Kontroller profilen, avgrens éi innkomande regel til poolen, og verifiser deretter porten.

Tunnelen din er oppe, gatewayen svarar på ping, og filutvekslinga gir framleis tidsavbrot. Den kombinasjonen er sjeldan eit ruteproblem: Windows har lagt undernettet til VPN-adapteren i profilen Offentleg, og kvar tillatingsregel som er skriven for Privat eller Domene, vart aldri brukt. Eg har møtt dette på berebære maskinar som når kontoret fint, og på RRAS-tenarar som betener alle andre klientar, og reparasjonen er kort når du først namngir profilen som er i spel. Her er rekkjefølgja eg arbeider i, med kontrollen som fortel deg at du skal stoppe før neste steg.

Finn ut kva profil trafikken faktisk kjem inn på

Windows-brannmuren har ikkje éin global modus. Kvart tilkopla grensesnitt ber ein kategori, og innkomande pakkar blir filtrerte mot kategorien til grensesnittet dei kjem inn på, så det er profilen til VPN-adapteren som avgjer kva ein klient i tunnelen kan nå, ikkje Wi-Fi- eller Ethernet-adapteren ved sida av. Les begge fakta før du endrar noko:

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

Ved ein standardinstallasjon av OpenVPN eller WireGuard viser VPN-adapteren seg som eit uidentifisert nettverk og hamnar i Offentleg, som er standarden for alle nettverk Windows ikkje kan klassifisere: ingen domenekontrollar svara over det, og ingen gatewayprofil passa. Namnet på grensesnittet er irrelevant her, så å kalle adapteren «VPN» eller «Corp» endrar ingenting. DomainAuthenticated krev ein maskin som er knytt til domenet , som faktisk kan nå ein domenekontrollar over det grensesnittet; ein delt tunnel som berre fører eitt undernett, oppfyller ikkje kravet.

Viss regelen du treng allereie er avgrensa til VPN-poolen og allereie gjeld for kategorien du nettopp las, stopp her: filtrering er ikkje laget ditt, og neste stad å sjå er tenestekonfigurasjonen. Den kontrollen tek ti sekund og sparar ein time med reglereigering. Kategorinamna og kva kvar kategori dekkjer, er dokumentert i referansen for Get-NetConnectionProfile.

Stadfest filtrering, ikkje ruting, før du redigerer reglar

Ping er ein svak test. ICMP kan passere medan tenesteporten blir droppa, og ein vert kan svare frå LAN-et medan han avviser den same førespurnaden over tunnelen. Test porten klienten treng, frå klienten:

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

Viss porttesten feilar, skil dei to laga. Ein tunnel- eller rutefeil viser seg vanlegvis som ingen svar frå gatewayadressa i det heile, medan ei brannmursperre viser ein gateway som svarar og ein tenesteport som ikkje gjer det. På ein Windows-tenar som publiserer poolen via RRAS, køyr den same testen frå ein klient og les profilen til tenaren sjølv: RAS-grensesnittet kan sitje i ein kategori der dei innkomande reglane aldri nemner klientområdet, og det er derfor maskinen betener LAN-et sitt og avviser kvar klient i tunnelen.

Når resultatet framleis er tvitydig, loggfør droppa for profilen som er i spel og les dei:

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

Oppføringar som nemner klientadressa og porten med DROP er avgjerande, og dei fortel deg også kva regel som mangla. Ei logg utan noko i, medan SYN-en til klienten aldri dukkar opp, peikar oppstraums for verten, så gå tilbake til tunnelen, NAT-regelen eller poolruta før du rører eit anna brannmurobjekt.

Avgrens éi innkomande regel til klientpoolen

Reparasjonen er éi innkomande tillatingsregel der fjernadressa er poolen, ikkje heile verda. Frå ei forhøgd ø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 tenesta er éi enkelt binærfil, føretrekk ein programavgrensa regel med -Program framfor ei portliste; det avgrensar unntaket både til prosessen og til kjeldeområdet.

Profilvalet er der den same feilen blir gjord i motsett retning. -Profile Public er nok når adapteren er Offentleg og blir verande Offentleg. -Profile Any er forsvarleg når tenesta må verke uansett korleis Windows klassifiserer adapteren, men berre så lenge fjernområdet blir ståande. Det som aldri er forsvarleg, er -RemoteAddress Any på profilen Offentleg: den regelen følgjer den berebære maskinen inn i kvart kafé- og hotellnettverk han koplar seg til og opnar porten for alle som deler det undernettet.

Noter poolen ved sida av regelen. -RemoteAddress 10.8.0.0/24 sluttar stille å passe den dagen VPN-poolen blir nummerert på nytt, og feilen ser nøyaktig ut som den opphavlege feilen, og difor kostar han ein ekstra ettermiddag. Namngi reglar etter tenesta og kjeldeområdet, hald dei saman med -Group, og les dei på nytt når pooldefinisjonen endrar seg. Eit regelinventar du kan revidere på éin skjerm, slår ein korrekt regel ingen kan finne.

Endre kategorien berre når kategorien er avgjerda

Å setje grensesnittet til Privat fungerer også, og det er feil standard. Profilen Privat har ei lang liste innebygde tillatingsreglar som dekkjer fil- og skrivardeling, nettverksgjenkjenning, eksternt skrivebord og meir avhengig av basislinja, så å omklassifisere VPN-adapteren aktiverer dei alle for kvar klient i tunnelen samtidig. Éin avgrensa regel gir éi teneste til eitt område. På ein berebær maskin som også koplar seg til utrygge nettverk, er den skilnaden ikkje kosmetisk.

Det finst tilfelle der klassifiseringa verkeleg er feil: ein alltid på eller site-to-site-tunnel som fører eit kontorundernett, er klarert infrastruktur, og å merke den adapteren som Privat er eit legitimt designval, teke éin gong etter policy og ikkje per sak. Når du først gjer det, gjer det eksplisitt:

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

På ein administrert eining, kontroller først om ein gruppepolicy eller ei MDM-basislinje eig innstillinga. Viss ho gjer det, blir den lokale endringa rulla tilbake ved neste oppdatering, og gpresult /h vil namngje policyen som eig ho; rett det der, ikkje på endepunktet.

Verifiser frå begge endar og legg att eit spor

Verifiser flyten brukaren rapporterte, frå klienten, etter endringa:

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øyfa på det som ryker neste veke. Start verten på nytt og test igjen, fordi ein regel avgrensa til feil profil fortset å verke til adapteren kjem tilbake i ein annan kategori. Test frå ein annan klient, sidan éin klient med ein gammal lease kan skjule eit avvik i poolen. Tel reglane du la til mot reglane du fjerna, fordi overlappande unntak er måten ei retting på to linjer blir ein filtreringspolicy ingen kan gjennomgå.

Før du kallar det ferdig:

  • Profilen som er namngitt i regelen, er profilen på grensesnittet trafikken kjem inn på.
  • Fjernområdet er VPN-poolen, og den poolen samsvarar med det tenaren faktisk deler ut.
  • Ingen regel du la til brukar -RemoteAddress Any på profilen Offentleg.
  • Ingenting vart deaktivert for å få testen til å bestå, og kvar kategorieendring registrerer kven som godkjende ho.

Relaterte artiklar