Miten julkinen välityspalvelin saavuttaa yksityisen alkuperän VPN:n kautta

Sivuston julkaiseminen tunnelin kautta ja VPN-pääsyn antaminen käyttäjille ovat kaksi eri järjestelyä, jotka jakavat saman kaapelin. Ensimmäisessä julkinen käänteinen välityspalvelin vastaanottaa vierailijan pyynnön ja välittää sen tunnelin kautta alkuperään, johon kukaan ei pääse suoraan. Toisessa käyttäjän on liityttävä VPN:hen ennen kuin sovellus on ylipäätään tavoitettavissa. Kahden kuvauksen sekoittaminen on se tapa, jolla yksityinen taustajärjestelmä lopulta päätyy julkisesti paljastetuksi.

Kaksi mallia, jotka näyttävät kaaviossa samalta

Piirrä nuolet ennen kuin valitset mitään. Julkisen julkaisun malli kulkee selaimesta välityspalvelimeen HTTPS:n yli, sitten välityspalvelimesta alkuperään tunnelin kautta, eikä alkuperä koskaan hyväksy yhteyttä internetistä. Vain VPN -malli kulkee asiakkaasta yhdyskäytävään, ja sovellus on tavoitettavissa vain kyseisen reitin sisältä. Käyttäjän kannettava on samassa verkossa kuin sovellus, ja se on koko kyseisen mallin idea.

Mallit eroavat siinä, kuka todentaa ja missä. Ensimmäisessä välityspalvelin on julkinen sisäänkäynti ja se välittää jokaisen saapuvan pyynnön, myös vihamielisen, siihen määritetyn käytännön mukaisesti. Toisessa tavoitettavuus itsessään on portti, mikä on karkea mutta todellinen hyväksyntä.

Mihin TLS pysähtyy ja mitä se todella todistaa

Selaimen ja välityspalvelimen välinen TLS suojaa kyseisen hypyn ja antaa selaimen varmistaa sivuston, jota se aikoi vierailla. Jos välityspalvelin päättää TLS:n, pyyntö on luettavassa muodossa kyseisen prosessin sisällä ennen välitystä. Toinen TLS-istunto alkuperään voi suojata seuraavan hypyn ja varmistaa sovelluksen päätepisteen erikseen. Kumpikaan istunto ei päätä, kuka ihminen saa käyttää sovellusta. Välityspalvelimen jokerimerkkivarmenne ei myöskään ulotu tuohon toiseen hyppyyn.

Tämä on se osa, jonka ihmiset tiivistävät sanaan salattu. Luottamuksellisuus, eheys ja palvelimen identiteetti ovat siirtokerroksen ominaisuuksia; valtuutus on sovelluksen päätös. Yksityinen osoite tunnelin takana muuttaa sitä, kuka pääsee pistokkeeseen, ei sitä, kuka saa kirjautua sisään kun pääsee.

Luota välitettyihin otsakkeisiin vain välityspalvelimelta

Sovellukset, jotka kirjaavat tai valtuuttavat asiakkaan osoitteen perusteella, lukevat yleensä otsakkeen, jonka välityspalvelin lisää. Se otsake on vain tekstiä, joten mikä tahansa, mikä pääsee suoraan alkuperään, voi väittää mitä tahansa osoitetta. Rajoita alkuperä niin, että vain välityspalvelimen tunneliosoite voi muodostaa yhteyden, ja määritä sovellus hyväksymään otsake vain kyseisestä osoitteesta.

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

Jos pyyntö onnistuu isännästä, joka ei ole välityspalvelin, alkuperä luottaa otsakkeeseen, joka sen pitäisi jättää huomiotta. Korjaa kuuntelija ennen kuin kosket sovellukseen. Hylkäys on paljon parempi lopputulos kuin väärennetyn osoitteen sisältävä lokirivi.

Pidä alkuperä tavoitettavissa täsmälleen yhdestä paikasta

Sido alkuperän kuuntelija tunneliosoitteeseen tai rajaa se palomuurilla välityspalvelinta kohti, ja vahvista sitten, mikä todella kuuntelee. Jokerimerkkisidonnalla käynnistetty palvelu hyväksyy yhteyksiä jokaisessa isännän rajapinnassa, myös sellaisessa, jonka olet unohtanut olevan reititettävissä. Kuuntelutaulukko on perustotuus, ei se asetustiedosto, jonka aioit ottaa käyttöön. Jos jokerimerkkisidonta on tarkoituksellinen, palomuurin on silti oltava se komponentti, joka kaventaa sitä.

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

Tee sama katsaus hallintarajapinnoille, jotka ovat tavallinen tahaton paljastuminen. Kirjoita sitten kaksi mallia erikseen: julkinen sivusto välityspalvelimen kautta ja hallintarajapinta, joka on tavoitettavissa vain tunnelin kautta. Lause, että palvelin on VPN:n takana, ei kerro mistään niistä.