Kā lokāla SSH pāradresācija pārvieto TCP OpenVPN sesiju

Šeit slāņojas trīs transporti, un katram ir sava ievainošana. VPN kravnesība ceļo TLS sesijā, šī TLS sesija ceļo TCP savienojumā uz loopback portu, un šī savienojuma baiti ceļo SSH iekšienē uz relay resursdatoru, kas atver īsto TCP savienojumu ar VPN klausītāju. Nekas šajā izkārtojumā nemaina to, ko OpenVPN autentificē, un nekas tajā nepadara UDP klausītāju sasniedzamu caur TCP. Pārējo lasiet kā baitu ceļa aprakstu, nevis kā recepti tīkla kontroles apiešanai.

Ko lokālā pāradresācija patiešām pārvieto

SSH klients klausās lokālā portā. Kad lokāls process pieslēdzas, klients iepako baitus savā šifrētajā kanālā, un servera puse atver jaunu TCP savienojumu ar galamērķi, kas nosaukts pāradresācijas pieprasījumā.

Šo galamērķi atrisina relay, nevis jūsu mašīna, tāpēc vārds, kas pastāv tikai attālā tīkla iekšienē, joprojām darbojas. Tas nozīmē arī to, ka relay ir jāsasniedz VPN klausītājs un jābūt atpakaļceļam uz to. Vārds, kas tiek atrisināts jūsu klēpjdatorā, neko nepasaka par to, ko relay redz.

SSH sesijas palaišana pierāda tikai to, ka relay ir sasniedzams un autentificēts. Tā nepasaka, vai nākamais klausītājs darbojas, vai ugunsmūris starp relay un klausītāju pieņem savienojumu, vai VPN pieņems jūsu profilu.

Pavērsiet klientu uz lokālo klausītāju

Paziņots piemērs: relay var sasniegt TCP klausītāju gw.internal.example:443, un augsts lokāls ports atklāj šo ceļu tikai šai mašīnai.

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

OpenSSH rokasgrāmata apraksta lokālo pāradresāciju kā TCP savienojumu pieņemšanu lokāli un nākamā savienojuma atvēršanu no attālās puses. Saistiet klausītāju ar loopback, nevis ar visām saskarnēm, jo no tīkla sasniedzama pāradresācija ir atvērts relay ar jūsu vārdu. Aizstājējzīmes saistīšana arī atklāj portu jebkuram citam lokālam kontam koplietotā mašīnā.

Pēc tam iestatiet VPN klientu TCP režīmā un pavērsiet to uz 127.0.0.1:24011. Ja profils izmanto UDP, šis dizains nevar palīdzēt: pāradresācija pārvieto baitu straumi, un caur to nav datagrammu ceļa.

Turiet abas autentifikācijas atsevišķi

SSH autentificē relay resursdatoru. OpenVPN joprojām autentificē VPN partneri, un loopback galamērķis šo prasību nemaina. Sertifikāta pārbaužu izslēgšana tāpēc, ka ligzda tagad norāda uz localhost, ir sliktākais šī dizaina saīsinājums. Tas pārvērš transporta izkārtojumu uzticības izkārtojumā, un otrajam neviens nepiekrita.

Saglabājiet profila uzticības enkuru, servera lomas pārbaudi un vārda verifikāciju neskartus. Ja jūsu klients salīdzina servera vārdu ar adresi, uz kuru zvanīja, loopback var būt nepieciešams skaidrs vārda iestatījums, nevis izslēgta pārbaude, un profila dokumentācija ir vieta, kur apstiprināt, kurš lauks tiek salīdzināts.

Uztveriet relay kā otru pusi uzticības stāstā: tā administrators redz savienojumu metadatus un var novirzīt pāradresāciju, ja konfigurācija tiek mainīta. Izkārtojumam nepieciešama gan relay, gan VPN pakalpojuma īpašnieka piekrišana, ne tikai tā, kam tas nepieciešams šodien.

Neveidojiet cilpu zem tuneļa

Kad VPN instalē maršrutus, to nesošajam SSH savienojumam joprojām vajadzīgs ceļš uz relay, kas neiet caur tuneli. Ja noklusējuma maršruts pāriet uz VPN un relay ir sasniedzams tikai caur to pašu tuneli, transports sabrūk un VPN iet tai līdzi. Kļūme izskatās kā nokritis tunelis, nevis maršrutēšanas kļūda, tāpēc tā tiek diagnosticēta nepareizi.

Parastais labojums ir resursdatora maršruts uz relay adresi, kas pirms tuneļa pacelšanas piesaistīts fiziskajai saskarnei, plus pārbaude, ka maršruts iztur atkārtotu savienojumu. Pārbaudiet to ar maršruta meklēšanu relay adresei, nevis pieņemot, ka secība bija pareiza.

Gaidiet arī, ka šis steks būs lēnāks un trauslāks nekā tiešs savienojums, jo tagad ir divi sakārtoti transporti un vēl viens galapunkts, kas jāuztur. Tas ir veids, kā šķērsot tīkla robežu, nevis veiktspējas paņēmiens.

Kad esat pabeidzis, aizveriet klausītāju

Apturiet SSH sesiju, kad tunelis vairs nav vajadzīgs, un apstipriniet, ka lokālais ports ir atbrīvots. Aizmirsta pāradresācija tur autentificētu ceļu atvērtu mašīnā, kas var būt koplietota.

Pārskatiet arī relay atļautos pāradresācijas galamērķus, jo pieļāvīga konfigurācija pārvērš jebkuru apdraudētu kontu par vispārēju atbalsta punktu. Pierakstiet portu, relay un galamērķi kopā, lai nākamā persona zinātu, kam pāradresācija bija paredzēta un vai tā joprojām ir apstiprināta.