Clienți VPN blocați de profilul Public al firewall-ului Windows

Tunelul este activ, gateway-ul răspunde la ping, iar partajarea de fișiere tot expiră. Această combinație este rareori o problemă de rutare: Windows a pus subrețeaua adaptorului VPN în profilul Public, iar fiecare regulă de permitere scrisă pentru Privat sau Domeniu nu s-a aplicat niciodată. Am întâlnit asta pe laptopuri care ajung fără probleme la birou și pe servere RRAS care deservesc toți ceilalți clienți, iar reparația este scurtă de îndată ce numești profilul implicat. Iată ordinea în care lucrez, cu verificarea care îți spune când să te oprești înainte de pasul următor.

Aflați pe ce profil ajunge de fapt traficul

Firewall-ul Windows nu are un singur mod global. Fiecare interfață conectată poartă o categorie, iar pachetele de intrare sunt filtrate după categoria interfeței pe care sosesc, deci profilul adaptorului VPN decide ce poate atinge un client din tunel, nu adaptorul Wi-Fi sau Ethernet de lângă el. Citiți ambele fapte înainte de a modifica ceva:

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

La o instalare standard OpenVPN sau WireGuard, adaptorul VPN apare ca rețea neidentificată și ajunge în Public, valoarea implicită pentru orice rețea pe care Windows nu o poate clasifica: niciun controler de domeniu nu a răspuns prin ea și niciun profil de gateway nu s-a potrivit. Numele interfeței nu contează aici, așa că a numi adaptorul „VPN” sau „Corp” nu schimbă nimic. DomainAuthenticated necesită o mașină alăturată domeniului , care poate ajunge efectiv la un controler de domeniu prin acea interfață; un tunel divizat care transportă o singură subrețea nu va satisface cerința.

Dacă regula de care aveți nevoie este deja limitată la pool-ul VPN și se aplică deja categoriei pe care tocmai ați citit-o, opriți-vă aici: filtrarea nu este stratul dumneavoastră, iar următorul loc de căutat este configurația serviciului. Această verificare durează zece secunde și economisește o oră de editare a regulilor. Numele categoriilor și ce acoperă fiecare sunt documentate în documentația de referință Get-NetConnectionProfile.

Confirmați filtrarea, nu rutarea, înainte de a edita reguli

Ping-ul este un test slab. ICMP poate trece în timp ce portul serviciului este aruncat, iar un host poate răspunde din LAN refuzând aceeași cerere prin tunel. Testați portul de care are nevoie clientul, din client:

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

Dacă testul portului eșuează, separați cele două straturi. O defecțiune de tunel sau de rută se arată de obicei ca niciun răspuns de la adresa gateway-ului, în timp ce o aruncare a firewall-ului arată un gateway care răspunde și un port de serviciu care nu răspunde. Pe un server Windows care publică pool-ul prin RRAS, rulați același test dintr-un client și citiți profilul serverului însuși: interfața RAS poate sta într-o categorie ale cărei reguli de intrare nu menționează niciodată intervalul clienților, motiv pentru care mașina își deservește LAN-ul și refuză fiecare client din tunel.

Când rezultatul este încă ambiguu, înregistrați în jurnal aruncările pentru profilul implicat și citiți-le:

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

Intrările care numesc adresa și portul clientului cu DROP sunt concludente și vă spun și ce regulă lipsea. Un jurnal fără nimic în el, în timp ce SYN-ul clientului nu apare niciodată, indică în amonte de host, așa că întoarceți-vă la tunel, la regula NAT sau la ruta pool-ului înainte de a atinge un alt obiect de firewall.

Limitați o regulă de intrare la pool-ul de clienți

Reparația este o singură regulă de permitere pentru intrare a cărei adresă la distanță este pool-ul, nu lumea întreagă. Dintr-o sesiune ridicată:

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

Când serviciul este un singur binar, preferați o regulă limitată la program cu -Program în loc de o listă de porturi; asta limitează excepția atât la proces, cât și la intervalul sursă.

Alegerea profilului este locul unde aceeași greșeală se face în direcția opusă. -Profile Public este suficient când adaptorul este Public și rămâne Public. -Profile Any este justificabil când serviciul trebuie să funcționeze indiferent cum clasifică Windows adaptorul, dar numai cât timp rămâne domeniul la distanță. Ce nu este niciodată justificabil este -RemoteAddress Any în profilul Public: acea regulă urmează laptopul în fiecare rețea de cafenea și hotel la care se conectează și deschide portul oricui împărtășește acea subrețea.

Notați pool-ul lângă regulă. -RemoteAddress 10.8.0.0/24 încetează silențios să se potrivească în ziua în care pool-ul VPN este renumerotat, iar defecțiunea arată exact ca bug-ul original, motiv pentru care costă o a doua după-amiază. Numirea regulilor după serviciu și intervalul sursă, țineți-le împreună cu -Group, și recitiți-le ori de câte ori definiția pool-ului se schimbă. Un inventar de reguli pe care îl puteți audita pe un singur ecran bate o regulă corectă pe care nimeni nu o găsește.

Schimbați categoria doar când categoria este decizia

Comutarea interfeței pe Privat funcționează și ea, și este implicitul greșit. Profilul Privat poartă o listă lungă de reguli de permitere încorporate, care acoperă partajarea fișierelor și imprimantelor, descoperirea rețelei, desktopul la distanță și mai mult în funcție de bază, așa că reclasificarea adaptorului VPN le activează pe toate deodată pentru fiecare client din tunel. O regulă limitată acordă un serviciu unui interval. Pe un laptop care se alătură și rețelelor neîncrezătoare, diferența nu este cosmetică.

Există cazuri în care clasificarea este cu adevărat greșită: un tunel permanent sau site-to-site care transportă o subrețea de birou este infrastructură de încredere, iar marcarea acelui adaptor ca Privat este o decizie de proiectare legitimă, luată o dată prin politică, nu pe tichet. Când o faceți, faceți-o explicit:

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

Pe un dispozitiv administrat, verificați mai întâi dacă o politică de grup sau o linie de bază MDM deține setarea. Dacă da, modificarea locală este anulată la următoarea reîmprospătare, iar gpresult /h va numi politica ce o deține; remediați acolo, nu pe punctul final.

Verificați de la ambele capete și lăsați o urmă

Verificați fluxul raportat de utilizator, din client, după modificare:

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

Apoi închideți bucla pe lucrurile care se strică săptămâna viitoare. Reporniți hostul și retestați, pentru că o regulă limitată la profilul greșit continuă să funcționeze până când adaptorul revine într-o altă categorie. Testați dintr-un al doilea client, fiindcă un client cu un lease vechi poate ascunde o nepotrivire a pool-ului. Numărați regulile adăugate față de cele eliminate, pentru că excepțiile suprapuse sunt modul în care o corectură de două linii devine o politică de filtrare pe care nimeni nu o poate revizui.

Înainte de a-l declara terminat:

• Profilul numit în regulă este profilul interfeței pe care sosește traficul.
• Domeniul la distanță este pool-ul VPN, iar acel pool corespunde cu ce distribuie efectiv serverul.
• Nicio regulă pe care ați adăugat-o nu folosește -RemoteAddress Any în profilul Public.
• Nimic nu a fost dezactivat pentru ca testul să treacă, iar orice schimbare de categorie consemnează cine a aprobat-o.