HTTP-välityspalvelin, SSH-tunneli vai VPN: valitse oikea kerros

Kysy kolmelta insinööriltä, miten sisäiseen palveluun päästään, ja saat kolme suunnitelmaa: web-välityspalvelin, SSH-tunneli tai täysi VPN. Kaikki kolme voivat tuoda etäpalvelun ulottuville, ja kaikki kolme voivat saada liikenteen näyttämään siltä kuin se tulisi muualta. Erot paljastuvat myöhemmin, kun käytössä oleva protokolla ei olekaan se, jota valittu työkalu olettaa. Nopean selaintarkistuksen läpäisevä suunnitelma epäonnistuu säännöllisesti sovelluksessa, joka pyynnön synnytti.

Päätä kahdesta asiasta: mitkä protokollat on ylitettävä ja kuka voi selvittää kyseiset nimet. Kaikki muu on mieltymys.

Välityspalvelin siirtää vain sen, mitä se ymmärtää

Web-välityspalvelin jäsentää protokollan, jota varten se on rakennettu. Asiakas antaa sille pyynnön ja se antaa pyynnön eteenpäin, joten sovellus, jolla ei ole välityspalvelinasetusta, ei osallistu lainkaan. HTTPS:ää varten asiakas tarvitsee läpinäkymättömän kanavan, jonka välityspalvelin tarjoaa CONNECTin kautta sen sijaan, että lukisi pyynnön.

SSH:n dynaaminen edelleenohjaus avaa paikallisen portin, joka puhuu SOCKSia, ja se portti välittää TCP-virran mihin tahansa kohteeseen, jonka asiakas nimeää. TCP:lle rakennetut protokollat toimivat yleensä sen kautta. UDP ei, ellei työkalu lisää tukea nimenomaisesti. Paikallinen edelleenohjaus on vielä kapeampi: yksi paikallinen portti yhdistettynä yhteen kiinteään isäntään ja porttiin, mikä palvelee yhtä tunnettua palvelua eikä mitään muuta.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN siirtää paketteja. Kaikki, mitä asiakas reitittää tunneliin, kulkee sen läpi, UDP ja ICMP mukaan lukien, siksi se sopii verkkovaatimukseen eikä yksittäiseen yhteyteen.

Jonkun on selvitettävä nimi

Kun kohdenimi on olemassa vain etäverkon DNS:ssä, kyselyn tekevän koneen on nähtävä se vyöhyke. Web-välityspalvelin tekee kyselyn itse, joten sisäinen nimi toimii sen kautta, vaikka kannettava ei pystyisi selvittämään nimeä lainkaan. SOCKS voi käyttäytyä samoin, mutta vain jos asiakas välittää nimen eteenpäin sen sijaan, että yhdistäisi jo selvittämäänsä osoitteeseen. Tämä valinta on asiakkaassa, ei palvelimessa.

curl näyttää jaon selvästi: yksi valitsin välittää isäntänimen välityspalvelimelle, toinen selvittää sen ensin paikallisesti. Paikallisella selvityksellä vain sisäinen nimi epäonnistuu ennen kuin yhtäkään tunnelia kosketaan, ja virhe syyttää välityspalvelinta asiasta, joka oli todella DNS-päätös.

VPN ottaa kolmannen tien asentamalla yksityisen selvittimen ja hakutoimialueen reittien viereen. Se on kätevää, ja se luo tutun illuusion: reitti, joka on olemassa selvittimen kanssa, joka ei vastaa, näyttää täsmälleen kuolleelta tunnelilta, vaikka paketit saavuttavat toiselle puolelle.

Kun verkko sallii vain yhden uloskäynnin

Monet yritysverkot sallivat lähtevät yhteydet vain todennetun web-välityspalvelimen kautta. OpenVPN ja SSH saadaan molemmat toimimaan siellä: ensimmäinen tunneloi oman siirtonsa välityspalvelimen läpi ja toinen välityspalvelinkomennolla, joka ajaa pientä CONNECT-apuria.

TCP:lle rakennetut tunnelit kestävät tämän rajoituksen, UDP-pohjainen VPN ei, mikä selittää hyvin monet kokoonpanot, jotka toimivat kotona ja epäonnistuvat toimistossa. Toinen hinta on helppo jättää huomaamatta: välityspalvelimen kautta kulkevassa TCP-yhteydessä kannettu TCP-tunneli sisältää nyt kaksi uudelleenlähettävää kerrosta, ja häviöiden vallitessa tuo pari juuttuu tavalla, jota kumpikaan kerros ei yksin tuota.

Välittäjien ketjuttaminen on eri kysymys kuin kerroksen valinta. Toisen välityspalvelimen tai Torin lisääminen muuttaa sitä, kuka havaitsee mitä, ja asema ketjussa päättää, mikä hyppy näkee salakirjoituksen.

Järjestys on tärkeämpi kuin hyppyjen määrä. Ulompi hyppy katsoo salattua virtaa, kun taas sisempi näkee sen kuljettaman selväkielisen tekstin, joten ketju on vain niin yksityinen kuin sen huolimattomin lenkki. Protokollien sekoittaminen hyppyjen välillä ei paranna sitä automaattisesti. Se lähinnä vaikeuttaa vikatilojen hahmottamista.

Väärennetty osoite ei ole yksi vaihtoehdoista

Pakettien rakentaminen toisen lähtöosoitteella ei saavuta mitään hyödyllistä: vastaukset matkaavat oikealle omistajalle, ja useimmat verkot pudottavat liikenteen suoraan. Välittäjä tarvitaan juuri siksi, ettei lähdettä voi keksiä, ja se on kaikkien kolmen suunnitelman rehellinen perustelu.

Se myös rajaa sitä, mitä mikä tahansa niistä voi väittää. Näyttää siltä, että liikenne lähtee tietystä osoitteesta, on kysymys siitä, mihin osoite on laillisesti annettu ja kuka saa reitittää sen, ei siitä, mikä työkalu voi väärentää otsakkeen. Jos suunnitelma olettaa muuta, oletus pettää ensimmäisellä tarjoajalla, joka suodattaa sen. Kirjoita oletus muistiin, jotta vika on tunnistettavissa, kun se tulee.

Päätä protokollien ja nimien perusteella

Valitse välityspalvelin, kun yksi web-asiakas tarvitsee yhtä web-palvelua ja sillä on välityspalvelinasetukset. Valitse SSH-tunneli, kun kourallinen tunnettuja TCP-palveluja riittää ja SSH-yhteys on jo olemassa. Valitse VPN, kun useat sovellukset, ei-TCP-liikenne, yksityinen DNS tai uudelleenkäytettävä polku ovat osa vaatimusta.

Tarkista sitten oikealla asiakkaalla ja oikealla nimellä. Sivun lataaminen välityspalvelimen kautta ei opeta sinulle mitään UDP:stä, eikä yhden työkalun saaminen toimimaan SOCKSin yli opeta sinulle mitään järjestelmän selvittimestä. Lue, mihin paikalliseen osoitteeseen prosessi sitoi ja mikä selvitin vastasi. Se on ero toimivan polun ja kerran sattumalta toimineen polun välillä.