Welk app-verkeer draagt een SSH-doorschakeling eigenlijk?

Een shell, een lokale doorschakeling, SOCKS en de tunnelapparaatmodus bieden verschillende interfaces. Benoem degene die je app kan gebruiken voordat je die vergelijkt met een gerouteerde VPN.

De terminal maakt verbinding, de prompt verschijnt en iedereen is het erover eens dat de SSH-toegang werkt. Dan bereikt een databaseclient op de laptop de private host nog steeds niet, en de sessie krijgt de schuld. Wat gebouwd is, was een shell, en dat is een van de vier heel verschillende interfaces die SSH kan bieden. Benoem eerst de interface en test dan of de toepassing die echt gebruikt. De volgorde is belangrijk, want elke interface faalt op zijn eigen manier.

Benoem de interface voordat je iets vergelijkt

De handleiding van de OpenSSH-client onderscheidt vier mechanismen die makkelijk door elkaar lopen. Een shell of een opdracht op afstand draait op de SSH-host. Een lokale doorschakeling opent een luisterende socket op de client en maakt de vervolgverbinding vanaf de andere kant. Een doorschakeling op afstand doet het omgekeerde en luistert aan de serverkant. Dynamische doorschakeling biedt een SOCKS-eindpunt voor programma’s die weten hoe ze dat moeten gebruiken.

  • Shell: het programma draait op de externe machine, lokaal luistert niets.
  • Lokale doorschakeling: je laptop heeft een poort, de externe host maakt de uitgaande verbinding.
  • Doorschakeling op afstand: de externe kant heeft een poort, het verkeer komt terug naar jou.
  • Dynamisch: een SOCKS-proxy op de client, alleen gebruikt door proxybewuste toepassingen.

Geen van deze installeert een route. Een programma dat proxyinstellingen negeert, of UDP spreekt, of namen zelf oplost, wordt niet beïnvloed door een actieve SSH-sessie. Dat is geen fout in SSH; het is de reikwijdte van de interface die je koos.

Lokale, externe en dynamische doorschakelingen verschillen in wie er luistert

Het verschil dat de meeste gevallen beslist, is wie de luisterende socket bezit. Bij een lokale doorschakeling luistert de client en kiest het verre uiteinde de bestemming, daarom wordt het bestemmingsadres vanuit het standpunt van de server opgelost. Bij een doorschakeling op afstand luistert de server en wordt de verbinding naar jouw kant teruggebracht, en zo stel je een lokale dienst beschikbaar zonder die rechtstreeks te publiceren.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

De eerste opdracht bindt poort 5432 op de laptop en schakelt die door naar de database zoals die vanaf de bastion zichtbaar is. De tweede maakt een SOCKS-proxy op poort 1080. De derde opdracht bevestigt welke processen echt luisteren, en dat is het enige bewijs dat de doorschakeling bestaat in plaats van stil te zijn mislukt door een poortconflict.

Dynamische doorschakeling verdient een eigen waarschuwing: ze dekt alleen toepassingen die SOCKS respecteren. Een browser kan erop gericht worden, een opdrachtregelprogramma kan gezegd worden het te gebruiken, en een databasestuurprogramma met zijn eigen verbindingsstack kan dat meestal niet. Aannemen dat elk programma op de machine nu de tunnel gebruikt, is de meest voorkomende fout in dit hele gebied.

De tunnelapparaatmodus is de enige echte netwerkuitzondering

OpenSSH ondersteunt ook -w tunnelapparaat-doorschakeling, die een punt-tot-punt-interface doorgeeft in plaats van een TCP-listener. Dat is een echte netwerktunnel, en hij wordt bewust geconfigureerd, niet als bijeffect van het openen van een shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Hij heeft de overeenkomstige interfacenummers aan beide kanten nodig, de juiste configuratie op de server en voldoende rechten op de client om het apparaat te maken. Hij heeft ook een adresserings- en routeringsplan nodig, want een kale interface draagt geen beleid over welke bestemmingen hem moeten gebruiken.

Zelfs dan eindigt de tunnel bij de externe host. Welke bescherming het SSH-transport ook bood, die eindigt daar, en de vervolgverbinding is een aparte sprong. Een VPN-gateway heeft dezelfde vorm van grens, en daarom zou de vergelijking over bereik en beëindiging moeten gaan en niet over welk gereedschap sterker is. Die grens hardop benoemen beslecht ook de discussie of een tunnel «alles versleutelt», want dat doet hij duidelijk niet.

Test dat je toepassing de interface gebruikt die je hebt gebouwd

Verificatie is per toepassing, niet per sessie. Een werkende doorschakeling bewijst dat de poort gebonden is en de externe kant kan kiezen; ze bewijst niet dat het programma dat je belangrijk vindt erdoor verbonden is.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

De eerste opdracht stuurt een verzoek via het SOCKS-eindpunt met de hostnaam op afstand opgelost, en de tweede oefent de doorgeschakelde databasepoort met TLS nog steeds vereist. Voer dezelfde tests uit met de doorschakeling gestopt om te bevestigen dat ze falen, want een test die beide kanten slaagt, heeft de tunnel nooit gebruikt.

Vergelijk dan met een gerouteerde VPN alleen op de dimensies die ertoe doen: welke bestemmingen gedekt zijn, welke protocollen werken, waar de bescherming eindigt en wie de toegang moet goedkeuren. Een doorschakeling voor één dienst kan het smallere en betere antwoord zijn, terwijl een VPN de juiste vorm is wanneer veel toepassingen hetzelfde netwerkpad nodig hebben. Geen van beide geeft alles wat vanaf zijn verre eindpunt bereikbaar is.

Gerelateerde artikelen