Ktorú prevádzku aplikácií vlastne prenáša SSH presmerovanie?

Terminál sa pripojí, objaví sa výzva a všetci súhlasia, že prístup SSH funguje. Potom sa klient databázy na notebooku stále nedostane k súkromnému hostiteľovi a vina padá na reláciu. To, čo bolo postavené, bol shell, a to je jedno zo štyroch značne odlišných rozhraní, ktoré SSH môže ponúknuť. Najprv pomenujte rozhranie a potom overte, že aplikácia ho skutočne používa. Poradie je dôležité, pretože každé rozhranie zlyháva po svojom.

Pomenujte rozhranie skôr, než čokoľvek porovnáte

manuál klienta OpenSSH rozlišuje štyri mechanizmy, ktoré sa ľahko zamieňajú. Shell alebo vzdialený príkaz sa vykonáva na hostiteľovi SSH. Lokálne presmerovanie otvorí počúvajúci socket na klientovi a nadväzujúce spojenie vytvorí zo vzdialenej strany. Vzdialené presmerovanie robí opak a počúva na strane servera. Dynamické presmerovanie vystavuje koncový bod SOCKS programom, ktoré ho vedia použiť.

• Shell: program beží na vzdialenom stroji, lokálne nič nepočúva.
• Lokálne presmerovanie: váš notebook má port, vzdialený hostiteľ vytvára odchádzajúce spojenie.
• Vzdialené presmerovanie: vzdialená strana má port, prevádzka sa vracia k vám.
• Dynamické: proxy SOCKS na klientovi, používajú ho len aplikácie, ktoré mu rozumejú.

Nič z toho neinštaluje trasu. Program, ktorý ignoruje nastavenia proxy, alebo hovorí UDP, alebo si sám prekladá mená, nie je ovplyvnený aktívnou reláciou SSH. To nie je chyba v SSH; to je rozsah rozhrania, ktoré ste si vybrali.

Lokálne, vzdialené a dynamické presmerovanie sa líši tým, kto počúva

Rozdiel, ktorý rozhoduje väčšinu prípadov, je, kto vlastní počúvajúci socket. Pri lokálnom presmerovaní počúva klient a vzdialený koniec vytáča cieľ, preto sa adresa cieľa prekladá z pohľadu servera. Pri vzdialenom presmerovaní počúva server a spojenie sa prenáša späť na vašu stranu, a tak vystavíte lokálnu službu bez toho, aby ste ju priamo publikovali.

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

Prvý príkaz naviaže port 5432 na notebooku a presmeruje ho do databázy tak, ako ju vidí bastion. Druhý vytvorí proxy SOCKS na porte 1080. Tretí príkaz potvrdí, ktoré procesy skutočne počúvajú, a to je jediný dôkaz, že presmerovanie existuje, a nie že ticho zlyhalo pre kolíziu portov.

Dynamické presmerovanie si zaslúži vlastné varovanie: pokrýva len aplikácie, ktoré rešpektujú SOCKS. Prehliadač sa naň dá nasmerovať, nástroju príkazového riadka sa dá povedať, aby ho použil, no ovládač databázy s vlastným spojovým zásobníkom to zvyčajne nedokáže. Predpoklad, že každý program na stroji teraz používa tunel, je najčastejšia chyba v celej tejto oblasti.

Režim tunelového zariadenia je jediná skutočná sieťová výnimka

OpenSSH podporuje aj presmerovanie tunelového zariadenia -w, ktoré prenáša rozhranie bod-bod namiesto TCP poslucháča. To je skutočný sieťový tunel a konfiguruje sa zámerne, nie je to vedľajší efekt otvorenia shellu.

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

Potrebuje príslušné čísla rozhraní dostupné na oboch koncoch, správnu konfiguráciu na serveri a dostatok oprávnení na klientovi na vytvorenie zariadenia. Potrebuje aj plán adresovania a smerovania, pretože holé rozhranie nenesie žiadnu politiku o tom, ktoré ciele ho majú používať.

Aj tak sa tunel končí na vzdialenom hostiteľovi. Akúkoľvek ochranu poskytol SSH transport, končí sa tam a nadväzujúce spojenie je samostatný skok. Brána VPN má rovnaký tvar hranice, a preto by porovnanie malo byť o rozsahu a ukončení, nie o tom, ktorý nástroj je silnejší. Vyslovenie tejto hranice tiež ukončuje spor o tom, či tunel „šifruje všetko“, pretože zjavne nešifruje.

Overte, že vaša aplikácia používa rozhranie, ktoré ste postavili

Overovanie je pre každú aplikáciu, nie pre reláciu. Fungujúce presmerovanie dokazuje, že port je naviazaný a vzdialená strana môže vytočiť; nedokazuje, že program, na ktorom vám záleží, sa pripojil cez neho.

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'

Prvý príkaz odošle požiadavku cez koncový bod SOCKS s názvom hostiteľa preloženým vzdialene a druhý precvičí presmerovaný port databázy s TLS stále vyžadovaným. Spustite rovnaké testy so zastaveným presmerovaním, aby ste potvrdili, že zlyhajú, pretože test, ktorý prejde oboma spôsobmi, tunel nikdy nepoužíval.

Potom porovnajte so smerovanou VPN len v dimenziách, na ktorých záleží: ktoré ciele sú pokryté, ktoré protokoly fungujú, kde sa ochrana končí a kto musí schváliť prístup. Presmerovanie jednej služby môže byť užšou a lepšou odpoveďou, zatiaľ čo VPN je správny tvar, keď veľa aplikácií potrebuje rovnakú sieťovú cestu. Ani jedno neposkytuje všetko, čo je dostupné z jeho vzdialeného koncového bodu.