HTTP-proxy, SSH-tonnel of VPN: kies die regte laag

Vra drie ingenieurs hoe om ’n interne diens te bereik, en jy kry drie ontwerpe: ’n webproxy, ’n SSH-tonnel of ’n volle VPN. Al drie kan ’n afgeleë diens binne bereik bring, en al drie kan verkeer laat lyk of dit van elders kom. Die verskille kom later na vore, wanneer die protokol in gebruik nie die een is wat die gekose hulpmiddel aanneem nie. ’n Ontwerp wat ’n vinnige blaaierkontrole slaag, faal gereeld op die toepassing wat die versoek gemotiveer het.

Besluit op grond van twee feite: watter protokolle moet deur, en wie kan die betrokke name oplos. Alles anders is voorkeur.

’n Proxy skuif net wat hy verstaan

’n Webproxy ontleed die protokol waarvoor hy gebou is. Die kliënt gee vir hom ’n versoek, en hy gee daardie versoek verder, so ’n toepassing sonder proxy-instellings neem glad nie deel nie. Vir HTTPS het die kliënt ’n ondeursigtige kanaal nodig, wat die proxy deur CONNECT verskaf eerder as deur die versoek te lees.

’n SSH-dinamiese deurvoer open ’n plaaslike poort wat SOCKS praat, en daardie poort stuur ’n TCP-stroom na enige bestemming wat die kliënt noem. Protokolle wat op TCP gebou is, werk gewoonlik daardeur. UDP werk nie, tensy ’n hulpmiddel dit eksplisiet byvoeg nie. ’n Plaaslike deurvoer is weer smaller: een plaaslike poort wat op een vaste gasheer en poort gekarteer is, wat ’n enkele bekende diens dien en niks meer nie.

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

’n VPN skuif pakkette. Alles wat die kliënt in die tonnel instuur, gaan deur, UDP en ICMP ingesluit, en daarom pas dit by ’n netwerkvereiste eerder as by ’n enkele verbinding.

Iemand moet die naam oplos

Wanneer die teikennaam net in die afgeleë netwerk se DNS bestaan, moet die kas wat die opsoek doen daardie sone kan sien. ’n Webproxy doen self die opsoek, so ’n interne naam werk daardeur selfs wanneer die skootrekenaar die naam glad nie kan oplos nie. SOCKS kan dieselfde doen, maar net as die kliënt die naam deurstuur in plaas daarvan om aan ’n adres te koppel wat dit reeds opgelos het. Daardie keuse is in die kliënt, nie in die bediener nie.

curl wys die skeiding duidelik: een vlag gee die gasheernaam aan die proxy, ’n ander los dit eers plaaslik op. Met plaaslike oplossing misluk ’n naam wat net intern bestaan voordat enige tonnel geraak word, en die fout blameer die proxy vir wat eintlik ’n DNS-besluit was.

’n VPN volg die derde roete deur die private oplosser en soekdomein langs die roetes te installeer. Dit is gerieflik, en dit skep ’n bekende illusie: ’n roete wat bestaan met ’n oplosser wat nie antwoord nie, lyk presies soos ’n dooie tonnel, selfs al bereik pakkette die oorkant.

Wanneer die netwerk net een uitgang toelaat

Baie korporatiewe netwerke laat uitgaande verbindings slegs deur ’n geauthentiseerde webproxy toe. OpenVPN en SSH kan albei daar laat werk, die eerste deur sy eie vervoer deur die proxy te tonnel en die tweede deur ’n proxy-opdrag wat ’n klein CONNECT-hulpprogram hardloop.

Tonnels wat op TCP gebou is, oorleef daardie beperking, en ’n VPN op UDP-basis nie, wat baie konfigurasies verduidelik wat by die huis werk en in ’n kantoor faal. ’n Tweede koste is maklik om te mis: ’n TCP-tonnel wat in ’n TCP-verbinding deur ’n proxy gedra word, het nou twee lae wat herstuur, en onder verlies staak daardie paring op ’n manier wat geen laag alleen veroorsaak nie.

Om tussengangers te ketting is ’n ander vraag as om ’n laag te kies. ’n Tweede proxy of Tor byvoeg verander wie wat waarneem, en die posisie in die ketting bepaal watter hop die syferteks sien.

Orde maak meer saak as die aantal hope. ’n Buitehop kyk na ’n versleutelde stroom terwyl ’n binnehop die gewone teks sien wat dit dra, so ’n ketting is net so privaat as sy minste sorgsame skakel. Om protokolle oor hope te meng verbeter dit nie outomaties nie. Dit maak meestal die foutmodusse moeiliker om te beredeneer.

’n Vervalste adres is nie een van die opsies nie

Om pakkette met iemand anders se bronadres te maak, bereik niks nuttigs nie: antwoorde reis na die regte eienaar, en die meeste netwerke laat die verkeer heeltemal val. ’n Tussenganger is juis nodig omdat die bron nie uitgedink kan word nie, en dit is die eerlike regverdiging vir al drie ontwerpe.

Dit beperk ook wat enigeen van hulle mag beweer. Om voor te kom asof dit van ’n bepaalde adres kom, is ’n vraag oor waar daardie adres wettig toegeken is en wie dit mag roeteer, nie oor watter hulpmiddel ’n kop kan vervals nie. As ’n ontwerp anders aanneem, faal die aanname by die eerste verskaffer wat dit filter. Skryf die aanname neer sodat die fout herkenbaar is wanneer dit opdaag.

Besluit volgens protokolle en name

Gryp na ’n proxy wanneer ’n enkele webkliënt ’n enkele webdiens nodig het en dit proxy-instellings het. Gryp na ’n SSH-tonnel wanneer ’n handvol bekende TCP-dienste genoeg is en SSH-toegang reeds bestaan. Gryp na ’n VPN wanneer verskeie toepassings, nie-TCP-verkeer, private DNS of ’n herbruikbare pad deel van die vereiste vorm.

Verifieer dan met die werklike kliënt en die werklike naam. Om ’n bladsy deur ’n proxy te laai, leer jou niks oor UDP nie, en om een hulpmiddel oor SOCKS werkend te kry, leer jou niks oor die stelseloplosser nie. Lees watter plaaslike adres die proses gebind het en watter oplosser geantwoord het. Dit is die verskil tussen ’n pad wat werk en een wat toevallig een keer gewerk het.