Clienți VPN și LAN-ul: când să folosești o zonă separată

Punerea interfeței de tunel în zona LAN este cea mai scurtă cale către un VPN funcțional și, de obicei, este valoarea implicită greșită. Acordă clientului la distanță aceeași încredere pe care o are LAN-ul cu cablu, ceea ce sarcina rareori cere. O zonă separată costă câteva reguli și face granița vizibilă. Decizia nu este dacă zonele sunt mai bune; este care trei condiții se aplică rețelei tale.

Numele zonei nu criptează nimic și nu autentifică niciun utilizator. Doar grupează interfețele pentru modelul de politici al paravanului.

Ce controlează de fapt apartenența la zonă

O zonă grupează interfețe sau trafic în modelul paravanului. Apoi setările sale de intrare, ieșire și redirecționare guvernează roluri diferite. Intrarea este traficul către routerul însuși; redirecționarea este traficul prin el către alt host. Documentația OpenWrt despre zone tratează intrarea, ieșirea și redirecționarea ca setări separate exact din acest motiv.

O permisiune din zona VPN în zona LAN nu este automat o permisiune inversă. Regulile de redirecționare au direcție, iar o regulă care permite trafic de la client la server nu permite sesiuni de la server la client. Un client care poate deschide o conexiune către un server nu este un client către care serverul poate deschide o conexiune înapoi.

Această distincție este motivul pentru care o zonă separată este utilă: poți enunța explicit fiecare direcție și fiecare rol. Scrie direcția lângă fiecare regulă.

Prima decizie: intrare, redirecționare sau ambele

Dacă clienții la distanță au nevoie de DNS de la router, permite intrarea doar pentru acel serviciu. Dacă trebuie să ajungă la un server de fișiere, permite redirecționarea către acea destinație. Majoritatea proiectelor VPN au nevoie de ambele, dar pentru servicii diferite.

Accesul larg la intrare pentru fiecare serviciu local aproape niciodată nu este necesar. Tratează administrarea routerului ca o decizie separată de accesul la aplicații. Dacă routerul trebuie doar să răspundă la DNS, scrie acea singură permisiune și lasă restul închis.

A doua decizie: ce resurse au nevoie clienții la distanță

Listează intervalele clienților, destinațiile și serviciile pe care VPN-ul ar trebui să le ofere înainte de a scrie reguli. O listă de destinații este mai utilă decât o etichetă de încredere, pentru că supraviețuiește unei migrări a paravanului.

Ține interfețele de administrare separate de accesul obișnuit la aplicații. Un client la distanță care ajunge la un wiki nu are prin asta nevoie de pagina de administrare a routerului sau de consola hipervizorului.

Dacă o destinație permisă poate redirecționa mai departe, granița zonei se oprește la paravan, nu la ce face destinația mai departe.

A treia decizie: cum vei demonstra granița

Testează un flux permis și unul refuzat intenționat după fiecare modificare. A demonstra că un site se încarcă nu dezvăluie o permisiune largă neintenționată. Testează din intervalul de adrese al clientului VPN, nu din LAN, și include direcția în care te aștepți să eșueze. Notează ambele rezultate lângă regulă.

Păstrează accesul de recuperare al gateway-ului înainte de a modifica politica zonei la distanță. Folosește configurația gestionată persistentă în locul modificărilor în timpul rulării, altfel următoarea repornire va restabili vechea încredere. O copie a configurației anterioare, păstrată în afara dispozitivului, este cea mai ieftină revenire pe care o vei avea vreodată.

Pe măsură ce rețeaua crește, documentează apartenența și scopul regulilor. O interfață nou conectată nu ar trebui să moștenească privilegii doar pentru că cineva i-a dat un nume de zonă convenabil.