VPN-klientoj blokataj de la publika fajroŝirmila profilo de Windows

Windows klasifikas la VPN-adaptilon kiel Publika, do viaj LAN-reguloj neniam validas. Kontrolu la profilon, limigu unu envenan regulon al la naĝejo, poste kontrolu la pordon.

Via tunelo estas aktiva, la kluzo respondas al ping, kaj la dosiera kunhavigo ankoraŭ finiĝas per tempolimo. Tiu kombino malofte estas enkursiga problemo: Windows metis la subreton de la VPN-adaptilo en la publikan profilon, kaj ĉiu permesa regulo verkita por Privata aŭ Domajna neniam aplikiĝis. Mi renkontis tion sur tekkomputiloj, kiuj senprobleme atingas la oficejon, kaj sur RRAS-serviloj, kiuj priservas ĉiujn aliajn klientojn, kaj la riparo estas mallonga post kiam vi nomas la koncernan profilon. Jen la ordo, en kiu mi laboras, kun la kontrolo, kiu diras al vi, kiam halti antaŭ la sekva paŝo.

Determinu, per kiu profilo la trafiko efektive alvenas

La fajroŝirmilo de Windows ne havas unu solan tutmondan reĝimon. Ĉiu konektita interfaco portas kategorion, kaj envenaj pakaĵoj estas filtritaj laŭ la kategorio de la interfaco, per kiu ili alvenas, do la profilo de la VPN-adaptilo decidas, kion kliento en la tunelo povas atingi, ne la apuda Wi-Fi- aŭ Ethernet-adaptilo. Legu ambaŭ faktojn antaŭ ol ŝanĝi ion ajn:

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

Ĉe norma instalado de OpenVPN aŭ WireGuard la VPN-adaptilo aperas kiel neidentigita reto kaj eniĝas en Publika, la defaŭlto por ĉiu reto, kiun Windows ne povas klasifiki: neniu domajna regilo respondis tra ĝi kaj neniu kluzoprofilo kongruis. La nomo de la interfaco ne gravas ĉi tie, do nomi la adaptilon "VPN" aŭ "Corp" ŝanĝas nenion. DomainAuthenticated postulas maŝinon aliĝintan al la domajno , kiu povas efektive atingi domajnan regilon tra tiu interfaco; disigita tunelo, kiu portas nur unu subreton, ne plenumos la postulon.

Se la regulo, kiun vi bezonas, jam estas limigita al la VPN-naĝejo kaj jam aplikiĝas al la kategorio, kiun vi ĵus legis, haltu ĉi tie: filtrado ne estas via tavolo, kaj la sekva loko por rigardi estas la servo-agordo. Tiu kontrolo daŭras dek sekundojn kaj ŝparas unu horon da regulredaktado. La kategoriaj nomoj kaj kion ĉiu kovras estas dokumentitaj en la referenco de Get-NetConnectionProfile.

Konfirmu filtradon, ne enkursigadon, antaŭ ol redakti regulojn

Ping estas malforta testo. ICMP povas trapasi dum la serva pordo estas forĵetita, kaj gastiganto povas respondi el la LAN dum ĝi rifuzas la saman peton tra la tunelo. Testu la pordon, kiun la kliento bezonas, de la kliento:

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

Se la pordotesto malsukcesas, apartigu la du tavolojn. Tunela aŭ voja miso kutime montriĝas kiel nenia respondo de la kluzoadreso, dum fajroŝirmila forĵeto montras kluzon, kiu respondas, kaj servan pordon, kiu ne respondas. Sur Windows-servilo, kiu publikigas la naĝejon per RRAS, rulu la saman teston de kliento kaj legu la propran profilon de la servilo: la RAS-interfaco povas sidi en kategorio, kies envenaj reguloj neniam mencias la klientan gamon, kaj tial la maŝino priservas sian LAN-on kaj rifuzas ĉiun klienton en la tunelo.

Kiam la rezulto ankoraŭ estas duba, registru la forĵetojn por la koncerna profilo kaj legu ilin:

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

Entiroj, kiuj nomas la klientan adreson kaj pordon kun DROP, estas konkludaj, kaj ili ankaŭ diras, kiu regulo mankis. Protokolo kun nenio en ĝi, dum la SYN de la kliento neniam aperas, indikas supre de la gastiganto, do reiru al la tunelo, la NAT-regulo aŭ la naĝeja vojo antaŭ ol tuŝi alian fajroŝirmilan objekton.

Limigu unu envenan regulon al la klienta naĝejo

La riparo estas unu envena permesa regulo, kies fora adreso estas la naĝejo, ne la tuta mondo. El altigita seanco:

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

Kiam la servo estas unu binara dosiero, preferu programlimigitan regulon kun -Program anstataŭ pordolisto; tio limigas la escepton kaj al la procezo kaj al la fonta gamo.

La profila elekto estas la loko, kie la sama eraro fariĝas en la mala direkto. -Profile Public sufiĉas, kiam la adaptilo estas Publika kaj restas Publika. -Profile Any estas defendebla, kiam la servo devas funkcii sendepende de tio, kiel Windows klasifikas la adaptilon, sed nur dum la fora amplekso restas. Tio, kio neniam estas defendebla, estas -RemoteAddress Any en la Publika profilo: tiu regulo sekvas la tekkomputilon en ĉiun kafejan kaj hotelan reton, al kiu ĝi aliĝas, kaj malfermas la pordon al ĉiu, kiu dividas tiun subreton.

Notu la naĝejon apud la regulo. -RemoteAddress 10.8.0.0/24 silente ĉesas kongrui en la tago, kiam la VPN-naĝejo estas renumerita, kaj la paneo aspektas ekzakte kiel la origina cimo, tial ĝi kostas duan posttagmezon. Nomu regulojn laŭ la servo kaj la fonta gamo, tenu ilin kune kun -Group, kaj relegu ilin ĉiufoje, kiam la naĝeja difino ŝanĝiĝas. Regula inventaro, kiun vi povas kontroli sur unu ekrano, superas ĝustan regulon, kiun neniu trovas.

Ŝanĝu la kategorion nur tiam, kiam la kategorio estas la decido

Ŝalti la interfacon al Privata ankaŭ funkcias, kaj ĝi estas la malĝusta defaŭlto. La Privata profilo portas longan liston da enkonstruitaj permesaj reguloj, kiuj kovras dosieran kaj printilan kunhavigon, retan malkovron, malproksiman labortablon kaj pli depende de la bazlinio, do reklasifiki la VPN-adaptilon ebligas ilin ĉiujn samtempe por ĉiu kliento en la tunelo. Unu limigita regulo donas unu servon al unu gamo. Sur tekkomputilo, kiu ankaŭ aliĝas al nefidindaj retoj, tiu diferenco ne estas kosmetika.

Estas kazoj, kie la klasifiko estas vere malĝusta: ĉiama aŭ intereja tunelo, kiu portas oficejan subreton, estas fidinda infrastrukturo, kaj marki tiun adaptilon Privata estas laŭleĝa dezajna elekto, farita unufoje per politiko, ne po bileto. Kiam vi faras ĝin, faru ĝin eksplicite:

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

Sur administrata aparato, unue kontrolu, ĉu grupa politiko aŭ MDM-bazlinio posedas la agordon. Se jes, la loka ŝanĝo estas malfarita ĉe la sekva refreŝigo, kaj gpresult /h nomos la politikon, kiu posedas ĝin; riparu ĝin tie, ne ĉe la finpunkto.

Kontrolu de ambaŭ flankoj kaj lasu spuron

Kontrolu la fluon, raportitan de la uzanto, de la kliento, post la ŝanĝo:

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

Poste fermu la buklon pri la aferoj, kiuj rompiĝos venontan semajnon. Restartigu la gastiganton kaj retestu, ĉar regulo limigita al la malĝusta profilo daŭre funkcias, ĝis la adaptilo revenas en alia kategorio. Testu de dua kliento, ĉar unu kliento kun malaktuala luo povas kaŝi naĝejan miskongruon. Kalkulu la aldonitajn regulojn kontraŭ la forigitaj, ĉar interkovrantaj esceptoj estas la maniero, kiel dulinea ripeto fariĝas filtrada politiko, kiun neniu povas revizii.

Antaŭ ol nomi ĝin finita:

  • La profilo nomita en la regulo estas la profilo de la interfaco, per kiu la trafiko alvenas.
  • La fora amplekso estas la VPN-naĝejo, kaj tiu naĝejo kongruas kun tio, kion la servilo efektive disdonas.
  • Neniu regulo, kiun vi aldonis, uzas -RemoteAddress Any en la Publika profilo.
  • Nenio estis malŝaltita por igi la teston pasi, kaj ĉiu kategoria ŝanĝo registras, kiu aprobis ĝin.

Rilataj artikoloj