SSH dinamikus továbbítás SOCKS-proxyként a VPN-je fölött

Egy csak SOCKS-ot beszélő alkalmazásnak nincs mivel beszélgetnie egy egyszerű VPN-en, mert az alagút csomagokat szállít, az alkalmazás pedig proxy-végpontot akar. Az OpenSSH tud ilyen végpontot adni, ha a hozzáférés tulajdonosa engedi, mert a dinamikus továbbítás egy SSH-munkamenetet helyi proxyvá alakít. Utána két ugrást kell külön tartani: az alagutat, amely eléri az SSH-gazdagépet, és a kapcsolatot, amelyet az a gazdagép tovább nyit. Szétválasztásuk megmagyarázza, miért működik ez az elrendezés, és azt is, mit soha nem fog tudni.

Mivé válik az SSH-figyelő és mivé nem

A dinamikus továbbítás ráveszi az SSH-klienst, hogy helyben figyeljen, és SOCKS4-et vagy SOCKS5-öt beszéljen mindennel, ami kapcsolódik. Minden kérés megnevez egy célt, és az SSH-kiszolgáló nyitja a további kapcsolatot, ezért a cél feloldása a túloldalon történhet. Ez alkalmazásszintű TCP-továbbítás, nem az egész eszközre szóló VPN. Nem szállít UDP-társítást, ICMP-t, és semmit azoknak az alkalmazásoknak, amelyek teljesen figyelmen kívül hagyják a proxybeállításokat. Az SSH-kiszolgálótól az alkalmazásig tartó ugrás sem az alagútján belül van, ami akkor számít, amikor a cél csak ismert hálózatokból fogad forgalmat.

Az előfeltételek valódiak: útvonal az SSH-gazdagéphez, engedélyezett fiók, ellenőrzött kiszolgáló-gazdagépkulcs és továbbítási engedély. Egyiket sem a proxy hozza létre, és az utóbbi általában az első, amely hiányzik. Erősítse meg mind a négyet, mielőtt bármi mást hibakeresne, mert a kliens felől a hiba ugyanúgy néz ki, bármelyik hiányzik is.

Indítsa el loopbacken, kifejezett porttal

Válasszon egy nem használt helyi portot, és kösse kifejezetten a loopbackhez, ahelyett hogy kihagyná a címet. A lenti három lehetőség mindegyike egy-egy okból létezik.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N kihagyja a távoli parancsot, -T pedig a pszeudoterminált, így a munkamenet csak továbbításra létezik. ExitOnForwardFailure kilépésre készteti a klienst, ha a figyelő nem hozható létre, ahelyett hogy a kért továbbítás nélkül futna. ControlPath=none távol tartja a munkamenetet egy meglévő multiplexelt kapcsolattól, amely saját továbbításokat adhatna hozzá. A loopback távol tartja a figyelőt a LAN-tól, de megosztott gépen ez nem engedélyezési határ, mert más helyi folyamatok is elérhetik. Az OpenSSH-kliens referenciája dokumentálja ezeket a kapcsolókat, és a loopbackre vonatkozó figyelmeztetés abból következik, mi az, ami egy figyelő socket.

A neveket a proxyn keresztül küldje, ne mellette

A SOCKS5-ügyfél maga is feloldhatja a célt, vagy kérheti a proxyt, hogy tegye meg, és ez a választás dönti el, melyik feloldó válaszol. A socks5h használatával a curl a gépnevet a proxyn keresztül küldi, így a keresés az SSH-kiszolgálón történik. Egyszerű socks5 mellett a laptop oldja fel először, és csak a kapcsolat utazik, ami csendben aláássa a célt, ha a név belső. A lenti kérés a proxy nélküli listát is törli, így egy örökölt NO_PROXY érték nem tudja a proxy mellett elkerülni.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

A tanúsítvány-ellenőrzés és az alkalmazás saját bejelentkezése továbbra is érvényes, mert a proxy egyiket sem helyettesíti. Két feloldás marad: a laptopnak az engedélyezett VPN- és DNS-úton kell elérnie az SSH-gazdagépet, és az SSH-kiszolgálónak magának kell feloldania az alkalmazás nevét. A második önmagában is tesztelhető, mielőtt bármilyen forgalom átmenne a proxyn.

ssh [email protected] getent hosts app.corp.example

Bizonyítson be egy engedélyezett célt, majd zárja le a munkamenetet

Teszteljen egy célt, amelyet a házirend engedélyez, és egyet, amelyet el kellene utasítania, mert egy működő továbbítás csak azt bizonyítja, hogy a figyelő működik, és semmi többet. Az alkalmazás az SSH-kiszolgáló által választott forráscímet látja, és az nem a laptopja alagútcíme. Ahol a túlsó vég forrás szerint naplózza a kapcsolatokat, ott ez a különbség az első, amit meg kell nézni, amikor egy kérést elutasítanak.

Állítsa le a munkamenetet a tulajdonában lévő folyamaton keresztül, ne egy kapcsolódó idegen shell megölésével. Utána erősítse meg, hogy a figyelő eltűnt, mert egy még válaszoló port olyan munkamenet, amelyet valójában nem zárt be. Csak az e gyakorlat által bevezetett proxybeállítást távolítsa el, és hagyja békén az alkalmazás többi konfigurációját. Egy felügyelet nélküli terminál, amely továbbítási szabályt tart, nem szolgáltatás, és az állandó proxynak jóváhagyott életciklus kell, nem elfelejtett ablak.

ss -ltn | grep 1080

Hibák, amelyeket ez az elrendezés nem tud kijavítani

Néhány tünet egyenesen a fenti korlátokra mutat, és korai felismerésük megspórol egy délutánt proxy-hibakereséssel. A táblázat összekapcsolja azt, amit lát, azzal, amit ez általában jelent. A legutolsó oszlopban bármi tervezési kérdés, nem konfigurációs hiba.

Az első három sor az, amelyet az emberek rosszul diagnosztizálnak, mert mindegyik kapcsolódási kísérletet ad a proxyra vonatkozó hiba helyett. Egy név, amely a laptopon oldódik fel, semmit sem mond a kiszolgáló feloldójáról, és a hiba helyette tanúsítvány- vagy időtúllépési problémaként olvasható. A csak UDP-t használó alkalmazások a tervezésen kívül állnak, nem belül töröttek, és semmilyen extra ssh-kapcsoló nem változtat ezen. A böngészősor a szokásos emlékeztető arra, hogy a proxybeállítások alkalmazásonként érvényesek. Az utolsó sor az oka annak, hogy létezik a lezárási ellenőrzés: egy még figyelő port azt jelenti, hogy most valami más birtokolja.