Hvordan en offentlig proxy når et privat opphav gjennom en VPN

Å publisere et nettsted gjennom en tunnel og å gi brukere VPN-tilgang er to forskjellige ordninger som deler én kabel. I den første tar en offentlig omvendt proxy imot besøkendes forespørsel og videresender den gjennom tunnelen til et opphav som ingen kan nå direkte. I den andre må brukeren bli med i VPN-en før applikasjonen i det hele tatt er tilgjengelig. Å blande de to beskrivelsene er måten et privat backend ender opp med å bli offentlig eksponert.

To modeller som ser like ut på et diagram

Tegn pilene før du velger noe. En offentlig publiseringsmodell går fra nettleser til proxy over HTTPS, deretter fra proxy til opphav gjennom tunnelen, og opphavet godtar aldri en tilkobling fra internett. En VPN-bare-modell går fra klient til gateway, og applikasjonen er bare tilgjengelig innenfra den veien. Brukerens bærbare datamaskin sitter på samme nettverk som applikasjonen, og det er hele poenget med den modellen.

Modellene skiller seg i hvem som autentiserer og hvor. I den første er proxyen den offentlige inngangen, og den videresender enhver forespørsel som kommer, også en fiendtlig, underlagt policyen som er konfigurert på den. I den andre er tilgjengeligheten selv porten, noe som er grov men reell inngang.

Hvor TLS stopper, og hva det egentlig beviser

TLS mellom nettleser og proxy beskytter det hoppet og lar nettleseren verifisere nettstedet den hadde tenkt å besøke. Hvis proxyen avslutter TLS, finnes forespørselen i lesbar form inne i den prosessen før den videresendes. En andre TLS-økt til opphavet kan beskytte det neste hoppet og verifisere applikasjonens endepunkt separat. Ingen av øktene avgjør hvilket menneske som får bruke applikasjonen. Et wildcard-sertifikat på proxyen strekker seg heller ikke til det andre hoppet.

Dette er delen folk samler i ordet kryptert. Konfidensialitet, integritet og serveridentitet er transportegenskaper; autorisasjon er en applikasjonsbeslutning. En privat adresse bak en tunnel endrer hvem som kan nå socketen, ikke hvem som får logge inn når de gjør det.

Stol bare på videresendte headere fra proxyen

Applikasjoner som logger eller autoriserer på klientadressen leser vanligvis en header som proxyen legger til. Den headeren er bare tekst, så alt som kan nå opphavet direkte kan hevde hvilken som helst adresse det vil. Begrens opphavet slik at bare proxyens tunneladresse kan koble til, og konfigurer applikasjonen til å godta headeren bare fra den adressen.

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

Hvis den forespørselen lykkes fra en vert som ikke er proxyen, stoler opphavet på en header det burde ignorere. Fiks lytteren før du rører applikasjonen. En avvisning er et mye bedre resultat enn en logglinje som bærer en forfalsket adresse.

Hold opphavet tilgjengelig fra nøyaktig ett sted

Bind opphavets lytter til tunneladressen eller skjerm det med en brannmur mot proxyen, og bekreft deretter hva som faktisk lytter. En tjeneste som startes med en wildcard-binding godtar tilkoblinger på hvert grensesnitt verten har, også et du glemte var rutbart. Lyttetabellen er grunnsannheten, ikke konfigurasjonsfilen du hadde tenkt å bruke. Hvis wildcard-bindingen er tilsiktet, må brannmuren fortsatt være komponenten som snevrer den inn.

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

Gjør den samme gjennomgangen for administrasjonsgrensesnitt, som er den vanlige utilsiktede eksponeringen. Skriv deretter de to modellene ned hver for seg: det offentlige nettstedet gjennom proxyen, og administrasjonsgrensesnittet som bare er tilgjengelig gjennom tunnelen. Setningen om at serveren er bak en VPN sier ingenting av det.