Kaip vietinis SSH peradresavimas perneša TCP OpenVPN sesiją

Čia susluoksniuoja trys transportai, ir kiekvienas turi savo įrėminimą. VPN naudingoji apkrova keliauja TLS sesijos viduje, ta TLS sesija keliauja TCP ryšio į loopback prievadą viduje, o to ryšio baitai keliauja SSH viduje į relay hostą, kuris atidaro tikrąjį TCP ryšį į VPN klausytoją. Niekas šioje išdėstyme nekeičia to, ką OpenVPN autentifikuoja, ir niekas jame nepadaro UDP klausytojo pasiekiamo per TCP. Likusią dalį skaitykite kaip baitų kelio aprašymą, o ne kaip receptą apeiti tinklo kontrolę.

Ką vietinis peradresavimas iš tikrųjų perkelia

SSH klientas klausosi vietinio prievado. Kai vietinis procesas prisijungia, klientas supakuoja baitus į savo šifruotą kanalą, o serverio pusė atidaro naują TCP ryšį į tikslą, nurodytą peradresavimo užklausoje.

Tą tikslą išsprendžia relay, o ne jūsų mašina, todėl vardas, egzistuojantis tik nuotolinio tinklo viduje, vis tiek veikia. Tai taip pat reiškia, kad relay turi pasiekti VPN klausytoją ir turėti atgalinį maršrutą į jį. Vardas, išsprendžiamas jūsų nešiojamajame kompiuteryje, nieko nesako apie tai, ką relay mato.

SSH sesijos paleidimas įrodo tik tai, kad relay yra pasiekiamas ir autentifikuotas. Jis nieko nesako apie tai, ar kitas klausytojas veikia, ar tarpinis ugniasienė tarp relay ir klausytojo priima ryšį, ar VPN priims jūsų profilį.

Nukreipkite klientą į vietinį klausytoją

Paskelbtas pavyzdys: relay pasiekia TCP klausytoją adresu gw.internal.example:443, o aukštas vietinis prievadas atskleidžia tą kelią tik šiai mašinai.

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

OpenSSH vadove vietinis peradresavimas apibūdinamas kaip TCP ryšių priėmimas vietoje ir kito ryšio atidarymas iš nuotolinės pusės. Susiekite klausytoją su loopback, o ne su visomis sąsajomis, nes iš tinklo pasiekiamas peradresavimas yra atviras relay su jūsų vardu. Pakaitos simbolio susiejimas taip pat atskleidžia prievadą bet kuriai kitai vietinei paskyrai bendroje mašinoje.

Tada nustatykite VPN klientą į TCP režimą ir nukreipkite jį į 127.0.0.1:24011. Jei profilis naudoja UDP, ši konstrukcija nepadės: peradresavimas perneša baitų srautą, o datagramų kelio per jį nėra.

Laikykite abu autentifikavimus atskirai

SSH autentifikuoja relay hostą. OpenVPN vis dar autentifikuoja VPN partnerį, o loopback tikslas to reikalavimo nekeičia. Sertifikato patikrų išjungimas todėl, kad lizdas dabar rodo į localhost, yra blogiausias šios konstrukcijos trumpinys. Jis paverčia transporto išdėstymą pasitikėjimo išdėstymu, o antrajam niekas nepratarė.

Išsaugokite profilio pasitikėjimo inkarą, serverio vaidmens patikrą ir vardo tikrinimą nepaliestus. Jei jūsų klientas lygina serverio vardą su adresu, į kurį skambino, loopback gali prireikti aiškaus vardo nustatymo, o ne išjungtos patikros, ir profilio dokumentacija yra vieta, kur patvirtinama, kuris laukas lyginamas.

Traktuokite relay kaip antrąją pasitikėjimo istorijos šalį: jo administratorius mato ryšio metaduomenis ir gali peradresuoti peradresavimą, jei konfigūracija pakeičiama. Išdėstymui reikia ir relay, ir VPN paslaugos savininko pritarimo, ne tik to, kam to reikia šiandien.

Nestatykite kilpos po tuneliu

Kai VPN įdiegia maršrutus, jį nešantis SSH ryšys vis dar turi kelią į relay, kuris neina per tunelį. Jei numatytasis maršrutas pereina prie VPN, o relay pasiekiamas tik per tą patį tunelį, transportas sugriūva ir VPN eina kartu. Gedimas atrodo kaip nutrūkęs tunelis, o ne maršruto klaida, todėl jis diagnozuojamas neteisingai.

Įprasta pataisa yra host maršrutas į relay adresą, prisegtas prie fizinės sąsajos prieš tunelio pakėlimą, ir patikra, kad maršrutas išlieka po pakartotinio prisijungimo. Patikrinkite jį maršruto paieška relay adresui, o ne manydami, kad tvarka buvo teisinga.

Taip pat tikėkitės, kad šis sluoksnis bus lėtesnis ir trapesnis nei tiesioginis ryšys, nes dabar yra du išdėstyti transportai ir dar vienas galinis taškas, kurį reikia prižiūrėti. Tai būdas kirsti tinklo ribą, o ne našumo technika.

Baigę uždarykite klausytoją

Sustabdykite SSH sesiją, kai tunelio nebereikia, ir patvirtinkite, kad vietinis prievadas atlaisvintas. Pamirštas peradresavimas palieka autentifikuotą kelią atvirą mašinoje, kuri gali būti bendra.

Peržiūrėkite ir leidžiamus relay peradresavimo tikslus, nes leistinoji konfigūracija bet kurią pažeistą paskyrą paverčia bendru atspirties tašku. Užrašykite prievadą, relay ir tikslą kartu, kad kitas žmogus žinotų, kam buvo peradresavimas ir ar jis vis dar patvirtintas.