Csak VPN-en át elérhető HTTPS-oldal elérése SSH-továbbítással

Az egyik gépen már van jóváhagyott VPN-hozzáférés, a második gépnek pontosan egy privát HTTPS-szolgáltatásra van szüksége, és egy helyi SSH-továbbítás áthidalhatja ezt a rést anélkül, hogy a második gépnek alagutat adna. A továbbítás egyetlen TCP-célt visz tovább a teljes hálózat helyett, és éppen ez a korlát a lényeg. Haladjon végig az alábbi öt lépésen sorrendben, mert mindegyik más okból hibázik, és egy későbbi lépés nem tud megmenteni egy korábbi rést. Ha bármelyik előfeltétel hiányzik, ez a terv nem oldja meg, és semmilyen parancshangolás nem segít.

Első lépés: erősítse meg a három előfeltételt

Három dolognak már igaznak kell lennie, mielőtt bármelyik parancs számítana. Engedélyre van szüksége ahhoz, hogy az első gépet továbbító gazdagépként használja, működő SSH-hozzáférésre hozzá, és olyan kiszolgálószabályzatra, amely engedélyezi a szándékolt célt. A fájlátvitelre létrehozott SSH-fiókban lehet, hogy ki van kapcsolva a továbbítás, és egy továbbítást engedélyező kiszolgáló továbbra is korlátozhatja, mely célok érhetők el rajta keresztül. Kérdezzen a tesztelés előtt, mert egy kolléga munkaállomásának megállapodás nélküli ugrópontként való használata szabályzati probléma, akkor is, ha a parancs hibátlanul működik.

Két parancs rendezi a lista technikai felét. Az első bizonyítja, hogy a fiók és a kulcs interaktív kérés nélkül működik, a második pedig a tényleges kiszolgálószabályzatot nyomtatja ki a konfigurációs fájlban megjegyzésbe tett példa helyett.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Második lépés: kössön egy loopback-portot, és tartsa életben a munkamenetet

A kliensalkalmazást futtató gépen nyisson helyi továbbítást a privát szolgáltatás felé. Kösse kifejezetten a loopbackhez, hogy ne tegye közzé a helyi hálózaton, és válasszon olyan magas portot, amelyet még nem tart egy helyi szolgáltatás sem. Tartsa futva a munkamenetet, amíg dolgozik, mert bezárása bezárja a figyelőt. ExitOnForwardFailure az elutasított kötést vagy a foglalt portot azonnali kilépéssé teszi továbbítás nélkül talpon maradó munkamenet helyett, és ez az a hibaállapot, amely a legtöbb időt pazarolja.

A privát kapcsolat az ugrógazdagépről jön létre, ezért annak DNS-ének, útvonalainak, VPN-szabályzatának és szolgáltatáshozzáférésének mind működnie kell. Az SSH-munkamenet nem hoz létre olyan elérhetőséget, amivel az ugrógazdagép nem rendelkezik, és nem tud megjavítani egy útvonalat, amelyet a VPN soha nem tolt ki. Erősítse meg a figyelőt ott, ahol valóban van, ahelyett hogy a parancs csendjében bízna.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Harmadik lépés: tartsa meg a HTTPS-nevet, amikor a foglalat helyi

A https://127.0.0.1:9443/ megnyitása megváltoztatja a TLS-kiszolgáló nevét és az alkalmazás jogosultságát. A portal.lab.example számára kiállított tanúsítvány nem fog érvényesülni loopback-címmel szemben, és az így kapott hiba törött tanúsítványnak tűnik, nem továbbítási rövidítésnek. Parancssori teszthez tartsa meg a valódi URL-t, és csak a foglalat célját módosítsa. Ezt teszi a --connect-to, és a curl kézikönyve dokumentálja az alább használt négy mezős formát.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

A név megmarad az URL-ben, a TLS-kézfogásban és a Host fejlécben, miközben a TCP-kapcsolat a helyi figyelőhöz megy. A proxy nélküli beállítás ezen a továbbításon tartja a tesztet, ahelyett hogy egy beállított HTTP-proxy elfogná, és a tanúsítvány-ellenőrzés bekapcsolva tartása az, ami értelmessé teszi az eredményt.

Negyedik lépés: tudja, mit nem tud lefedni egyetlen továbbítás

Egyetlen TCP-továbbítás egyetlen célportot fed le. Egy oldal, amely egy második gazdagépnévre irányít át, a privát hálózaton belüli gazdagépről tölt be erőforrásokat, vagy más portra küld, saját továbbítást igényel, és mindegyikük ugyanazt a szabályzatellenőrzést igényli, mint az első. A böngészős munkafolyamatok saját követelményeket adnak hozzá, mert a böngészőnek meg kell mondani, hogy a valódi nevet a helyi portra küldje proxykonfiguráción vagy helyi leképezésen keresztül. Ezért egy sikeres parancssori teszt nem bizonyítja, hogy a böngésző is sikerrel jár, bár az útvonalat bizonyítja.

Az UDP, az SMB-felderítés és a tartományba való bejelentkezés egyáltalán nem halad át TCP-továbbításon. Ha a valódi igény általános hálózati hozzáférés, ez a terv a rossz eszköz, és egy támogatott távoli hozzáférési átjáró a megfelelő.

Ötödik lépés: tisztítson és jegyezze fel

Állítsa le a munkamenetet, amikor a teszt elkészült, és erősítse meg, hogy a figyelő eltűnt. Ha a választott port már foglalt volt, válasszon egy másik használaton kívüli loopback-portot, és együtt frissítse az URL-t, a tesztparancsot és a jegyzetet, ahelyett hogy egy nem kapcsolódó helyi szolgáltatást állítana le a szám felszabadításáért. Egy laptopon nyitva hagyott továbbítás diagnosztikából felügyelet nélküli szolgáltatást csinál.

Jegyezze fel az ugrógazdagépet, a továbbított célt, a helyi portot és azt, hogy ki hagyta jóvá a megállapodást. Egy továbbítás, amely csak valakinek a shell-előzményeiben létezik, egy újraindításra van az ismételt vizsgálattól, és a következő ember nem fogja tudni, hogy a három előfeltétel közül melyiket ellenőrizték már.