Un singur URL pentru birou și VPN? De ce eșuează mitul listei de permisiuni

Conectați tunelul, deschideți același marcaj și site-ul permis răspunde exact cum răspundea din birou. Aceasta este presupunerea pe care se sprijină în tăcere majoritatea planurilor de acces la distanță și este valabilă doar cât timp trei lucruri separate rămân adevărate simultan. Niciunul nu este o funcție a clientului VPN și nicio înregistrare DNS nu poate furniza vreunul. Când marcajul eșuează acasă, browserul vă dă o singură eroare generică, fie că motivul este o rută lipsă, o adresă de ieșire neaprobată sau un proxy care a înlocuit sursa pe care o raportează. A trata aceste trei ca o singură problemă este calea pe care o mică corecție de politică devine o săptămână de extindere a listelor de permisiuni.

Designul care supraviețuiește contactului cu o rețea de birou reală este mai îngust decât presupunerea: un tabel de decizie explicit cu trei rânduri, un singur punct de aplicare care nu poate fi ocolit și un test de refuz care demonstrează ceva. Demontarea presupunerii vine prima, pentru că tot ce urmează depinde de a ști care strat prezintă greșit sursa.

Mitul: conectarea nu este rutare

Se stabilește un tunel și clientul instalează rute pentru un anumit set de prefixe. Atât face conectarea. Dacă o cerere HTTPS fără legătură trece prin tunel și din ce adresă publică pare să vină când ajunge sunt decizii luate mai târziu de alte componente: tabelul de rutare alege calea, iar ieșirea alege sursa.

De aceea biroul și masa din bucătărie diferă cu același laptop, același profil de browser și același marcaj. În birou cererea pleacă printr-o adresă publică întreținută cu care operatorul site-ului a fost de acord. Printr-un tunel complet poate ieși prin ieșirea VPN, care este o altă adresă și, până când cineva o adaugă, neaprobată. Printr-un tunel divizat poate să nu intre deloc în tunel. Doar două dintre aceste trei căi au făcut vreodată parte din acordul cu proprietarul site-ului, iar a treia nu este un defect de petecat cu o linie allow suplimentară.

Trei stări ale cererii, două ieșiri aprobate

Scrieți matricea înainte de a atinge un firewall, pentru că tabelul este designul, iar regula doar o implementare a lui. Adresele de mai jos sunt intervale de documentație; înlocuiți-le cu valorile dumneavoastră întreținute și păstrați-le unde proprietarul site-ului le poate audita.

Rândul din mijloc este locul unde majoritatea acestor planuri se rup. Contează adresa pe care o vede dispozitivul de aplicare, nu adresa privată pe care laptopul o ține în tunel și nu adresa sa LAN. O valoare ca 10.8.0.6 nu înseamnă nimic pentru un site public, iar 192.168.1.44 nici atât. Adresa tunelului este un detaliu de adresare al tunelului, nu o acreditare pe care site-ul o poate verifica.

Dacă VPN-ul dumneavoastră nu poate oferi o ieșire stabilă și documentată, matricea nu are un rând din mijloc valid și nicio cantitate de liste de permisiuni nu inventează unul. Opțiunile oneste în acel moment sunt un site privat accesat prin rute private explicite sau o poartă de acces conștientă de identitate în fața aplicației. Ambele au un contract diferit de o listă publică de permisiuni și ambele sunt mai ușor de explicat unui auditor decât o listă care a crescut până când, din întâmplare, a funcționat.

Citiți sursa acolo unde se ia decizia

Puneți restricția pe dispozitivul care termină cererea și confirmați că nicio cale de origine alternativă nu o ocolește. Modulul de acces al Nginx evaluează directivele allow și deny în ordine, câștigă prima potrivire, iar regulile moștenite dintr-un bloc care le înconjoară se aplică în continuare în interiorul location. Un allow îngust lângă un allow larg în același loc înseamnă de obicei că cel larg decide. Citiți întreaga configurație efectivă pentru acel location înainte de a edita măcar o linie a ei.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

În spatele unui balanceator de încărcare sau al unui proxy invers, acea regulă vede proxy-ul dacă nu îi spuneți altfel. Restabiliți adresa apelantului doar prin mecanismul de proxy de încredere acceptat, cu o listă explicită de adrese de proxy. Un antet de cerere care pretinde o adresă aprobată nu este dovada că apelantul o deține, iar pe un ascultător public un antet redirecționat nevalidat transformă lista de permisiuni în decorațiune.

Apoi verificați cealaltă familie de adrese. Un set de reguli care acoperă doar IPv4 este o decizie incompletă pentru un nume de gazdă care răspunde și pe AAAA, iar un client cu IPv6 funcțional va atinge aceeași aplicație printr-o cale pe care nu ați revizuit-o niciodată.

Tunel divizat: cererea care nu intră niciodată

Un tunel divizat transportă doar prefixele din lista sa. Subrețelele interne ale biroului ajung de obicei pe acea listă; un site web public nu. Browserul rezolvă numele, compară adresa aleasă cu tabelul de rutare și tot găsește poarta implicită locală în fața sa.

Astfel cererea vine din conexiunea de acasă a utilizatorului, este refuzată, iar raportul spune că VPN-ul este stricat în timp ce tunelul face exact ceea ce a fost configurat să facă. Două corecții sunt legitime: direcționați acea destinație prin tunel și lăsați ieșirea aprobată să o transporte, sau acceptați că site-ul este accesat direct și dați utilizatorilor la distanță o altă cale aprobată, cum ar fi poarta de acces. Extinderea listei publice de permisiuni a site-ului până când o adresă de acasă ajunge din întâmplare în ea nu este niciuna dintre cele două și elimină granița pe care designul trebuia să o impună. Primele două păstrează matricea onestă; a treia șterge în tăcere un rând din ea.

Dovediți refuzul, apoi recuperarea

Testați cu o cerere care exercită decizia reală, de la un client aflat pe fiecare rând al tabelului. O verificare de accesibilitate către o pagină oarecare care afișează adresa nu dovedește nimic, pentru că acea destinație poate urma o cale diferită de cea a aplicației.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Comparați înregistrarea de acces de la graniță cu ceea ce a prezis tabelul. Apoi coborâți tunelul și faceți o cerere nouă care ar trebui refuzată; o pagină deja încărcată sau o conexiune deja deschisă nu testează absolut nimic. Dacă nu apare niciun refuz, punctul de aplicare nu este unde credeți.

Păstrați autentificarea aplicației după admiterea în rețea, pentru că o ieșire de birou și o ieșire VPN reprezintă fiecare mulți oameni și niciuna nu identifică un individ. Instrucțiunea pentru utilizatori rămâne scurtă: ridicați tunelul aprobat, apoi reîncercați. Aceasta este ceea ce menține un singur URL comod în timp ce regula sursei rămâne o decizie, nu o presupunere.