VPN-kliendid on blokeeritud Windowsi avaliku tulemüüri profiili tõttu
Windows liigitab VPN-adapteri avalikuks, mistõttu teie LAN-reeglid ei kehti kunagi. Kontrollige profiili, piirake üks sissetulev reegel pooliga ja seejärel kontrollige porti.
Teie tunnel on üleval, lüüs vastab pingile ja failijagamine lõpeb ikkagi ajalõpuga. See kombinatsioon on harva marsruutimisprobleem: Windows on pannud VPN-adapteri alavõrgu avalikku profiili ja iga lubamisreegel, mis on kirjutatud privaatse või domeeni profiili jaoks, ei ole kunagi rakendunud. Olen seda kohanud nii sülearvutitel, mis jõuavad kontorisse ilma probleemideta, kui ka RRAS-serveritel, mis teenindavad kõiki teisi kliente, ja parandus on lühike, kui olete asjaomase profiili nimetanud. Siin on järjekord, milles ma töötan, koos kontrolliga, mis ütleb teile, millal enne järgmist sammu peatuda.
Tehke kindlaks, millise profiili kaudu liiklus tegelikult saabub
Windowsi tulemüüril pole ühtset globaalset režiimi. Igal ühendatud liidesel on kategooria ja sissetulevaid pakette filtreeritakse selle liidese kategooria järgi, mille kaudu need saabuvad, seega määrab VPN-adapteri profiil, mida tunnelis olev klient saab kätte, mitte kõrval olev Wi-Fi- või Ethernet-adapter. Lugege mõlemad faktid enne midagi muuta:
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction
OpenVPN-i või WireGuardi tavapärasel paigaldamisel ilmub VPN-adapter tuvastamata võrguina ja maandub avalikku profiili, mis on vaikeväärtus iga võrgu jaoks, mida Windows ei suuda liigitada: ükski domeenikontroller ei vastanud selle kaudu ja ükski lüüsiprofiil ei sobitunud. Liidese nimi ei oma siin tähtsust, seega adapteri "VPN" või "Corp" nimetamine ei muuda midagi. DomainAuthenticated nõuab domeeniga liidetud masinat mis pääseb selle liidese kaudu tegelikult domeenikontrollerile ligi; jaotatud tunnel, mis kannab ainult ühte alavõrku, ei vasta sellele nõudele.
Kui vajalik reegel on juba VPN-pooliga piiratud ja kehtib juba kategooriale, mille just läbi lugesite, peatuge siin: filtreerimine ei ole teie kiht ja järgmine koht, kust vaadata, on teenuse konfiguratsioon. See kontroll võtab kümme sekundit ja säästab tunni reeglite muutmist. Kategooriate nimed ja see, mida kumbki hõlmab, on dokumenteeritud Get-NetConnectionProfile'i viitedokumentatsioonis.
Kinnitage filtreerimine, mitte marsruutimine, enne kui reegleid muudate
Ping on nõrk test. ICMP võib läbi minna, samal ajal kui teenuseporti visatakse kõrvale, ja host võib LAN-ist vastata, samal ajal kui sama päringu tunnelist tagasi lükkab. Testige porti, mida klient vajab, kliendi poolt:
Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed
Kui porditest ebaõnnestub, eraldage kaks kihti. Tunneli- või marsruudiviga avaldub tavaliselt nii, et lüüsi aadressilt ei tule üldse vastust, samal ajal kui tulemüüri poolt kõrvaleviskamine näitab vastavat lüüsi ja mittevastavat teenuseporti. Windowsi serveris, mis avaldab pooli RRAS-i kaudu, käivitage sama test kliendi poolt ja lugege serveri enda profiili: RAS-liides võib asuda kategoorias, mille sissetulevad reeglid ei maini kunagi kliendivahemikku, ja seetõttu teenindab masin oma LAN-i ning lükkab tagasi iga tunnelis oleva kliendi.
Kui tulemus on endiselt mitmetähenduslik, logige asjaomase profiili kõrvaleviskamised ja lugege neid:
Set-NetFirewallProfile -Name Public -LogBlocked True `
-LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"
Kirjed, mis nimetavad kliendi aadressi ja porti koos DROP-iga, on lõplikud ja ütlevad ka, millist reeglit puudu oli. Logi, milles pole midagi, samal ajal kui kliendi SYN ei ilmu kunagi, viitab hostist ülespoole, seega minge tagasi tunneli, NAT-reegli või pooli marsruudi juurde, enne kui puudutate mõnda teist tulemüüriobjekti.
Piirake üks sissetulev reegel kliendipooliga
Parandus on üks sissetulev lubamisreegel, mille kaugadress on pool, mitte kogu maailm. Kõrgendatud seansist:
New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
-RemoteAddress 10.8.0.0/24 -Profile PublicKui teenus on üks binaarfail, eelistage parameetriga -Program programmipõhist reeglit pordiloendi asemel; see piirab erandi nii protsessi kui ka allikavahemikuga.
Profiili valik on koht, kus sama viga tehakse vastupidises suunas. -Profile Public piisab, kui adapter on avalik ja jääb avalikuks. -Profile Any on põhjendatav, kui teenus peab töötama olenemata sellest, kuidas Windows adapterit liigitab, kuid ainult seni, kuni kaugvahemik püsib. Mida ei saa kunagi põhjendada, on -RemoteAddress Any avalikus profiilis: see reegel järgib sülearvutit igasse kohvikuja hotellivõrku, millega see liitub, ja avab pordi kõigile, kes seda alavõrku jagavad.
Märkige pool reegli kõrvale. -RemoteAddress 10.8.0.0/24 lakkab vaikselt sobimast päeval, mil VPN-pool ümber numereeritakse, ja rike näeb välja täpselt nagu algne viga, mistõttu maksab see teise pärastlõuna. Nimetage reeglid teenuse ja allikavahemiku järgi, hoidke neid koos -Group -ga ja lugege neid uuesti iga kord, kui pooli määratlus muutub. Reeglite loend, mida saate ühel ekraanil auditeerida, on parem kui õige reegel, mida keegi ei leia.
Muutke kategooriat ainult siis, kui kategooria on otsus
Liidese privaatseks lülitamine toimib samuti ja see on vale vaikeväärtus. Privaatne profiil sisaldab pikka nimekirja sisseehitatud lubamisreeglitest, mis hõlmavad faili- ja printerijagamist, võrgu tuvastamist, kaugtöölauda ja sõltuvalt baasjoonest veelgi enam, seega VPN-adapteri ümberliigitamine lubab need kõik korraga iga tunnelis oleva kliendi jaoks. Üks piiratud reegel annab ühe teenuse ühele vahemikule. Sülearvutis, mis liitub ka mitteusaldusväärsete võrkudega, ei ole see erinevus kosmeetiline.
On juhtumeid, kus liigitus on tõesti vale: pidevalt sisse lülitatud või saidi-saiti tunnel, mis kannab kontori alavõrku, on usaldusväärne taristu, ja selle adapteri privaatseks märkimine on õiguspärane disainiotsus, mis tehakse üks kord poliitikaga, mitte iga pileti kaupa. Kui te seda teete, tehke seda selgesõnaliselt:
Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory PrivateHallatavas seadmes kontrollige esmalt, kas seade kuulub rühmakorraldusele või MDM-i baasjoonele. Kui kuulub, tühistatakse kohalik muudatus järgmisel värskendamisel ja gpresult /h nimetab korralduse, millele see kuulub; parandage seda seal, mitte lõpp-punktis.
Kontrollige mõlemast otsast ja jätke jälg
Kontrollige kasutaja teatatud voogu kliendi poolt pärast muudatust:
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
Seejärel sulgege ring nende asjade osas, mis järgmisel nädalal katki lähevad. Taaskäivitage host ja testige uuesti, sest vale profiiliga piiratud reegel töötab edasi, kuni adapter naaseb teise kategooriasse. Testige teise kliendi poolt, sest üks aegunud rendilepinguga klient võib pooli mittevastavust varjata. Loendage lisatud reeglid eemaldatud reeglite vastu, sest kattuvad erandid on viis, kuidas kaherealise parandusest saab filtreerimispoliitika, mida keegi ei saa üle vaadata.
Enne kui peate seda valmis:
- Reeglis nimetatud profiil on selle liidese profiil, mille kaudu liiklus saabub.
- Kaugvahemik on VPN-pool ja see pool vastab sellele, mida server tegelikult väljastab.
- Ükski lisatud reegel ei kasuta
-RemoteAddress Anyavalikus profiilis. - Midagi ei lülitatud välja, et test läbi läheks, ja iga kategooria muudatus registreerib, kes selle heaks kiitis.