Hvilken apptrafikk bærer egentlig en SSH-videresending?

Terminalen kobler til, ledeteksten vises, og alle er enige om at SSH-tilgangen virker. Deretter når en databaseklient på laptopen fortsatt ikke den private verten, og økten får skylden. Det som ble bygget, var et skall, og det er ett av fire ganske forskjellige grensesnitt SSH kan tilby. Navngi grensesnittet først, og test deretter at applikasjonen faktisk bruker det. Rekkefølgen betyr noe, fordi hvert grensesnitt feiler på sin egen måte.

Navngi grensesnittet før du sammenligner noe

OpenSSH-klientens håndbok skiller mellom fire mekanismer som er lette å blande sammen. Et skall eller en fjernkommando kjører på SSH-verten. En lokal videresending åpner en lyttende socket på klienten og lager den videre forbindelsen fra den fjerne siden. En fjern videresending gjør det motsatte og lytter på serversiden. Dynamisk videresending eksponerer et SOCKS-endepunkt for programmer som vet hvordan de bruker det.

• Skall: programmet kjører på den fjerne maskinen, ingenting lytter lokalt.
• Lokal videresending: laptopen din har en port, den fjerne verten lager den utgående forbindelsen.
• Fjern videresending: den fjerne siden har en port, trafikken kommer tilbake mot deg.
• Dynamisk: en SOCKS-proxy på klienten, bare brukt av proxybevisste applikasjoner.

Ingen av disse installerer en rute. Et program som ignorerer proxyinnstillinger, eller snakker UDP, eller slår opp navn selv, påvirkes ikke av en aktiv SSH-økt. Det er ikke en feil i SSH; det er omfanget av grensesnittet du valgte.

Lokale, fjerne og dynamiske videresendinger skiller seg i hvem som lytter

Forskjellen som avgjør de fleste tilfeller, er hvem som eier den lyttende socketen. Med en lokal videresending lytter klienten, og den fjerne enden ringer destinasjonen, og derfor slås destinasjonsadressen opp fra serverens synspunkt. Med en fjern videresending lytter serveren, og forbindelsen bæres tilbake til din side, og slik eksponerer du en lokal tjeneste uten å publisere den direkte.

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

Den første kommandoen binder port 5432 på laptopen og videresender den til databasen slik den ses fra bastionen. Den andre oppretter en SOCKS-proxy på port 1080. Den tredje kommandoen bekrefter hvilke prosesser som faktisk lytter, og det er det eneste beviset på at videresendingen finnes i stedet for å ha feilet lydløst på en portkonflikt.

Dynamisk videresending fortjener sin egen advarsel: den dekker bare applikasjoner som respekterer SOCKS. En nettleser kan pekes på den, et kommandolinjeverktøy kan få beskjed om å bruke den, og en databasedriver med sin egen tilkoblingsstakk kan vanligvis ikke. Å anta at hvert program på maskinen nå bruker tunnelen, er den vanligste feilen i hele dette området.

Tunnel-enhetsmodus er den eneste ekte nettverksunntaket

OpenSSH støtter også -w tunnel-enhetsvideresending, som sender et punkt-til-punkt-grensesnitt videre i stedet for en TCP-lytter. Det er en ekte nettverkstunnel, og den konfigureres bevisst, ikke som en bivirkning av å åpne et skall.

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

Den trenger de tilsvarende grensesnittnumrene tilgjengelig i begge ender, riktig konfigurasjon på serveren og nok rettigheter på klienten til å opprette enheten. Den trenger også en adresserings- og rutingplan, fordi et bart grensesnitt ikke bærer noen policy om hvilke destinasjoner som skal bruke det.

Selv da slutter tunnelen ved den fjerne verten. Den beskyttelsen SSH-transporten ga, slutter der, og den videre forbindelsen er et eget hopp. En VPN-gateway har samme form for grense, og derfor bør sammenligningen handle om omfang og avslutning fremfor om hvilket verktøy som er sterkest. Å navngi den grensen høyt avgjør også diskusjonen om en tunnel «krypterer alt», for det gjør den tydeligvis ikke.

Test at applikasjonen din bruker grensesnittet du bygde

Verifiseringen er per applikasjon, ikke per økt. En fungerende videresending beviser at porten er bundet og at den fjerne siden kan ringe; den beviser ikke at programmet du bryr deg om, koblet gjennom den.

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'

Den første kommandoen sender en forespørsel gjennom SOCKS-endepunktet med vertsnavnet slått opp eksternt, og den andre prøver den videresendte databaseporten med TLS fortsatt påkrevd. Kjør de samme testene med videresendingen stoppet for å bekrefte at de feiler, fordi en test som består begge veier, aldri brukte tunnelen.

Sammenlign deretter med en rutet VPN bare i dimensjonene som betyr noe: hvilke destinasjoner som dekkes, hvilke protokoller som virker, hvor beskyttelsen slutter, og hvem som må godkjenne tilgangen. En videresending for én tjeneste kan være det smalere og bedre svaret, mens en VPN er riktig form når mange applikasjoner trenger samme nettverksvei. Ingen av dem gir alt som er tilgjengelig fra endepunktet i det fjerne.