Kiel loka SSH-plusendado transportas TCP-OpenVPN-sesion

Ĉi tie stakiĝas tri transportoj, kaj ĉiu havas sian propran kadrigon. La VPN-ŝarĝo vojaĝas ene de TLS-sesio, tiu TLS-sesio vojaĝas ene de TCP-konekto al loopback-pordo, kaj la bajtoj de tiu konekto vojaĝas ene de SSH al relaja gastiganto, kiu malfermas la realan TCP-konekton al la VPN-aŭskultanto. Nenio en la aranĝo ŝanĝas tion, kion OpenVPN aŭtentigas, kaj nenio en ĝi igas UDP-aŭskultanton atingebla per TCP. Legu la restaĵon kiel priskribon de la bajta vojo, ne kiel recepton por ĉirkaŭiri retan kontrolon.

Kion la loka plusendado efektive movas

La SSH-kliento aŭskultas sur loka pordo. Kiam loka procezo konektiĝas, la kliento pakaĵigas la bajtojn en sian ĉifritan kanalon, kaj la servila flanko malfermas novan TCP-konekton al la celloko nomita en la plusenda peto.

Tiun cellokon solvas la relajo, ne via maŝino, tial nomo, kiu ekzistas nur ene de la malproksima reto, ankoraŭ funkcias. Tio ankaŭ signifas, ke la relajo devas povi atingi la VPN-aŭskultanton kaj havi revenan itineron al ĝi. Nomo, kiu solviĝas sur via tekkomputilo, diras nenion pri tio, kion la relajo povas vidi.

Startigi la SSH-sesion pruvas nur, ke la relajo estas atingebla kaj aŭtentigita. Ĝi diras nenion pri tio, ĉu la sekva aŭskultanto funkcias, ĉu fajrŝirmilo inter la relajo kaj la aŭskultanto akceptas la konekton, aŭ ĉu la VPN akceptos vian profilon.

Direktu la klienton al la loka aŭskultanto

Deklarita ekzemplo: la relajo povas atingi TCP-aŭskultanton ĉe gw.internal.example:443, kaj alta loka pordo elmetas tiun vojon nur al ĉi tiu maŝino.

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

La manlibro de OpenSSH priskribas la lokan plusendadon kiel lokan akcepton de TCP-konektoj kaj malfermon de la sekva konekto el la malproksima flanko. Ligu la aŭskultanton al loopback anstataŭ al ĉiu interfaco, ĉar plusendado atingebla el la reto estas malfermita relajo kun via nomo sur ĝi. Ĵokera ligo ankaŭ elmetas la pordon al ĉiu ajn alia loka konto sur kunhavata maŝino.

Poste metu la VPN-klienton en sian TCP-reĝimon kaj direktu ĝin al 127.0.0.1:24011. Se la profilo uzas UDP, ĉi tiu dezajno ne povas helpi: la plusendado portas bajtan fluon, kaj ne ekzistas datagrama vojo tra ĝi.

Tenu la du aŭtentigojn apartaj

SSH aŭtentigas la relajan gastiganton. OpenVPN ankoraŭ aŭtentigas la VPN-paron, kaj la loopback-celloko ne ŝanĝas tiun postulon. Malŝalti atestilajn kontrolojn ĉar la ingo nun montras al localhost estas la plej malbona fuŝsolvo en ĉi tiu dezajno. Ĝi transformas transportan aranĝon en aranĝon de fido, kaj neniu aprobis la duan.

Konservu la fidan ankron de la profilo, la servilan rolan kontrolon kaj la nomverifikon sendifektaj. Se via kliento komparas la servilan nomon kun la adreso, kiun ĝi alvokis, loopback eble bezonas eksplicitan nomagordon anstataŭ malŝaltita kontrolo, kaj la profila dokumentaro estas la loko por konfirmi, kiun kampon oni komparas.

Traktu la relajon kiel duan partion en la fida rakonto: ĝia administranto povas vidi konektajn metadatenojn kaj povas alidirekti la plusendadon, se la agordo ŝanĝiĝas. La aranĝo bezonas aprobon de kaj la relajo kaj la posedanto de la VPN-servo, ne nur de tiu, kiu bezonas ĝin hodiaŭ.

Ne konstruu buklon sub la tunelo

Post kiam la VPN instalas itinerojn, la SSH-konekto portanta ĝin ankoraŭ bezonas vojon al la relajo, kiu ne iras tra la tunelo. Se la defaŭlta itinero moviĝas al la VPN kaj la relajo estas atingebla nur tra tiu sama tunelo, la transporto kolapsas kaj la VPN iras kun ĝi. La fiasko aspektas kiel falinta tunelo, ne kiel itinera eraro, tial ĝi estas misdiagnozita.

La kutima ripeto estas gastiganta itinero al la relaja adreso fiksita al la fizika interfaco antaŭ ol la tunelo ekfunkcias, plus kontrolo, ke la itinero postvivas rekonekton. Kontrolu ĝin per itinera serĉo por la relaja adreso anstataŭ supozi, ke la ordo estis ĝusta.

Atendu ankaŭ, ke ĉi tiu stako estos pli malrapida kaj pli rompiĝema ol rekta konekto, ĉar nun estas du ordigitaj transportoj kaj plia finpunkto por prizorgi. Ĝi estas rimedo por transiri retan limon, ne rendimenta tekniko.

Fermu la aŭskultanton, kiam vi finis

Haltigu la SSH-sesion, kiam la tunelo ne plu necesas, kaj konfirmu, ke la loka pordo estas liberigita. Forgesita plusendado tenas aŭtentigitan vojon malfermita sur maŝino, kiu eble estas kunhavata.

Revizuu ankaŭ la permesitajn plusendajn cellokojn de la relajo, ĉar permesema agordo igas ĉiun kompromititan konton ĝenerala pivoto. Notu la pordon, la relajon kaj la cellokon kune, por ke la sekva persono povu scii, por kio estis la plusendado kaj ĉu ĝi ankoraŭ estas aprobita.