Cum un proxy public ajunge la o origine privată printr-un VPN

Publicarea unui site printr-un tunel și acordarea accesului VPN utilizatorilor sunt două aranjamente diferite care împart un cablu. În primul, un proxy invers public preia cererea vizitatorului și o trimite prin tunel către o origine pe care nimeni nu o poate atinge direct. În al doilea, utilizatorul trebuie să se alăture VPN-ului înainte ca aplicația să fie accesibilă. Amestecarea celor două descrieri este modul în care un backend privat ajunge expus public.

Două modele care arată la fel pe o diagramă

Desenați săgețile înainte de a alege ceva. Un model de publicare publică merge de la browser la proxy prin HTTPS, apoi de la proxy la origine prin tunel, iar originea nu acceptă niciodată o conexiune din internet. Un model doar VPN merge de la client la gateway, iar aplicația este accesibilă doar din interiorul acelei căi. Laptopul utilizatorului stă în aceeași rețea ca aplicația, iar acesta este tot rostul acelui model.

Modelele diferă în cine autentifică și unde. În primul, proxy-ul este intrarea publică și retransmite orice cerere care sosește, inclusiv una ostilă, conform politicii configurate pe el. În al doilea, accesibilitatea însăși este poarta, ceea ce este o admitere grosolană, dar reală.

Unde se oprește TLS și ce demonstrează de fapt

TLS între browser și proxy protejează acel salt și permite browserului să verifice site-ul pe care intenționa să îl viziteze. Dacă proxy-ul termină TLS, cererea există în formă lizibilă în interiorul acelui proces înainte de a fi retransmisă. O a doua sesiune TLS către origine poate proteja următorul salt și poate verifica separat punctul final al aplicației. Niciuna dintre sesiuni nu decide ce persoană poate folosi aplicația. Un certificat wildcard pe proxy nu se extinde nici la acel al doilea salt.

Aceasta este partea pe care oamenii o reduc la cuvântul criptat. Confidențialitatea, integritatea și identitatea serverului sunt proprietăți de transport; autorizarea este o decizie a aplicației. O adresă privată în spatele unui tunel schimbă cine poate ajunge la socket, nu cine se poate autentifica după ce ajunge.

Acordați încredere antetelor transmise doar de la proxy

Aplicațiile care înregistrează sau autorizează după adresa clientului citesc de obicei un antet pe care proxy-ul îl adaugă. Acel antet este doar text, așa că orice poate ajunge direct la origine poate pretinde orice adresă dorește. Restrângeți originea astfel încât doar adresa tunelului proxy-ului să se poată conecta, și configurați aplicația să accepte antetul doar de la acea adresă.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Dacă acea cerere reușește de la un host care nu este proxy-ul, originea se încrede într-un antet pe care ar trebui să îl ignore. Reparați listenerul înainte de a atinge aplicația. O respingere este un rezultat mult mai bun decât o linie de jurnal care poartă o adresă falsificată.

Păstrați originea accesibilă din exact un singur loc

Legați listenerul originii de adresa tunelului sau izolați-l cu un firewall către proxy, apoi confirmați ce ascultă de fapt. Un serviciu pornit cu o legătură wildcard acceptă conexiuni pe fiecare interfață pe care o are hostul, inclusiv una despre care ați uitat că este rutabilă. Tabelul de ascultare este adevărul de bază, nu fișierul de configurare pe care intenționați să îl aplicați. Dacă legătura wildcard este intenționată, firewall-ul trebuie totuși să fie componenta care o restrânge.

ss -ltnp | grep -E ':(80|443)'

Faceți aceeași revizuire pentru interfețele de administrare, care sunt expunerea accidentală obișnuită. Apoi scrieți cele două modele separat: site-ul public prin proxy și interfața de administrare accesibilă doar prin tunel. Propoziția că serverul este în spatele unui VPN nu spune nimic din toate acestea.