Hoe een lokale SSH-doorschakeling een TCP-OpenVPN-sessie draagt

Hier stapelen drie transporten zich, en elk heeft zijn eigen inkapseling. De VPN-payload reist in een TLS-sessie, die TLS-sessie reist in een TCP-verbinding naar een loopback-poort, en de bytes van die verbinding reizen in SSH naar een relay-host, die de echte TCP-verbinding naar de VPN-listener opent. Niets aan de opstelling verandert wat OpenVPN authenticeert, en niets eraan maakt een UDP-listener bereikbaar via TCP. Lees de rest als een beschrijving van het bytepad, niet als een recept om een netwerkcontrole te omzeilen.

Wat de lokale doorgifte werkelijk verplaatst

De SSH-client luistert op een lokale poort. Wanneer een lokaal proces verbindt, verpakt de client de bytes in zijn versleutelde kanaal, en de serverzijde opent een nieuwe TCP-verbinding naar de bestemming die in het doorgeefverzoek staat.

Die bestemming wordt door de relay opgelost, niet door uw machine, en daarom werkt een naam die alleen binnen het externe netwerk bestaat nog steeds. Dat betekent ook dat de relay de VPN-listener moet kunnen bereiken en een retourroute ernaartoe moet hebben. Een naam die op uw laptop wordt opgelost zegt niets over wat de relay kan zien.

Het starten van de SSH-sessie bewijst alleen dat de relay bereikbaar en geauthenticeerd is. Het zegt niets over of de volgende listener draait, of een firewall tussen relay en listener de verbinding accepteert, of over of de VPN uw profiel accepteert.

Richt de client op de lokale listener

Een aangegeven voorbeeld: de relay bereikt een TCP-listener op gw.internal.example:443, en een hoge lokale poort stelt dat pad alleen voor deze machine open.

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

De OpenSSH-handleiding beschrijft de lokale doorgifte als het lokaal accepteren van TCP-verbindingen en het openen van de volgende verbinding vanaf de externe kant. Bind de listener aan loopback in plaats van aan alle interfaces, want een doorgifte die vanaf het netwerk bereikbaar is, is een open relay met uw naam erop. Een wildcard-binding stelt de poort ook open voor elk ander lokaal account op een gedeelde machine.

Zet daarna de VPN-client in zijn TCP-modus en richt hem op 127.0.0.1:24011. Als het profiel UDP gebruikt, kan dit ontwerp niet helpen: de doorgifte draagt een bytestroom, en er is geen datagrampad doorheen.

Houd de twee authenticaties gescheiden

SSH authenticeert de relay-host. OpenVPN authenticeert nog steeds de VPN-peer, en de loopback-bestemming verandert die eis niet. De certificaatcontroles uitschakelen omdat de socket nu naar localhost wijst, is de slechtste sluiproute in dit ontwerp. Het verandert een transportopstelling in een vertrouwensopstelling, en met de tweede heeft niemand ingestemd.

Houd het vertrouwensanker van het profiel, de serverrolcontrole en de naamverificatie intact. Als uw client de servernaam vergelijkt met het adres dat hij belde, heeft loopback misschien een expliciete naaminstelling nodig in plaats van een uitgeschakelde controle, en de profieldocumentatie is de plek om te bevestigen welk veld wordt vergeleken.

Behandel de relay als een tweede partij in het vertrouwensverhaal: de beheerder kan verbindingsmetadata zien en kan de doorgifte omleiden als de configuratie wordt gewijzigd. De opstelling vereist goedkeuring van zowel de relay als de eigenaar van de VPN-dienst, niet alleen van wie het vandaag nodig heeft.

Bouw geen lus onder de tunnel

Zodra de VPN routes installeert, heeft de SSH-verbinding die hem draagt nog steeds een pad naar de relay nodig dat niet door de tunnel loopt. Als de standaardroute naar de VPN verschuift en de relay alleen via diezelfde tunnel bereikbaar is, stort het transport in en de VPN gaat mee. De storing lijkt op een gevallen tunnel in plaats van een routeringsfout, en daarom wordt hij verkeerd gediagnosticeerd.

De gebruikelijke oplossing is een hostroute naar het relay-adres, vastgezet aan de fysieke interface voordat de tunnel omhoog komt, plus een controle dat de route een herverbinding overleeft. Controleer het met een routeopzoeking voor het relay-adres in plaats van aan te nemen dat de volgorde juist was.

Verwacht ook dat deze stapel langzamer en fragieler is dan een directe verbinding, omdat er nu twee geordende transporten en nog een eindpunt te onderhouden zijn. Het is een manier om een netwerkgrens over te steken, geen prestatietechniek.

Sluit de listener als u klaar bent

Stop de SSH-sessie wanneer de tunnel niet meer nodig is, en bevestig dat de lokale poort is vrijgegeven. Een vergeten doorgifte houdt een geauthenticeerd pad open op een machine die gedeeld kan zijn.

Bekijk ook de toegestane doorgeefbestemmingen van de relay, want een toegeeflijke configuratie maakt elk gecompromitteerd account tot een algemeen draaipunt. Noteer de poort, de relay en de bestemming samen, zodat de volgende persoon weet waarvoor de doorgifte was en of die nog is goedgekeurd.