Hoe 'n plaaslike SSH-deurvoer 'n TCP-OpenVPN-sessie dra

Drie vervoerlaers stapel hier op mekaar, en elkeen het sy eie raamwerk. Die VPN-vrag reis binne 'n TLS-sessie, daardie TLS-sessie reis binne 'n TCP-verbinding na 'n loopback-poort, en die grepe van daardie verbinding reis binne SSH na 'n aflos-gasheer, wat die werklike TCP-verbinding na die VPN-luisteraar oopmaak. Niks aan die reëling verander wat OpenVPN authentiseer nie, en niks daaraan maak 'n UDP-luisteraar oor TCP bereikbaar nie. Lees die res hiervan as 'n beskrywing van die grepe-pad, nie as 'n resep om 'n netwerkkontrole te omseil nie.

Wat die plaaslike deurvoer werklik vervoer

Die SSH-kliënt luister op 'n plaaslike poort. Wanneer 'n plaaslike proses konnekteer, verpak die kliënt die grepe in sy geënkripteerde kanaal, en die bedienerkant maak 'n nuwe TCP-verbinding na die bestemming wat in die deurvoer-versoek genoem word oop.

Daardie bestemming word deur die aflos opgelos, nie deur jou masjien nie, en daarom werk 'n naam wat net binne die afgeleë netwerk bestaan steeds. Dit beteken ook die aflos moet die VPN-luisteraar kan bereik en daarheen kan terugroeteer. 'n Naam wat op jou skootrekenaar oplos, sê niks oor wat die aflos kan sien nie.

Om die SSH-sessie te begin bewys net dat die aflos bereikbaar en geauthentiseer is. Dit sê niks oor of die verdere luisteraar aan is, of 'n vuurmuur tussen die aflos en die luisteraar die verbinding aanvaar, of of die VPN jou profiel sal aanvaar nie.

Rig die kliënt op die plaaslike luisteraar

'n Verklaarde voorbeeld: die aflos kan 'n TCP-luisteraar by gw.internal.example:443 bereik, en 'n hoë plaaslike poort stel daardie pad net aan hierdie masjien bloot.

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

Die OpenSSH-handleiding beskryf die plaaslike deurvoer as die aanvaarding van TCP-verbindings plaaslik en die opening van die verdere verbinding vanaf die afgeleë kant. Bind die luisteraar aan loopback eerder as aan elke koppelvlak, want 'n deurvoer wat van die netwerk af bereikbaar is, is 'n oop aflos met jou naam daarop. 'n Wildcard-binding stel die poort ook aan enige ander plaaslike rekening op 'n gedeelde masjien bloot.

Stel dan die VPN-kliënt op sy TCP-modus en rig dit op 127.0.0.1:24011. As die profiel UDP gebruik, kan hierdie ontwerp nie help nie: die deurvoer dra 'n greepstroom, en daar is geen datagram-pad daardeur nie.

Hou die twee authentiserings apart

SSH authentiseer die aflos-gasheer. OpenVPN authentiseer steeds die VPN-eweknie, en die loopback-bestemming verander nie daardie vereiste nie. Om sertifikaatkontroles af te skakel omdat die sok nou na localhost wys, is die enkele slegste kortpad in hierdie ontwerp. Dit verander 'n vervoerreëling in 'n vertrouensreëling, en niemand het die tweede een goedgekeur nie.

Hou die profiel se vertrouensanker, bedienerrol-kontrole en naamverifikasie ongeskonde. As jou kliënt die bedienernaam vergelyk met die adres wat dit gebel het, mag loopback 'n eksplisiete naaminstelling nodig hê eerder as 'n afgeskakelde kontrole, en die profieldokumentasie is die plek om te bevestig watter veld vergelyk word.

Behandel die aflos as 'n tweede party in die vertrouensverhaal: sy administrateur kan verbindingsmetadata sien en kan die deurvoer herlei as die konfigurasie verander word. Die reëling het goedkeuring van beide die aflos en die eienaar van die VPN-diens nodig, nie net van wie dit vandag nodig het nie.

Moenie 'n lus onder die tonnel bou nie

Sodra die VPN roetes installeer, het die SSH-verbinding wat dit dra steeds 'n pad na die aflos nodig wat nie deur die tonnel loop nie. As die verstekroete na die VPN skuif en die aflos net deur dieselfde tonnel bereikbaar is, stort die vervoer ineen en die VPN gaan saam daarmee. Die fout lyk soos 'n onderbroke tonnel eerder as 'n roetefout, en daarom word dit verkeerd gediagnoseer.

Die gewone oplossing is 'n gasheerroete na die aflosadres wat aan die fisiese koppelvlak vasgepen word voordat die tonnel opkom, plus 'n kontrole dat die roete 'n herverbinding oorleef. Verifieer dit met 'n roete-soektog vir die aflosadres eerder as om aan te neem die volgorde was reg.

Verwag ook dat hierdie stapel stadiger en broser as 'n direkte verbinding sal wees, want daar is nou twee geordende vervoerlaers en nog 'n eindpunt om te onderhou. Dit is 'n manier om 'n netwerkgrens oor te steek, nie 'n prestasietegniek nie.

Sluit die luisteraar wanneer jy klaar is

Stop die SSH-sessie wanneer die tonnel nie meer nodig is nie, en bevestig dat die plaaslike poort vrygestel is. 'n Vergete deurvoer hou 'n geauthentiseerde pad oop op 'n masjien wat dalk gedeel word.

Hersien ook die aflos se toegelate deurvoerbestemmings, want 'n toegeeflike konfigurasie verander enige gekompromitteerde rekening in 'n algemene spilpunt. Teken die poort, die aflos en die bestemming saam aan, sodat die volgende persoon kan sien waarvoor die deurvoer was en of dit nog goedgekeur is.