Hogyan visz át egy helyi SSH-továbbítás egy TCP OpenVPN-munkamenetet

Itt három átvitel rétegződik egymásra, és mindegyiknek megvan a saját keretezése. A VPN hasznos terhelése egy TLS-munkamenetben utazik, az a TLS-munkamenet egy TCP-kapcsolatban utazik egy loopback-port felé, és annak a kapcsolatnak a bájtjai SSH-n belül utaznak egy relay-gazdagéphez, amely megnyitja a valódi TCP-kapcsolatot a VPN-figyelő felé. Semmi sem változtatja meg az elrendezésben azt, amit OpenVPN hitelesít, és semmi benne nem teszi elérhetővé egy UDP-figyelőt TCP-n keresztül. A többit a bájtút leírásaként olvassa, nem hálózati ellenőrzés megkerülésére szolgáló receptként.

Mit mozgat valójában a helyi továbbítás

Az SSH-ügyfél egy helyi porton figyel. Amikor egy helyi folyamat csatlakozik, az ügyfél a bájtokat a titkosított csatornájába csomagolja, a kiszolgáló oldal pedig új TCP-kapcsolatot nyit a továbbítási kérésben megnevezett cél felé.

Ezt a célt a relay oldja fel, nem a gépe, ezért működik továbbra is egy név, amely csak a távoli hálózaton belül létezik. Ez azt is jelenti, hogy a relaynek el kell érnie a VPN-figyelőt, és visszaúttal kell rendelkeznie hozzá. Egy név, amely a laptopján oldódik fel, semmit sem mond arról, mit lát a relay.

Az SSH-munkamenet indítása csak azt bizonyítja, hogy a relay elérhető és hitelesített. Nem mondja meg, hogy a következő figyelő fut-e, hogy a relay és a figyelő közötti tűzfal elfogadja-e a kapcsolatot, vagy hogy a VPN elfogadja-e a profilját.

Irányítsa az ügyfelet a helyi figyelőre

Egy megadott példa: a relay elér egy TCP-figyelőt a(z) gw.internal.example:443 címen, és egy magas helyi port csak ennek a gépnek tárja fel ezt az utat.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Az OpenSSH kézikönyve a helyi továbbítást a TCP-kapcsolatok helyi elfogadásaként és a következő kapcsolat távoli oldalról való megnyitásaként írja le. A figyelőt a loopbackhez kösse, ne minden interfészhez, mert a hálózatról elérhető továbbítás nyitott relay a nevével. A helyettesítő karakteres kötés a portot a megosztott gépen minden más helyi fióknak is kiteszi.

Ezután állítsa a VPN-ügyfelet TCP-módba, és irányítsa a(z) 127.0.0.1:24011 címre. Ha a profil UDP-t használ, ez a kialakítás nem segíthet: a továbbítás bájtfolyamot visz, és nincs rajta datagramút.

Tartsa külön a két hitelesítést

Az SSH hitelesíti a relay-gazdagépet. Az OpenVPN továbbra is hitelesíti a VPN-partnert, és a loopback cél nem változtat ezen a követelményen. A tanúsítvány-ellenőrzések kikapcsolása, mert a socket most a localhostra mutat, a legrosszabb rövidítés ebben a kialakításban. Átalakítja az átviteli elrendezést bizalmi elrendezéssé, és a másodikhoz senki nem adta a beleegyezését.

Tartsa érintetlenül a profil bizalmi horgonyát, a kiszolgálószerep-ellenőrzést és a névellenőrzést. Ha az ügyfél a kiszolgáló nevét a tárcsázott címhez hasonlítja, a loopbacknek kifejezett névbeállításra lehet szüksége a kikapcsolt ellenőrzés helyett, és a profil dokumentációja az a hely, ahol megerősítheti, melyik mezőt hasonlítja össze.

Tekintse a relayt a bizalmi történet második feleként: rendszergazdája látja a kapcsolati metaadatokat, és átirányíthatja a továbbítást, ha a konfiguráció megváltozik. Az elrendezéshez a relay és a VPN-szolgáltatás tulajdonosának jóváhagyása is kell, nem csak azé, akinek ma szüksége van rá.

Ne építsen hurkot az alagút alá

Miután a VPN telepíti az útvonalakat, az azt hordozó SSH-kapcsolatnak továbbra is szüksége van a relayhez vezető útra, amely nem az alagúton halad. Ha az alapértelmezett útvonal a VPN-hez kerül, és a relay csak ugyanazon az alagúton érhető el, az átvitel összeomlik, és a VPN vele megy. A hiba inkább leesett alagútnak tűnik, mint útvonalhibának, ezért diagnosztizálják rosszul.

A szokásos javítás egy, a relay címéhez vezető gazdagép-útvonal, amelyet az alagút felemelkedése előtt a fizikai interfészhez rögzítenek, plusz annak ellenőrzése, hogy az útvonal túléli-e az újracsatlakozást. Ellenőrizze egy útvonalkereséssel a relay címére, ahelyett hogy feltételezné, a sorrend helyes volt.

Számítson arra is, hogy ez a halmaz lassabb és törékenyebb lesz egy közvetlen kapcsolatnál, mert most két rendezett átvitel és még egy végpont van karbantartásra. Ez mód egy hálózati határ átlépésére, nem teljesítménytechnika.

Zárja be a figyelőt, ha végzett

Állítsa le az SSH-munkamenetet, amikor az alagútra már nincs szükség, és erősítse meg, hogy a helyi port felszabadult. Egy elfelejtett továbbítás hitelesített utat hagy nyitva egy esetleg megosztott gépen.

Tekintse át a relay engedélyezett továbbítási céljait is, mert egy megengedő konfiguráció minden kompromittált fiókot általános forgóponttá tesz. Jegyezze fel a portot, a relayt és a célt együtt, hogy a következő ember tudja, mi volt a továbbítás célja, és hogy még jóvá van-e hagyva.