Gateway VPN Windows: trei sarcini, trei responsabili

Trei funcții se adună de fiecare dată când cineva spune server VPN: închiderea tunelului criptat, mutarea pachetelor între rețele și, opțional, rescrierea adreselor. În Windows acestea trăiesc în părți diferite ale stivei, chiar și atunci când o singură mașină le face pe toate trei. Fiecare are propriile intrări și propriul mod de eșec, iar fiecare poate fi încredințată unui produs diferit. Separarea lor pe hârtie este cel mai ieftin mod de a menține o instalare mică ușor de înțeles.

Un design lizibil numește responsabilul fiecărui flux în loc să descrie mașina ca pe un rol.

Închide, transmite, traduce

RRAS gestionează tunelul în cazul nativ Windows: autentifică utilizatorul, atribuie o adresă dintr-un bazin și decide ce destinații sunt permise. Un alt produs VPN poate deține în schimb ascultătorul și adaptorul virtual, lăsând Windows să transmită pachetele decriptate. Documentația Remote Access a Microsoft separă rolurile VPN, site-la-site și de rutare, iar instalarea rolului de rutare nu creează o a doua identitate VPN. Adăugarea unei alte aplicații VPN nu îi oferă nici adaptorul tuturor funcțiilor de gateway existente.

Traducerea este a treia sarcină și cea mai opțională. Vine după transmitere și schimbă adresa sursă pe care o vede rețeaua îndepărtată. Faptul că aveți nevoie de ea depinde de ce va accepta rețeaua de destinație ca sursă, nu de faptul că mașina se numește gateway VPN.

Cui aparțin adaptorul și bazinul

Când mai multe produse împart gazda, patru lucruri au nevoie fiecare de un singur proprietar: porturile de ascultare, durata de viață a adaptorului, bazinul de adrese pentru clienți și rutele. Adaptorul este cel incomod, pentru că un serviciu VPN îl poate crea dinamic și distruge la deconectare. A trata acea interfață ca pe o placă de rețea cu nume permanent și a scrie reguli împotriva numelui ei funcționează până la următoarea reconectare. Folosiți punctul de integrare acceptat de produs în loc să codificați rigid numele unei interfețe.

Bazinul de adrese este a doua coliziune. Două produse care distribuie intervale suprapuse produc rutare care pare corectă și nu livrează nimic. Țineți bazinele în același document cu rutele, astfel încât o schimbare într-unul să fie vizibilă față de celălalt.

Păstrează sursa sau rescrie-o

Păstrarea adresei sursă a clientului menține vizibilitatea pe utilizator: jurnalele, cotele și regulile de firewall pot distinge un utilizator de altul. Prețul este că LAN-ul de destinație are nevoie de o rută de întoarcere către gateway, iar cineva trebuie să o întrețină. Rescrierea sursei cu NAT elimină această cerință și elimină vizibilitatea odată cu ea. Alegeți deliberat și notați ce informații ascunde rescrierea.

Accesul la rețeaua privată, ieșirea în internet și conexiunile care se termină chiar pe gateway sunt trei căi diferite. Nu toate au nevoie de același tratament.

Descrie fluxul într-o singură propoziție

O propoziție ar trebui să descrie designul: ce clienți admite acest serviciu, ce resurse acordă acea politică de transmitere și cum calea de întoarcere completează fluxul. Dacă propoziția are nevoie de un al doilea strat NAT pentru a fi adevărată, de obicei este semnul că piesele anterioare nu erau lămurite. Gazda este și o frontieră partajată de eșec și de încredere, așa că o schimbare de rutare poate afecta atât accesul utilizatorilor, cât și administrarea. Păstrați o cale de recuperare independentă pentru aceasta din urmă.

Țineți un inventar de roluri lângă configurație: ce produs închide, care transmite, care traduce și cine poate schimba fiecare. Acea listă este ce face următoarea schimbare verificabilă.

Când propoziția devine neclară, adăugarea unui alt strat de traducere rareori o lămurește. Eliminarea unuia de obicei o face.