Korleis ein offentleg proxy når eit privat opphav gjennom ein VPN

Å publisere ein nettstad gjennom ein tunnel og å gje brukarar VPN-tilgang er to ulike ordningar som deler éin kabel. I den første tek ein offentleg omvend proxy imot førespurnaden frå vitjande og sender han vidare gjennom tunnelen til eit opphav som ingen kan nå direkte. I den andre må brukaren bli med i VPN-en før applikasjonen i det heile er tilgjengeleg. Å blande dei to skildringane er måten eit privat backend endar opp med å bli offentleg eksponert.

To modellar som ser like ut på eit diagram

Teikn pilene før du vel noko. Ein offentleg publiseringsmodell går frå nettlesar til proxy over HTTPS, deretter frå proxy til opphav gjennom tunnelen, og opphavet godtek aldri ei tilkopling frå internett. Ein VPN-berre-modell går frå klient til gateway, og applikasjonen er berre tilgjengeleg innanfrå den vegen. Den berbare datamaskinen til brukaren sit på same nettverket som applikasjonen, og det er heile poenget med den modellen.

Modellane skil seg i kven som autentiserer og kvar. I den første er proxyen den offentlege inngangen, og han sender vidare kvar førespurnad som kjem, også ein fiendtleg, underlagt policyen som er konfigurert på han. I den andre er tilgjengelegheita sjølv porten, noko som er grov men reell inngang.

Kvar TLS stoppar, og kva det eigentleg beviser

TLS mellom nettlesar og proxy vernar det hoppet og lèt nettlesaren verifisere nettstaden han hadde tenkt å besøke. Viss proxyen avsluttar TLS, finst førespurnaden i lesbar form inne i den prosessen før han blir send vidare. Ei andre TLS-økt til opphavet kan verne det neste hoppet og verifisere endepunktet til applikasjonen separat. Ingen av øktene avgjer kva menneske som får bruke applikasjonen. Eit wildcard-sertifikat på proxyen strekkjer seg heller ikkje til det andre hoppet.

Dette er delen folk samlar i ordet kryptert. Konfidensialitet, integritet og serveridentitet er transporteigenskapar; autorisasjon er ei avgjerd i applikasjonen. Ei privat adresse bak ein tunnel endrar kven som kan nå socketen, ikkje kven som får logge inn når dei gjer det.

Stol berre på vidaresende headarar frå proxyen

Applikasjonar som loggar eller autoriserer på klientadressa les vanlegvis ein header som proxyen legg til. Den headeren er berre tekst, så alt som kan nå opphavet direkte kan hevde kva som helst adresse det vil. Avgrense opphavet slik at berre tunneladressa til proxyen kan kople til, og konfigurer applikasjonen til å godta headeren berre frå den adressa.

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

Viss den førespurnaden lykkast frå ein vert som ikkje er proxyen, stolar opphavet på ein header det burde ignorere. Fiks lyttaren før du rører applikasjonen. Ei avvising er eit mykje betre resultat enn ei logglinje som ber ei forfalska adresse.

Hald opphavet tilgjengeleg frå nøyaktig éin stad

Bind lyttaren til opphavet til tunneladressa eller skjerm han med ein brannmur mot proxyen, og stadfest deretter kva som faktisk lyttar. Ein teneste som blir starta med ei wildcard-binding godtek tilkoplingar på kvart grensesnitt verten har, også eit du gløymde var rutbart. Lyttetabellen er grunnsaninga, ikkje konfigurasjonsfila du hadde tenkt å bruke. Viss wildcard-bindinga er tilsikta, må brannmuren framleis vere komponenten som snevrar ho inn.

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

Gjer den same gjennomgangen for administrasjonsgrensesnitt, som er den vanlege utilsikta eksponeringa. Skriv deretter dei to modellane ned kvar for seg: den offentlege nettstaden gjennom proxyen, og administrasjonsgrensesnittet som berre er tilgjengeleg gjennom tunnelen. Setninga om at serveren er bak ein VPN seier ingenting av det.