Hvilken apptrafik bærer en SSH-videresendelse egentlig?

Terminalen opretter forbindelse, prompten vises, og alle er enige om, at SSH-adgangen virker. Derefter kan en databaseklient på computeren stadig ikke nå den private vært, og sessionen får skylden. Det, der blev bygget, var en skal, og den er en af fire ret forskellige grænseflader, som SSH kan tilbyde. Navngiv grænsefladen først, og test derefter, at applikationen faktisk bruger den. Rækkefølgen er vigtig, fordi hver grænseflade fejler på sin egen måde.

Navngiv grænsefladen, før du sammenligner noget

OpenSSH-klientens manual skelner mellem fire mekanismer, som er lette at blande sammen. En skal eller en fjernkommando kører på SSH-værten. En lokal videresendelse åbner en lyttende socket på klienten og laver den videre forbindelse fra den fjerne side. En fjern videresendelse gør det modsatte og lytter på serversiden. Dynamisk videresendelse udstiller et SOCKS-endepunkt til programmer, der ved, hvordan man bruger det.

• Skal: programmet kører på den fjerne maskine, intet lytter lokalt.
• Lokal videresendelse: din computer har en port, den fjerne vært laver den udgående forbindelse.
• Fjern videresendelse: den fjerne side har en port, trafikken kommer tilbage mod dig.
• Dynamisk: en SOCKS-proxy på klienten, kun brugt af proxybevidste applikationer.

Ingen af disse installerer en rute. Et program, der ignorerer proxyindstillinger, eller taler UDP, eller slår navne op selv, påvirkes ikke af en aktiv SSH-session. Det er ikke en fejl i SSH; det er omfanget af den grænseflade, du valgte.

Lokale, fjern og dynamiske videresendelser adskiller sig i, hvem der lytter

Den forskel, der afgør de fleste tilfælde, er, hvem der ejer den lyttende socket. Med en lokal videresendelse lytter klienten, og den fjerne ende ringer til destinationen, og derfor slås destinationsadressen op fra serverens synspunkt. Med en fjern videresendelse lytter serveren, og forbindelsen bæres tilbage til din side, og det er sådan, du udstiller en lokal tjeneste uden at publicere 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 kommando binder port 5432 på computeren og videresender den til databasen, som den ses fra bastionen. Den anden opretter en SOCKS-proxy på port 1080. Den tredje kommando bekræfter, hvilke processer der faktisk lytter, og det er det eneste bevis på, at videresendelsen findes, i stedet for at være fejlet lydløst på en portkonflikt.

Dynamisk videresendelse fortjener sin egen advarsel: den dækker kun applikationer, der respekterer SOCKS. En browser kan peges på den, et kommandolinjeværktøj kan få besked om at bruge den, og en databasedriver med sin egen forbindelsesstak kan normalt ikke. At antage, at hvert program på maskinen nu bruger tunnelen, er den mest almindelige fejl i hele dette område.

Tunnel-enhedstilstand er den eneste rigtige netværksundtagelse

OpenSSH understøtter også -w tunnel-enhedsvideresendelse, som sender en punkt-til-punkt-grænseflade videre i stedet for en TCP-lytter. Det er en ægte netværkstunnel, og den konfigureres bevidst, ikke som en bivirkning af at åbne en skal.

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

Den kræver de tilsvarende grænsefladenumre tilgængelige i begge ender, den rigtige konfiguration på serveren og tilstrækkelige rettigheder på klienten til at oprette enheden. Den kræver også en adresserings- og routingplan, fordi en bar grænseflade ikke bærer nogen politik om, hvilke destinationer der skal bruge den.

Selv da slutter tunnelen ved den fjerne vært. Den beskyttelse, SSH-transporten gav, slutter der, og den videre forbindelse er et separat hop. En VPN-gateway har samme form for grænse, og derfor bør sammenligningen handle om omfang og afslutning frem for om, hvilket værktøj der er stærkest. At navngive den grænse højt afgør også diskussionen om, hvorvidt en tunnel «krypterer alt», for det gør den tydeligt ikke.

Test, at din applikation bruger den grænseflade, du byggede

Verifikation sker for hver applikation, ikke for hver session. En fungerende videresendelse beviser, at porten er bundet, og at den fjerne side kan ringe; det beviser ikke, at det program, du bryder dig om, koblede igennem 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 kommando sender en anmodning gennem SOCKS-endepunktet med værtsnavnet slået op eksternt, og den anden prøver den videresendte databaseport med TLS stadig påkrævet. Kør de samme tests med videresendelsen stoppet for at bekræfte, at de fejler, fordi en test, der består begge veje, aldrig brugte tunnelen.

Sammenlign derefter med en routet VPN kun på de dimensioner, der betyder noget: hvilke destinationer der er dækket, hvilke protokoller der virker, hvor beskyttelsen slutter, og hvem der skal godkende adgangen. En enkeltjenestevideresendelse kan være det smallere og bedre svar, mens en VPN er den rigtige form, når mange applikationer har brug for samme netværksvej. Ingen af dem giver alt, hvad der er tilgængeligt fra dens fjerne endepunkt.