Desktopurile din birou ajung la partajare, utilizatorii VPN întâmpină expirarea timpului, iar același cont funcționează de pe un hotspot de telefon. Permisiunile partajării sunt rareori diferența; adresa care ajunge la serverul de fișiere este de obicei. O regulă limitată la LocalSubnet admite subrețelele proprii conectate ale serverului, iar un pool VPN rutat separat nu este una dintre ele. Două proiectări închid această breșă și lasă în urmă înregistrări foarte diferite.

Două proiectări, un simptom

Prima proiectare adaugă pool-ul VPN la condiția de adresă la distanță a regulii. Serverul vede atunci adresa de tunel a fiecărui client, astfel încât jurnalele sale pot distinge un utilizator la distanță de altul. A doua proiectare rutează traficul VPN printr-o poartă care îl traduce într-o adresă LAN înainte ca serverul să îl vadă. Asta restaurează conectivitatea și elimină distincția în același pas.

Tabelul descrie roluri, nu adrese, iar prefixele tale decid care rând se aplică. Tipărește valorile reale ale serverului în loc să copiezi un exemplu dintr-o postare de blog:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

Tabelul este un ajutor de decizie, nu o afirmație despre fiecare implementare. Un host cu interfețe suplimentare, o a doua legătură de site sau altă mască are un alt set local.

Path the packet takesAddress the server recordsFilter scope that admits itWhat the log can still tell you
Desktop on the server LANIts own LAN addressLocalSubnet or the LAN prefixWhich workstation connected
Client on the routed VPN poolIts tunnel addressThe VPN pool as a remote addressWhich VPN account connected, if the pool is logged
Client behind source NAT at the gatewayThe gateway's LAN addressThe gateway addressOnly that some VPN user connected
Site-to-site gatewayThe remote gateway's tunnel addressThe remote site's prefixWhich site connected, not which user

Referința New-NetFirewallRule de la Microsoft documentează condițiile de adresă la distanță și cuvântul cheie LocalSubnet. Citește-o înainte de a decide că cuvântul cheie înseamnă toate adresele private, pentru că nu este așa.

Compară ce primește de fapt serverul

Citește regula efectivă, nu pe cea pe care cineva își amintește că a creat-o. Verifică dacă este activată, dacă se aplică profilului activ și dacă condiția sa de adresă la distanță corespunde sursei pe care o vede serverul. O regulă activată doar pe profilul Domain nu face nimic atunci când adaptorul a trecut la Public după o schimbare de rețea.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Prima comandă tipărește filtrele de adresă atașate regulilor de partajare a fișierelor, iar a doua arată ce profile sunt active și cum este tratat traficul de intrare care nu se potrivește. Caută și o regulă de blocare și o politică administrată central. Regulile de blocare au prioritate față de cele de permitere, iar o politică ce dezactivează fuzionarea regulilor locale poate face ineficientă o nouă excepție locală.

Acesta este cazul în care regula pare corectă în consolă și nu are niciun efect asupra traficului. Verifică alocarea profilului în același timp, pentru că un laptop care s-a alăturat altei rețele poate trece pe profilul Public fără ca cineva să atingă firewallul.

Testează transportul înainte de autentificare

Separă accesibilitatea de autentificare. Un listener pe TCP 445 dovedește că un serviciu este legat de port; nu dovedește că un pachet la distanță poate ajunge la el. O conexiune TCP finalizată, la rândul ei, nu spune încă nimic despre stabilirea sesiunii SMB sau despre permisiunile de partajare. Testează handshake-ul din ambele părți înainte de a edita o regulă.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

Prima comandă raportează dacă un handshake TCP reușește de pe mașina pe care o rulezi, iar a doua adaugă adresa rezolvată și detaliile interfeței. Rulează-o de pe clientul VPN și de pe un desktop din birou, apoi compară. Ping nu răspunde la niciuna dintre întrebări, pentru că ICMP poate fi blocat în timp ce SMB este deschis, sau permis în timp ce firewallul aruncă 445.

Dacă handshake-ul eșuează doar de pe VPN, domeniul sursă este principalul suspect. Dacă reușește și partajarea te refuză în continuare, treci la diagnosticarea sesiunii și permisiunilor SMB în loc să editezi reguli de firewall.

Când NAT-ul de sursă elimină distincția

Cu traducere pe traseu, serverul nu poate distinge clienții VPN individuali după adresă. Fiecare utilizator la distanță sosește ca poarta. Orice autorizare care depinde de distingerea lor trebuie aplicată acolo unde identitățile lor sunt încă vizibile, ceea ce înseamnă de obicei concentratorul VPN sau un proxy care autentifică. Regula de firewall poate admite trafic; nu poate restabili o distincție pe care traducerea a eliminat-o.

Odată ce adresa porții este permisă, fiecare utilizator la distanță este înregistrat sub o singură adresă, așa că regula acordă întregul pool oricui poate ajunge la poartă. Dacă o decizie pe utilizator contează, păstrează adresele originale vizibile sau mută decizia într-un strat care încă cunoaște utilizatorul. Altfel, fiecare utilizator la distanță moștenește permisiunile singurei adrese pe care serverul o poate vedea, iar urma de audit nu îi mai poate distinge. Aceasta este o decizie de proiectare, nu un detaliu de firewall.

Alege deliberat între cele două proiectări. Limitează regula la pool-ul VPN real când serverul trebuie să vadă cine s-a conectat, și acceptă traseul tradus doar când serverul chiar nu are nevoie de acea informație. Notează intervalul sursă ales lângă regulă, pentru că următoarea persoană care depanează asta se va uita mai întâi la tabelul de adrese.

Articole similare