Kaip viešasis tarpinis serveris per VPN pasiekia privatų šaltinį

Svetainės publikavimas per tunelį ir VPN prieigos suteikimas naudotojams yra du skirtingi išdėstymai, kurie dalijasi vienu kabeliu. Pirmajame viešas atvirkštinis tarpinis serveris priima lankytojo užklausą ir perduoda ją per tunelį į šaltinį, kurio niekas negali pasiekti tiesiogiai. Antrajame naudotojas turi prisijungti prie VPN, kol programa apskritai taps pasiekiama. Šių dviejų aprašymų sumaišymas yra kelias, kuriuo privatus backend galiausiai atsiduria viešai atskleistas.

Du modeliai, diagramoje atrodantys vienodai

Nubrėžkite rodykles prieš ką nors pasirinkdami. Viešo publikavimo modelis eina iš naršyklės į tarpinį serverį per HTTPS, paskui iš tarpinio serverio į šaltinį per tunelį, o šaltinis niekada nepriima ryšio iš interneto. Tik VPN modelis eina iš kliento į šliuzą, o programa pasiekiama tik iš to kelio vidaus. Naudotojo nešiojamasis kompiuteris yra tame pačiame tinkle kaip programa, ir tai yra visa to modelio esmė.

Modeliai skiriasi tuo, kas autentifikuoja ir kur. Pirmajame tarpinis serveris yra viešas įėjimas ir perduoda bet kokią atvykstančią užklausą, įskaitant priešišką, pagal jame sukonfigūruotą politiką. Antrajame pats pasiekiamumas yra vartai, ir tai yra grubus, bet tikras priėmimas.

Kur sustoja TLS ir ką ji iš tikrųjų įrodo

TLS tarp naršyklės ir tarpinio serverio apsaugo tą šuolį ir leidžia naršyklei patikrinti svetainę, kurią ketino aplankyti. Jei tarpinis serveris užbaigia TLS, užklausa egzistuoja skaitoma forma to proceso viduje prieš perduodant. Antroji TLS sesija į šaltinį gali apsaugoti kitą šuolį ir atskirai patikrinti programos galinį tašką. Nė viena sesija nenusprendžia, kuris žmogus gali naudotis programa. Pakaitos simbolio sertifikatas tarpiniame serveryje taip pat neapima to antrojo šuolio.

Tai dalis, kurią žmonės sutraukia į žodį užšifruota. Konfidencialumas, vientisumas ir serverio tapatybė yra transporto savybės; autorizacija yra programos sprendimas. Privatus adresas už tunelio keičia kas gali pasiekti lizdą, o ne kas gali prisijungti jį pasiekęs.

Pasitikėkite persiunčiamomis antraštėmis tik iš tarpinio serverio

Programos, kurios registruoja arba autorizuoja pagal kliento adresą, paprastai skaito antraštę, kurią prideda tarpinis serveris. Ta antraštė yra tik tekstas, todėl viskas, kas gali tiesiogiai pasiekti šaltinį, gali teigti bet kokį adresą. Apribokite šaltinį taip, kad jungtis galėtų tik tarpinio serverio tunelio adresas, ir sukonfigūruokite programą priimti antraštę tik iš to adreso.

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

Jei ta užklausa pavyksta iš hosto, kuris nėra tarpinis serveris, šaltinis pasitiki antrašte, kurios turėtų nepaisyti. Pataisykite klausytuvą prieš liesdami programą. Atsisakymas yra daug geresnis rezultatas nei žurnalo eilutė su suklastotu adresu.

Laikykite šaltinį pasiekiamą tiksliai iš vienos vietos

Susiekite šaltinio klausytuvą su tunelio adresu arba atitverkite jį užtvara link tarpinio serverio, tada patvirtinkite, kas iš tikrųjų klausosi. Paslauga, paleista su pakaitos simbolio susiejimu, priima ryšius kiekviename sąsajoje, kurią turi hostas, įskaitant tą, kurią pamiršote esant maršrutizuojamą. Klausymo lentelė yra pagrindinė tiesa, o ne konfigūracijos failas, kurį ketinote taikyti. Jei pakaitos simbolio susiejimas yra sąmoningas, užtvara vis tiek turi būti tas komponentas, kuris jį susiaurina.

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

Atlikite tą pačią apžvalgą valdymo sąsajoms, kurios paprastai yra atsitiktinis atskleidimas. Tada užrašykite du modelius atskirai: viešą svetainę per tarpinį serverį ir administravimo sąsają, pasiekiamą tik per tunelį. Sakinys, kad serveris yra už VPN, nieko iš to nesako.