HTTP-proxy, SSH-alagút vagy VPN: válassza a megfelelő réteget

Kérdezzen meg három mérnököt, hogyan érhető el egy belső szolgáltatás, és három tervet kap: webproxy, SSH-alagút vagy teljes VPN. Mindhárom elérhetővé tehet egy távoli szolgáltatást, és mindhárom elhitetheti, hogy a forgalom máshonnan érkezik. A különbségek később mutatkoznak meg, amikor a használt protokoll nem az, amelyet a választott eszköz feltételez. Egy terv, amely átmegy egy gyors böngészőellenőrzésen, rendszeresen elbukik azon az alkalmazáson, amely a kérést kiváltotta.

Két tényből döntsön: mely protokolloknak kell átjutniuk, és ki tudja feloldani az érintett neveket. Minden más ízlés kérdése.

A proxy csak azt mozgatja, amit megért

A webproxy azt a protokollt elemzi, amelyre épült. Az ügyfél átad neki egy kérést, és az továbbadja azt, így a proxybeállítás nélküli alkalmazás egyáltalán nem vesz részt. HTTPS-hez az ügyfélnek átlátszatlan csatornára van szüksége, amelyet a proxy CONNECT-tel biztosít, nem a kérés olvasásával.

Az SSH dinamikus továbbítása megnyit egy helyi portot, amely SOCKS-t beszél, és ez a port TCP-folyamot továbbít bármely célhoz, amelyet az ügyfél megnevez. A TCP-re épülő protokollok általában működnek rajta keresztül. Az UDP nem, hacsak egy eszköz nem ad hozzá kifejezett támogatást. A helyi továbbítás még szűkebb: egy helyi port egyetlen rögzített hoszthoz és porthoz rendelve, ami egyetlen ismert szolgáltatást szolgál ki, semmi mást.

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

A VPN csomagokat mozgat. Minden, amit az ügyfél az alagútba irányít, átmegy rajta, az UDP és az ICMP is, ezért hálózati követelményhez illik, nem egyetlen kapcsolathoz.

Valakinek fel kell oldania a nevet

Amikor a cél szerinti név csak a távoli hálózat DNS-ében létezik, a lekérdezést végző gépnek látnia kell azt a zónát. A webproxy maga végzi a lekérdezést, így egy belső név rajta keresztül működik akkor is, amikor a laptop egyáltalán nem tudja feloldani a nevet. A SOCKS ugyanígy viselkedhet, de csak akkor, ha az ügyfél továbbadja a nevet, ahelyett hogy egy már feloldott címhez kapcsolódna. Ez a választás az ügyfélben van, nem a kiszolgálóban.

A curl tisztán mutatja a szétválaszt: az egyik kapcsoló átadja a hosztnevet a proxynak, a másik előbb helyben oldja fel. Helyi feloldással egy csak belső név még azelőtt elbukik, hogy bármelyik alagutat érintenénk, és a hiba a proxyt hibáztatja azért, ami valójában DNS-döntés volt.

A VPN a harmadik utat választja: az útvonalak mellé telepíti a privát feloldót és a keresési tartományt. Ez kényelmes, és ismerős illúziót teremt: egy útvonal, amely létezik egy nem válaszoló feloldó mellett, pontosan halott alagútnak látszik, pedig a csomagok elérik a túloldalt.

Amikor a hálózat csak egy kijáratot engedélyez

Sok vállalati hálózat csak hitelesített webproxyn keresztül engedélyezi a kimenő kapcsolatokat. OpenVPN és SSH is működőképessé tehető ott: az előbbi a saját átvitelét alagútaztatja a proxyn keresztül, az utóbbi egy proxyparanccsal, amely egy kis CONNECT-segédet futtat.

A TCP-re épülő alagutak túlélik ezt a korlátot, a UDP-alapú VPN pedig nem, ami rengeteg olyan konfigurációt megmagyaráz, amely otthon működik és irodában elbukik. Egy második költséget könnyű kihagyni: a proxyn keresztüli TCP-kapcsolatban vitt TCP-alagútban most két réteg küld újra, és veszteség esetén ez a pár olyan módon akad meg, amelyet egyik réteg sem produkál egyedül.

A közvetítők láncolása más kérdés, mint egy réteg kiválasztása. Egy második proxy vagy a Tor hozzáadása megváltoztatja, ki mit figyel meg, és a láncban elfoglalt hely dönti el, melyik ugrás látja a rejtjelezett szöveget.

A sorrend fontosabb, mint az ugrások száma. Egy külső ugrás titkosított folyamot lát, míg egy belső a szállított nyílt szöveget, így egy lánc csak annyira titkos, mint a legkevésbé gondos láncszeme. A protokollok ugrások közötti keverése ezt nem javítja automatikusan. Többnyire nehezebbé teszi a hibaformák végiggondolását.

A hamisított cím nem tartozik a lehetőségek közé

Csomagokat gyártani valaki más forráscímével semmi hasznosat nem ér el: a válaszok a valódi tulajdonoshoz utaznak, és a legtöbb hálózat egyszerűen eldobja a forgalmat. Éppen azért kell közvetítő, mert a forrás nem található ki, és ez a három terv őszinte indoklása.

Ez azt is korlátozza, hogy bármelyikük mit állíthat. Annak látszani, hogy a forgalom egy adott címről indul, arról szól, hol van ez a cím jogszerűen kiosztva és ki irányíthatja, nem arról, melyik eszköz tud fejlécet hamisítani. Ha egy terv mást feltételez, a feltevés az első olyan szolgáltatónál megbukik, amely szűri. Írja le a feltevést, hogy a hiba felismerhető legyen, amikor megérkezik.

Protokollok és nevek alapján döntsön

Válasszon proxyt, amikor egyetlen webes ügyfélnek egyetlen webes szolgáltatás kell, és van proxybeállítása. Válasszon SSH-alagutat, amikor néhány ismert TCP-szolgáltatás elég, és az SSH-hozzáférés már megvan. Válasszon VPN-t, amikor több alkalmazás, nem TCP-forgalom, privát DNS vagy újrahasznosítható útvonal része a követelménynek.

Utána ellenőrizze a valódi ügyféllel és a valódi névvel. Egy oldal proxyn keresztüli betöltése semmit sem tanít az UDP-ről, és egy eszköz SOCKS-on keresztüli működtetése semmit sem tanít a rendszer feloldójáról. Olvassa ki, melyik helyi címhez kötődött a folyamat, és melyik feloldó válaszolt. Ez a különbség a működő útvonal és az között, amely egyszer véletlenül működött.