Kako javni proxy doseže zasebni izvor prek VPN

Objavljanje spletnega mesta prek tunela in dajanje uporabnikom dostopa do VPN sta dve različni ureditvi, ki si delita en kabel. Pri prvi javni povratni proxy sprejme zahtevo obiskovalca in jo posreduje prek tunela do izvora, do katerega nihče ne more priti neposredno. Pri drugi se mora uporabnik pridružiti VPN, preden je aplikacija sploh dosegljiva. Mešanje obeh opisov je pot, po kateri zasebni backend na koncu konča javno izpostavljen.

Dva modela, ki sta na diagramu videti enako

Narišite puščice, preden karkoli izberete. Model javne objave gre od brskalnika do proxyja po HTTPS, nato od proxyja do izvora skozi tunel, in izvor nikoli ne sprejme povezave iz interneta. Model samo z VPN gre od odjemalca do prehoda, in aplikacija je dosegljiva le od znotraj te poti. Prenosnik uporabnika sedi v istem omrežju kot aplikacija, in to je ves smisel tega modela.

Modela se razlikujeta v tem, kdo overja in kje. Pri prvem je proxy javni vhod in posreduje vsako zahtevo, ki prispe, tudi sovražno, v skladu s politiko, nastavljeno na njem. Pri drugem so vrata dosegljivost sama, kar je grob, a resničen sprejem.

Kje se TLS ustavi in kaj v resnici dokazuje

TLS med brskalnikom in proxyjem ščiti ta skok in brskalniku omogoča, da preveri mesto, ki ga je nameraval obiskati. Če proxy zaključi TLS, zahteva obstaja v berljivi obliki znotraj tega procesa, preden se posreduje. Druga seja TLS do izvora lahko zaščiti naslednji skok in ločeno preveri končno točko aplikacije. Nobena seja ne odloči, kateri človek sme uporabljati aplikacijo. Potrdilo z nadomestnim znakom na proxyju se tudi ne razširi na ta drugi skok.

To je del, ki ga ljudje strnejo v besedo šifrirano. Zaupnost, celovitost in identiteta strežnika so lastnosti prenosa; avtorizacija je odločitev aplikacije. Zasebni naslov za tunelom spremeni kdo lahko doseže vtičnico, ne pa kdo se lahko prijavi, ko jo doseže.

Zaupajte posredovanim glavam le od proxyja

Aplikacije, ki beležijo ali avtorizirajo glede na naslov odjemalca, običajno berejo glavo, ki jo doda proxy. Ta glava je le besedilo, zato lahko karkoli, kar doseže izvor neposredno, zahteva kateri koli naslov. Omejite izvor tako, da se lahko poveže le naslov tunela proxyja, in nastavite aplikacijo, da glavo sprejme samo z tega naslova.

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

Če ta zahteva uspe z gostitelja, ki ni proxy, izvor zaupa glavi, ki bi jo moral prezreti. Popravite poslušalec, preden se dotaknete aplikacije. Zavrnitev je veliko boljši izid kot vrstica dnevnika s ponarejenim naslovom.

Ohranite izvor dosegljiv natanko z enega mesta

Povežite poslušalec izvora z naslovom tunela ali ga ogradite z požarnim zidom proti proxyju, nato potrdite, kaj v resnici posluša. Storitev, zagnana z vezavo z nadomestnim znakom, sprejema povezave na vsakem vmesniku, ki ga ima gostitelj, tudi na tistem, za katerega ste pozabili, da je usmerljiv. Tabela poslušanja je osnovna resnica, ne konfiguracijska datoteka, ki ste jo nameravali uporabiti. Če je vezava z nadomestnim znakom namerna, mora biti požarni zid še vedno sestavni del, ki jo zoži.

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

Enak pregled opravite za upravljalne vmesnike, ki so običajna naključna izpostavljenost. Nato zapišite oba modela ločeno: javno spletno mesto prek proxyja in upravljalni vmesnik, dosegljiv le prek tunela. Stavek, da je strežnik za VPN, ne pove nič od tega.