Nginx virdrun, private Backend hannert der VPN

De Browser schwätzt mam Nginx, an den Nginx mécht eng zweet Verbindung an den Tunnel op. Leet béides, verifizéier béid Zertifikater a hal déi ëffentlech Ëmleedungen ëffentlech.

Verfolleg eng Ufro vun engem Telefon am Zuch bis zu engem Backend, dee just bannent engem private Netz existéiert. Den Telefon léist en ëffentlechen Numm op, verbënnt sech mat enger ëffentlecher Adress op Port 443 a kompletéiert en normale TLS-Handshake. Den Nginx akzeptéiert déi Verbindung an mécht dann eng zweet, komplett getrennte, op eng Adress op déi en nëmmen iwwer eng VPN-Schnittstell kënnt. Um Telefon ännert sech näischt, an den Telefon weess ni datt en Tunnel derbäi war.

Eng Ufro duerch zwou Verbindungen verfollegen

Den agaangene Been ass eng ëffentlech HTTP-Transaktioun. En huet en ëffentlechen Numm, en ëffentlecht Zertifikat an en Äntwertwee dee muss funktionéieren fir all Adress déi de Visiteur an deem Moment huet. All Ännerung déi dee Wee stéiert, brécht all Visiteuren op eng Kéier. Dofir ass den ëffentlechen Been deen, op deem s du am mannsten experimentéiere wëlls.

Den ausgänge Been ass privat. Den Nginx gëtt engem Client, léist en internen Numm op oder benotzt eng fix Adress, an erreecht en Service deen eng Verbindung aus dem Internet refuséiere géif.

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

Hal se getrennt am Kapp an d'Konfiguratioun gëtt evident. Wann s de se vermëschs, endegs du domat datt s en ëffentleche Client wëlls un engem Tunnel deelhuele loossen, an dohier kënnt de gréissten Deel vun der Verwierrung an dësem Design. Den private Been dierf fragil sinn. Den ëffentlechen net.

Ier s eppes dovun baues, bestäteg datt d'Publizéieren vun der Applikatioun bewosst ass. En funktionéierende Proxy ass och eng funktionéierend Aussoen, an d'Authentifikatiounsmodell muss eng Entscheedung sinn, net en Nieweeffekt.

Den Numm vum Gateway muss den Tunnel iwwerliewe

Et läit eng subtil Fal an der Numm-Opléisung. Wann private DNS dee selwechten Numm iwwerschreift, deen de VPN-Profil fir säin eegene Gateway benotzt, kann eng Reconnectioun dozou kommen, dee Gateway duerch deen Tunnel ze erreechen, deen en selwer soll opbauen. De Client brauch deen Numm opgeléist ier den Tunnel existéiert. Soubal en am Tunnel opgeléist gëtt, kann d'Verbindung guer net opgebaut ginn.

Benotz getrennt ugeholl Nimm fir de Gateway an de Backend, a begrenz d'Politik vum Opléiser esou datt all Numm op d'Adress opgeléist gëtt déi säi Benotzer brauch. D'Ännere vum Host-Header vun enger Applikatioun hëlleft hei näischt, well de VPN-Client d'Sich mécht.

Dann denk un de Beräich. D'Frontend brauch eng Route bis op d'Adress vum Backend, an et muss och weiderhin ëffentlech Cliente beäntwerten. En vollstännegen Tunnel op deem Host kann déi éischt Fuerderung erfëllen an déi zweet briechen.

Wou d'Politik et erlaabt, ass en Tunnel op en spezifescht Zil dat méi propper Design. Wou d'Politik e vollstännegen Tunnel virschreift, gehéiert d'Frontend an en anere Netz-Kontext amplaz mat Ad-hoc-Routen fir bekannte Visiteuren gefléckt ze ginn.

Schreif de Serverblock esou datt béid Been verifizéieren

Stell dir vir datt de Backend en Zertifikat fir dësen Numm presentéiert: backend.corp.example an op enger privater Adress äntwert. Sech mat enger Adress verbannen während een en Numm verifizéiert ass genau dat, wofir d'SNI- an Numm-Optioune vum Proxy-Modul do sinn.

upstream private_app {
    server 10.40.0.20:8443;
}

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

    ssl_certificate     /etc/nginx/tls/app-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/app-key.pem;

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

All Wee an Adress uewe sinn en Platzhalter. Déi wichteg Deeler sinn déi, déi d'Verifizéierung un halen: en Numm fir ze kontrolléieren, e Vertrauensbündel fir en dogéint ze kontrolléieren, an eng Déift déi zu der ugeholl Kette passt.

proxy_set_header Host app.example.com ass bewosst. De Backend soll esou konfiguréiert sinn datt en deen ëffentlechen Urspronk akzeptéiert, an en soll weidergeleet Header just vun dësem Frontend vertrauen. D'Iwwerschreiwen vun X-Forwarded-For mat der Client-Adress ass richteg fir een eenzegen Proxy a falsch fir eng Kette, dofir brauch eng Ausrullung mat méi Proxyen hir eege Reegelung fir vertrauenswierdeg Adressen.

Maach datt den ëffentlechen Urspronk sech wéi een ëffentlechen Urspronk behëlt

D'Applikatioun soll absolut URLen, Ëmleedungen a Cookien fir den ëffentlechen Urspronk ausginn. Wann se e Visiteur op backend.corp.example ëmleet, gëtt dee Visiteur op een Numm geschéckt deen en net opléise kann.

Reparéier dat duerch déi ënnerstëtzt extern URL-Astellung vun der Applikatioun an eng iwwerpréift Ëmleedungspolitik, net duerch d'Ëmschreiwe vun Hostnimm an den Äntwertkierper. D'Ersetze vu Stréng an arbiträrem Inhalt brécht signéiert Luedungen a schaaft Feeler déi schwéier ze verfollegen sinn.

Cookien verdéngen déi selwecht Suergfalt. E Cookie deen op den private Numm limitéiert ass, gëtt ni vun engem Browser geschéckt deen just den ëffentlechen kennt.

Bestäteg och datt den Nginx deen ëffentlechen Socket wierklech ka besëtzen. En existente Webservice op 443 muss sech bewegen oder d'Frontend muss soss doruechter wunnen, well zwee Prozesser kënnen net déiselwecht Adress a Port bannen.

Kontrolléier all Been do wou et wierklech leeft

Validéier d'Konfiguratioun mam installéierte Parser virun all Nei-Lueden, datt en Tippfeeler de Lauschterer dee grad zerwéiert net erofgeet.

Test dann de Backend-Been vum Frontend-Host selwer, am selwechten Netz-Kontext deen den Nginx benotzt. E Ping duerch den Tunnel beweise d'Erreechbarkeet a näischt iwwer TLS, Autorisatioun oder d'Applikatioun.

Um Schluss maach eng frësch ëffentlech Ufro op den echte Hostnumm mat normaler Zertifikatsverifizéierung, an observéier den Äntwertwee amplaz just den Äntwertkierper.

Behäl béid Observatiounen zesumme mat der ausgerullter Konfiguratioun, a notéier wat geschitt wann den Tunnel net disponibel ass. D'Frontend soll e kontrolléierte Upstream-Fehler zréckschécken, net stillech op en anere Backend falen deen keen dokumentéiert huet. En 502 mat enger kloerer Loglinn ass en gutt Resultat. Eng gecachte Säit vun engem ongewollten Urspronk ass keen gutt Resultat.

Ähnlech Artikelen