Kva apptrafikk ber eigentleg ei SSH-vidaresending?

Eit skal, ei lokal vidaresending, SOCKS og tunnel-einingsmodus tilbyr ulike grensesnitt. Namngje det appen din kan bruke, før du samanliknar det med ein ruta VPN.

Terminalen koplar til, ledeteksta vert vist, og alle er samde om at SSH-tilgangen verkar. Deretter når ein databaseklient på laptopen framleis ikkje den private verten, og økta får skulda. Det som vart bygd, var eit skal, og det er eitt av fire ganske ulike grensesnitt SSH kan tilby. Namngje grensesnittet først, og test deretter at applikasjonen faktisk brukar det. Rekkjefølgja har noko å seie, fordi kvart grensesnitt feilar på sin eigen måte.

Namngje grensesnittet før du samanliknar noko

handboka til OpenSSH-klienten skil mellom fire mekanismar som er lette å blande saman. Eit skal eller ein fjernkommando køyrer på SSH-verten. Ei lokal vidaresending opnar ein lyttande socket på klienten og lagar den vidare sambindinga frå den fjerne sida. Ei fjern vidaresending gjer det motsette og lyttar på serversida. Dynamisk vidaresending eksponerer eit SOCKS-endepunkt for program som veit korleis dei brukar det.

  • Skal: programmet køyrer på den fjerne maskina, ingenting lyttar lokalt.
  • Lokal vidaresending: laptopen din har ein port, den fjerne verten lagar den utgåande sambindinga.
  • Fjern vidaresending: den fjerne sida har ein port, trafikken kjem tilbake mot deg.
  • Dynamisk: ein SOCKS-proxy på klienten, berre brukt av proxyvitande applikasjonar.

Ingen av desse installerer ei rute. Eit program som ignorerer proxyinnstillingar, eller snakkar UDP, eller slår opp namn sjølv, vert ikkje påverka av ei aktiv SSH-økt. Det er ikkje ein feil i SSH; det er omfanget av grensesnittet du valde.

Lokale, fjerne og dynamiske vidaresendingar skil seg i kven som lyttar

Skilnaden som avgjer dei fleste tilfella, er kven som eig den lyttande socketen. Med ei lokal vidaresending lyttar klienten, og den fjerne enden ringjer destinasjonen, og difor vert destinasjonsadressa slått opp frå synsvinkelen til serveren. Med ei fjern vidaresending lyttar serveren, og sambindinga vert boren tilbake til di side, og slik eksponerer du ein lokal teneste utan å publisere henne 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 bind port 5432 på laptopen og vidaresender han til databasen slik han vert sett frå bastionen. Den andre opprettar ein SOCKS-proxy på port 1080. Den tredje kommandoen stadfester kva prosessar som faktisk lyttar, og det er det einaste beviset på at vidaresendinga finst i staden for å ha feila lydlaust på ein portkonflikt.

Dynamisk vidaresending fortener si eiga åtvaring: ho dekkjer berre applikasjonar som respekterer SOCKS. Ein nettlesar kan peikast på henne, eit kommandolinjeverktøy kan få beskjed om å bruke henne, og ein databasedrivar med sin eigen sambindingsstakk kan vanlegvis ikkje. Å tru at kvart program på maskina no brukar tunnelen, er den vanlegaste feilen i heile dette området.

Tunnel-einingsmodus er det einaste ekte nettverksunntaket

OpenSSH støttar òg -w tunnel-einingsvidaresending, som sender eit punkt-til-punkt-grensesnitt vidare i staden for ein TCP-lyttar. Det er ein ekte nettverkstunnel, og han vert konfigurert med vilje, ikkje som ein biverknad av å opne eit skal.

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

Han treng dei tilsvarande grensesnittnummera tilgjengelege i båe endar, rett konfigurasjon på serveren og nok rettar på klienten til å opprette eininga. Han treng òg ein adresserings- og rutingsplan, fordi eit bart grensesnitt ikkje ber noka retningslinje om kva destinasjonar som skal bruke han.

Sjølv då sluttar tunnelen ved den fjerne verten. Den vernet SSH-transporten gav, sluttar der, og den vidare sambindinga er eit eige hopp. Ein VPN-gateway har same forma for grense, og difor bør samanlikninga handle om omfang og avslutning framfor om kva verktøy som er sterkast. Å namngje den grensa høgt avgjer òg diskusjonen om ein tunnel «krypterer alt», for det gjer han tydelegvis ikkje.

Test at applikasjonen din brukar grensesnittet du bygde

Verifiseringa er per applikasjon, ikkje per økt. Ei fungerande vidaresending beviser at porten er bunden og at den fjerne sida kan ringje; ho beviser ikkje at programmet du bryr deg om, kopla gjennom henne.

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 ein førespurnad gjennom SOCKS-endepunktet med vertsnamnet slått opp eksternt, og den andre prøver den vidaresende databaseporten med TLS framleis påkravd. Køyr dei same testane med vidaresendinga stoppa for å stadfeste at dei feilar, fordi ein test som går gjennom båe vegar, aldri brukte tunnelen.

Samanlikn deretter med ein ruta VPN berre i dimensjonane som betyr noko: kva destinasjonar som er dekte, kva protokollar som verkar, kvar vernet sluttar, og kven som må godkjenne tilgangen. Ei vidaresending for éi teneste kan vere det smalare og betre svaret, medan ein VPN er rett form når mange applikasjonar treng same nettverksveg. Ingen av dei gir alt som er tilgjengeleg frå endepunktet i det fjerne.

Relaterte artiklar