Vzdálený SSH přes VPN: co tunel nedělá
VPN zpřístupní SSH server a nic víc. Tři podmínky rozhodují, zda se hodí, a fáze selhání ukáže, která vrstva je vinna.
VPN dává SSH serveru soukromou cestu a odstraňuje potřebu veřejného posluchače na portu 22. Neověřuje hostitele, neautorizuje uživatele ani nerozhoduje, které účty se smějí přihlásit. To zůstává úkolem SSH. Zda je VPN správný způsob, jak se k serveru dostat, závisí na třech podmínkách, a tunel je jen jedna z možných odpovědí.
Co tunel mění a co SSH stále rozhoduje
Tunel mění dostupnost: které adresy lze dosáhnout a odkud. Nemění to, co se stane poté, co TCP spojení dorazí, kde server představí klíč hostitele a požádá o identitu uživatele.
Udržujte obě vrstvy oddělené v hlavě i v dokumentaci. Přihlášení k VPN dokazuje, kdo smí používat síť. Neříká nic o tom, které účty na cíli existují, a není to oprávnění přihlásit se na každý dostupný stroj.
Režimy selhání jsou také oddělené, a právě to dělá oddělení užitečným během incidentu.
Tři podmínky, které rozhodují o modelu přístupu
Za prvé, musí být server dostupný lidem mimo vaši síť? Pokud ne, soukromá cesta plus bastion nebo síťovina je menší design. Za druhé, může klientská populace skutečně spustit VPN klienta, včetně těch na spravovaných zařízeních s omezeními?
Za třetí, potřebujete řízení po službách, nebo po uživatelích? VPN poskytuje síťový dosah; SSH poskytuje přístup k účtu. Pokud je požadavkem, aby dodavatel dosáhl jednoho hostitele a ničeho jiného, je to požadavek na autorizaci a samotný tunel ho nemůže vyjádřit.
Odpovězte na tyto tři a model se vybere sám. Přeskočte je a skončíte tím, že SSH vystavíte veřejně, abyste se vyhnuli zavádění klienta.
Potvrďte soukromou cestu, než obviníte SSH
Připojte se ke schválené VPN a použijte dokumentovaný soukromý název nebo adresu cíle. Potom zkontrolujte zvolenou trasu, oprávnění brány a zpáteční cestu ke klientovi. Název, který se správně přeloží, není důkazem, že adresa jde zamýšleným tunelem, protože překrývající se místní a vzdálené prefixy mohou požadavek poslat zcela jinam. Tento rozdíl stojí za zapsání do runbooku.
Pokud spojení nikdy nedorazí, ověřte, že server naslouchá na rozhraní, které očekáváte a že jeho hostitelský firewall povoluje zdroj, který skutečně vidí. NAT brány může tento zdroj přepsat, takže seznam povolených napsaný pro tunelovou adresu klienta nemusí nikdy sedět.
Tento nesoulad je nejčastější samostatně způsobená závada SSH přes VPN.
Čtěte fázi selhání, ne kombinovanou chybu
Tři fáze vytvářejí tři různé zprávy a pouze jedna z nich je o přihlašovacích údajích.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Použijte přesnou chybu a vlastní log serveru místo resetování přihlašovacích údajů VPN i SSH najednou. Resetování obou je způsob, jak se z pětiminutové diagnózy stane dvoudenní incident identity.
Podrobný výstup ukazuje, do které fáze jste se dostali:
ssh -vv [email protected]Zachovejte klíče hostitele a autorizaci v pořádku
Ověřte klíč hostitele zamýšleným důvěryhodným procesem, zejména po výměně serveru. Nečekané varování o změněném klíči je jediná zpráva, kterou nesmíte odmítnout jen proto, že se VPN připojila, protože soukromý tunel nedělá z cíle stroj, který si myslíte. Zkontrolujte otisk proti zdroji, kterému důvěřujete nezávisle na spojení.
Na straně serveru ověřte, že účet je autorizován a že metoda ověřování, kterou jste nakonfigurovali, je ta nabízená. Klíč, který je přítomen, ale ignorován, je obvykle problém oprávnění nebo konfigurace, ne sítě.
Omezte přístup ke službám na potřebné identity a zachovejte autorizovanou cestu obnovy pro síťové změny.