Zachovejte místní SSH, když host používá odchozí VPN

Malý linuxový server používá odchozí VPN pro aplikaci, kterou hostuje, a správce se k němu stále chce dostat přes SSH ze sousední kanceláře. Je to rozumný požadavek a obvykle nevyžaduje přesměrování portů, adresu poskytovatele ani díru v tunelu. Potřebuje cestu správy navrženou záměrně, místo aby dědila to, co klient VPN provedl se směrovací tabulkou.

Následující kroky předpokládají, že správce je ve stejné LAN.Vzdálená správa je jiný problém s jinou odpovědí.

Privažte SSH k adrese, kterou správci používají

Začněte u naslouchače.ss -ltnp | grep :22 ukazuje, k čemu je sshd přivázán, a naslouchač na 0.0.0.0 přijímá spojení ze všech rozhraní, včetně tunelu. Přivázání k adrese LAN je užší a činí záměr viditelným:ListenAddress 192.168.10.20 v sshd_config, následuje test konfigurace a znovunačtení. Překlep v této adrese je viditelnější než zástupný znak, protože sshd odmítne startovat, když adresa neexistuje.

Ponechte kontrolu klíče hostitele a ověřování každého uživatele přesně tak, jak jsou. „Je to jen místní síť“ není metoda ověřování a kanál správy, který přeskakuje ověření klíče, protože je trasa krátká, je kanál správy čekající na zneužití. Rezervace DHCP nebo statická adresa dělá cíl předvídatelným, aniž by z něj udělala veřejnou identitu serveru.

Držte trasu LAN mimo tunel

Hostitel s adresou v 192.168.10.0/24 má pro tento prefix připojenou trasu a konkrétnější trasa poráží výchozí trasu VPN ve stejné tabulce. Proto místní SSH často funguje dál samo, když se tunel zvedne. Ověřte to, místo abyste to předpokládali:ip route get 192.168.10.50 pojmenovává rozhraní a zdrojovou adresu, které by jádro použilo, a odpovědí by mělo být zařízení LAN, ne tunel. Zopakujte kontrolu i ze stroje správce, protože o tom, zda pakety vůbec dorazí, rozhoduje jeho vlastní tabulka. Dva hostitelé na stejném kabelu se mohou neshodnout, který směr je dostupný.

Předpoklad se láme na dvou místech. Pravidlo směrování podle zásad může poslat provoz do tabulky, jejíž výchozí trasa míří do tunelu, dříve než se podívá do hlavní tabulky. Klient VPN s funkcí uzamčení nebo kill switch může také blokovat provoz, který do tunelu nevstupuje, bez ohledu na to, co říká směrovací tabulka.

Směrované správní VLAN jsou druhý případ. Pokud správce sedí na 192.168.50.0/24 za místním routerem, server potřebuje výslovnou trasu pro tento prefix přes 192.168.10.1 a tato trasa musí přežít opětovné připojení. Držte výjimku konkrétní pro správní prefix; široká výjimka pro soukromé rozsahy ničí účel tunelu.

Udělejte výjimku firewallu tak úzkou, jako je pravidlo

Pokud hostitel provozuje firewall, povolte SSH jen ze zdroje správy a jen na rozhraní LAN. Pravidlo, které povoluje port 22 odvšad, je širší než požadavek a hůře obhajitelné při revizi. Na hostiteli s nftables patří pravidlo do vstupního řetězce se shodou rozhraní a zdroje; na hostiteli s iptables je ekvivalentem dvojice shod na -i a -s. Okomentujte pravidlo skupinou správců, které slouží, aby příští audit nemusel hádat, proč je port 22 otevřený.

Zkontrolujte i vlastní filtr klienta VPN. Někteří klienti instalují pravidla, která návrhově zahazují místní provoz, a správné pravidlo firewallu navrch zahazování na úrovni klienta nic nezmění. Přečtěte si konfiguraci klienta dřív, než upravíte firewall hostitele, protože dva filtry v sérii dávají selhání, které se nepodobá ani jednomu z nich.

Otestujte oba stavy

Spusťte test dvakrát: jednou s připojeným tunelem a jednou s odpojeným. V každém stavu potvrďte naslouchač, trasu a skutečné přihlášení přes SSH ze stroje správce. Cesta, která funguje jen dokud je tunel zvednutý, není místní cesta správy; je to náhoda.

Potom restartujte tunel, zatímco je otevřená relace SSH. Relace, která přežije, dokazuje, že směrování je stabilní; relace, která spadne, vám říká, že klient při opětovném připojení přepisuje trasy nebo filtry, což stojí za to vědět před incidentem, ne během něj.

Zapište zdrojovou adresu, ze které jste testovali, protože pravidlo napsané pro 192.168.10.50 tiše selže, když se notebook správce přesune do jiné podsítě.

Zapište cestu obnovy do runbooku

Rozhodněte teď, co se stane, když odchozí VPN rozbije místní cestu. Přístup přes konzoli, druhá adresa správy nebo dokumentovaný postup pro zastavení klienta jsou všechny legitimní odpovědi a kterákoli z nich je lepší než objevit problém v okamžiku, kdy se potřebujete přihlásit. Pokud je server vzdálený, místní cesta neexistuje a správný návrh je samostatná schválená trasa vzdáleného přístupu nebo bastion, ne vystavený veřejný port.

Držte obě role v dokumentaci oddělené: místní SSH pro správce, který je poblíž, a odchozí tunel pro provoz aplikace. Když jsou tyto role zapsané, budoucí změna kterékoli z nich má zjevné místo ke kontrole a další člověk nemusí znovu objevovat, proč server s VPN stále odpovídá na své adrese LAN.