Který provoz aplikací vlastně přenáší SSH přesměrování?

Shell, místní přesměrování, SOCKS a režim tunelového zařízení nabízejí různá rozhraní. Pojmenujte to, které vaše aplikace může použít, než je porovnáte se směrovanou VPN.

Terminál se připojí, objeví se výzva a všichni souhlasí, že SSH přístup funguje. Pak se klient databáze na notebooku stále nedostane k soukromému hostu a vina padá na relaci. To, co bylo postaveno, byl shell, což je jedno ze čtyř značně odlišných rozhraní, která SSH nabízí. Nejprve pojmenujte rozhraní a pak ověřte, že aplikace skutečně používá právě je. Pořadí je důležité, protože každé rozhraní selhává po svém.

Pojmenujte rozhraní dřív, než cokoli porovnáte

manuál klienta OpenSSH rozlišuje čtyři mechanismy, které se snadno pletou. Shell nebo vzdálený příkaz se spouští na hostu SSH. Místní přesměrování otevře naslouchající socket na klientovi a navazující spojení vytvoří ze vzdálené strany. Vzdálené přesměrování dělá opak a naslouchá na straně serveru. Dynamické přesměrování vystavuje koncový bod SOCKS programům, které jej umějí použít.

  • Shell: program běží na vzdáleném stroji, místně nic neposlouchá.
  • Místní přesměrování: váš notebook má port, vzdálený host vytváří odchozí spojení.
  • Vzdálené přesměrování: vzdálená strana má port, provoz se vrací k vám.
  • Dynamické: proxy SOCKS na klientovi, používají ji pouze aplikace, které jí rozumějí.

Nic z toho neinstaluje trasu. Program, který ignoruje nastavení proxy, nebo mluví UDP, nebo si sám překládá jména, není aktivní SSH relací ovlivněn. To není chyba v SSH; to je rozsah rozhraní, které jste zvolili.

Místní, vzdálené a dynamické přesměrování se liší tím, kdo naslouchá

Rozdíl, který rozhoduje většinu případů, je, kdo vlastní naslouchající socket. U místního přesměrování naslouchá klient a vzdálený konec vytočí cíl, proto se adresa cíle překládá z pohledu serveru. U vzdáleného přesměrování naslouchá server a spojení se přenáší zpět na vaši stranu, a tak vystavíte místní službu, aniž byste ji přímo publikovali.

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

První příkaz naváže port 5432 na notebooku a přesměruje jej do databáze tak, jak ji vidí bastion. Druhý vytvoří proxy SOCKS na portu 1080. Třetí příkaz potvrdí, které procesy skutečně naslouchají, a to je jediný důkaz, že přesměrování existuje, místo aby tiše selhalo kvůli kolizi portů.

Dynamické přesměrování si zaslouží vlastní varování: pokrývá jen aplikace, které respektují SOCKS. Prohlížeč na něj lze nasměrovat, nástroji příkazové řádky lze říct, aby jej použil, ale ovladač databáze s vlastním spojovým zásobníkem obvykle nemůže. Předpoklad, že každý program na stroji nyní používá tunel, je nejčastější chyba v celé této oblasti.

Režim tunelového zařízení je jediná skutečná síťová výjimka

OpenSSH podporuje také přesměrování tunelového zařízení -w, které předává rozhraní bod-bod místo TCP posluchače. To je skutečný síťový tunel a konfiguruje se záměrně, není to vedlejší efekt otevření shellu.

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

Potřebuje odpovídající čísla rozhraní dostupná na obou koncích, správnou konfiguraci na serveru a dostatek oprávnění na klientovi k vytvoření zařízení. Potřebuje také plán adresování a směrování, protože holé rozhraní nenese žádnou politiku o tom, které cíle je mají používat.

I tak tunel končí na vzdáleném hostu. Jakákoli ochrana, kterou SSH transport poskytl, tam končí a navazující spojení je samostatný skok. Brána VPN má stejný tvar hranice, a proto by srovnání mělo být o rozsahu a ukončení, nikoli o tom, který nástroj je silnější. Vyslovení této hranice také ukončuje spor o tom, zda tunel „šifruje všechno“, protože zjevně nešifruje.

Ověřte, že vaše aplikace používá rozhraní, které jste postavili

Ověřování je pro každou aplikaci, ne pro relaci. Fungující přesměrování dokazuje, že port je navázán a vzdálená strana může vytočit; nedokazuje, že program, na kterém vám záleží, se připojil skrz něj.

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'

První příkaz odešle požadavek přes koncový bod SOCKS s názvem hostitele přeloženým vzdáleně a druhý procvičí přesměrovaný port databáze s TLS stále vyžadovaným. Spusťte stejné testy se zastaveným přesměrováním, abyste potvrdili, že selhávají, protože test, který projde oběma způsoby, tunel nikdy nepoužíval.

Potom porovnejte se směrovanou VPN pouze v dimenzích, na kterých záleží: které cíle jsou pokryty, které protokoly fungují, kde ochrana končí a kdo musí schválit přístup. Přesměrování jedné služby může být užší a lepší odpovědí, zatímco VPN je správný tvar, když mnoho aplikací potřebuje stejnou síťovou cestu. Ani jedno neposkytuje vše dostupné z jeho vzdáleného koncového bodu.

Související články