Politica de grup NPS nu este aplicarea resurselor VPN

Două grupuri, două profiluri de acces, un gateway VPN și, în final, ambele grupuri ajung la aceleași servere. Motivul obișnuit nu este o politică stricată, ci o a doua jumătate lipsă a proiectării: NPS decide cine poate stabili o sesiune, iar altceva trebuie să decidă la ce poate ajunge acea sesiune. Când există doar prima jumătate, autorizarea reușește pentru toți cei care se autentifică. Politica își face treaba, iar proiectarea este încă incompletă.

O politică de rețea care se potrivește unui grup este o dovadă despre admitere. Nu este o dovadă despre pachete, iar decalajul dintre aceste două afirmații este locul unde se întâmplă cea mai mare parte a acestei munci.

Găsiți politica care a admis efectiv sesiunea

NPS evaluează politici de rețea ordonate, iar prima regulă activată ale cărei condiții se potrivesc câștigă. Condițiile pot include apartenența la un grup de utilizatori sau de calculatoare, tipul conexiunii, ora și starea dispozitivului. De aceea o politică largă plasată mai sus în listă admite o conexiune înainte ca o regulă mai îngustă de mai jos să fie măcar luată în considerare. Ordinea nu este un detaliu al interfeței; ordinea este politica.

Citiți lista în ordine și identificați-o pe cea care s-a potrivit, apoi notați ce setări a returnat. Numele grupului din editor nu este rezultatul; rezultatul este autorizarea pe care a primit-o serverul. Țineți separată autorizarea utilizatorului și autorizarea dispozitivului acolo unde implementarea le folosește pe ambele, pentru că un cont care poate deschide un tunel nu este automat un cont care ar trebui să ajungă la fiecare serviciu intern.

Răspunsul RADIUS este o instrucțiune, nu un filtru

Un atribut Filter-Id poartă numele unei liste de filtre. Nu transportă un set portabil de reguli de filtrare a pachetelor pe care fiecare receptor să îl înțeleagă, iar trimiterea unui nume pe care gatewayul nu l-a definit niciodată nu aplică absolut nimic. Aceeași prudență este valabilă pentru atributele VLAN: atribuirea unei sesiuni de tunel unui VLAN nu este, prin ea însăși, o regulă de acces rutată pentru acel utilizator.

Aici o proiectare care pare completă pe partea NPS nu face nimic, în liniște. Confirmați din documentația furnizorului gatewayului ce atribute de autorizare sunt acceptate și ce face receptorul cu fiecare, în loc să presupuneți că un nume standard de atribut implică un comportament standard.

Puneți aplicarea acolo unde trece traficul

Un gateway care procesează pachetele utilizatorului poate aplica un filtru per sesiune, poate mapa un grup la o politică a gatewayului sau poate da sesiunii o adresă dintr-un bazin segregat pe care paravanul o tratează diferit. Oricare dintre acestea poate funcționa și fiecare eșuează în moduri diferite. Stabiliți ce mecanism acceptă gatewayul dumneavoastră înainte de a scrie politica ce îl numește. Apoi notați ce se întâmplă cu o sesiune când acel mecanism lipsește, pentru că tăcerea este starea implicită.

Descrieți permisiunea intenționată în patru părți: identitatea sursei sau grupul, destinația, protocolul și portul. Adăugați dependențele de care utilizatorul are cu adevărat nevoie, cum ar fi DNS sau un serviciu de autentificare, altfel restricția va rupe fluxuri de conectare pe care nimeni nu s-a gândit să le testeze. Scrieți regula față de interfața care filtrează efectiv, nu față de interfața care se întâmplă să fie deschisă în editor.

Luați în calcul și traducerea adreselor. Dacă un paravan din aval vede o singură adresă sursă tradusă pentru fiecare utilizator al tunelului, nu poate distinge persoane doar după acea adresă, iar o regulă scrisă ca și cum ar putea va fi fie inutilă, fie prea largă.

Profilurile de client trăiesc pe partea neîncrezătoare

Un profil VPN administrat poate împinge rute, reguli de tunel divizat sau filtre de aplicații, iar acestea modelează cum se comportă un dispozitiv bine crescut. Ele nu sunt protecție pentru serviciu, pentru că clientul este partea pe care încercați să o constrângeți. Eliminarea unei rute dintr-un profil nu este nici ea autorizare, deoarece un client poate avea o altă cale către aceeași destinație.

Tratați setările clientului ca pe o comozitate și setările gatewayului ca pe un control. Când cele două nu sunt de acord, gatewayul are dreptate, pentru că el este cel care vede pachetele.

Acceptați cu două conturi, apoi urmăriți în ordine

Creați două conturi de test obișnuite cu permisiuni intenționate diferite, stabiliți sesiuni noi și verificați politica efectivă a gatewayului pentru fiecare. Apoi testați o operațiune permisă inofensivă și o resursă refuzată în mod specific. Un ping eșuat demonstrează foarte puțin de unul singur, deoarece ICMP poate fi filtrat în timp ce serviciul TCP din spate răspunde bucuros.

Când ambele conturi obțin în continuare acces larg, urmăriți într-o ordine fixă: ce politică s-a potrivit, ce autorizare purta răspunsul și ce a făcut gatewayul cu ea. Adăugarea mai multor atribute NPS înainte de a confirma că receptorul le implementează este felul în care o mică problemă de autorizare devine o fereastră de schimbare fără rezultat.