Hur en offentlig proxy når ett privat ursprung genom en VPN

Att publicera en webbplats genom en tunnel och att ge användare VPN-åtkomst är två olika arrangemang som delar en kabel. I det första tar en offentlig omvänd proxy emot besökarens begäran och vidarebefordrar den genom tunneln till ett ursprung som ingen kan nå direkt. I det andra måste användaren ansluta till VPN:en innan applikationen ens är nåbar. Att blanda de två beskrivningarna är hur en privat backend till slut blir offentligt exponerad.

Två modeller som ser likadana ut på ett diagram

Rita pilarna innan du väljer något. En offentlig publiceringsmodell går från webbläsare till proxy över HTTPS, sedan från proxy till ursprung genom tunneln, och ursprunget accepterar aldrig en anslutning från internet. En VPN-bara-modell går från klient till gateway, och applikationen är bara nåbar inifrån den vägen. Användarens bärbara dator sitter på samma nätverk som applikationen, och det är hela poängen med den modellen.

Modellerna skiljer sig i vem som autentiserar och var. I det första är proxyn den offentliga ingången och den vidarebefordrar varje begäran som kommer, även en fientlig, enligt policyn som konfigurerats på den. I det andra är nåbarheten själv porten, vilket är grovt men verkligt intag.

Var TLS stannar, och vad det faktiskt bevisar

TLS mellan webbläsare och proxy skyddar det hoppet och låter webbläsaren verifiera webbplatsen den tänkte besöka. Om proxyn avslutar TLS finns begäran i läsbar form inne i den processen innan den vidarebefordras. En andra TLS-session till ursprunget kan skydda nästa hopp och verifiera applikationens slutpunkt separat. Ingen av sessionerna avgör vilken människa som får använda applikationen. Ett wildcard-certifikat på proxyn sträcker sig inte heller till det andra hoppet.

Det här är delen som folk sammanfattar i ordet krypterat. Konfidentialitet, integritet och serveridentitet är transportegenskaper; auktorisering är ett applikationsbeslut. En privat adress bakom en tunnel ändrar vem som kan nå socketen, inte vem som får logga in när de gör det.

Lita på vidarebefordrade huvuden endast från proxyn

Applikationer som loggar eller auktoriserar på klientadressen läser vanligtvis en header som proxyn lägger till. Den headern är bara text, så allt som kan nå ursprunget direkt kan hävda vilken adress som helst. Begränsa ursprunget så att bara proxyns tunneladress kan ansluta, och konfigurera applikationen att acceptera headern endast från den adressen.

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

Om den begäran lyckas från en värd som inte är proxyn litar ursprunget på en header som det borde ignorera. Åtgärda lyssnaren innan du rör applikationen. Ett avslag är ett mycket bättre resultat än en logglinje med en förfalskad adress.

Håll ursprunget nåbart från exakt en plats

Bind ursprungets lyssnare till tunneladressen eller skydda det med en brandvägg mot proxyn, och bekräfta sedan vad som faktiskt lyssnar. En tjänst som startas med en wildcard-bindning accepterar anslutningar på varje gränssnitt som värden har, även ett du glömt var dirigerbart. Lyssnartabellen är grundsanningen, inte konfigurationsfilen du tänkte tillämpa. Om wildcard-bindningen är avsiktlig måste brandväggen ändå vara komponenten som begränsar den.

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

Gör samma genomgång för administrationsgränssnitt, som är den vanliga oavsiktliga exponeringen. Skriv sedan ner de två modellerna var för sig: den offentliga webbplatsen genom proxyn, och administrationsgränssnittet som bara är nåbart genom tunneln. Meningen att servern är bakom en VPN säger inget av det.