Spouštíte VPN klienta přes SSH? Nejprve si připněte vlastní trasu
Klient s plným tunelem přepisuje tabulku, která nese vaši SSH odpověď. Připněte jednu trasu k hostu přes starou bránu, nebo spusťte klienta v jeho vlastním jmenném prostoru.
Přihlásíte se přes SSH na build host, spustíte na něm VPN klienta a relace přestane odpovídat. Nic nespadlo a nic se nezdá být špatně nakonfigurované v tom zřejmém smyslu. Klient nainstaloval výchozí trasu, takže odpovědi na váš pracovní stanici nyní odcházejí tunelem, kde adresa vaší pracovní stanice není směrovatelná. Zajímavé je, že tento výsledek byl předvídatelný, a oprava je jedna trasa zapsaná před startem klienta. Předpokládejme server s jedním síťovým adaptérem, bránu 192.0.2.254 a správce, který se připojuje z 203.0.113.9.
Zaznamenejte cestu před startem
ip route show default uvádí aktuální bránu a rozhraní, zatímco ip route get 203.0.113.9 ukazuje, které rozhraní a zdrojovou adresu by jádro použilo pro vaši relaci. Uložte oba výstupy. Po zvednutí tunelu by tyto dva příkazy měly stále popisovat fyzickou cestu, a pokud popisují tunel, relace už žije z vypůjčeného času.
Na tom záleží navázané spojení, proto neověřujte jen novým přihlášením. Nová relace může krátce uspět díky stavu, který ta stará už nemá.
Připněte adresu ve vlastní konfiguraci klienta
Trasa přidaná ručně zmizí při restartu a závodí s vlastními aktualizacemi tabulky klienta, proto výjimku vložte tam, kde se tabulka spravuje. V OpenVPN se klíčové slovo net_gateway přeloží na bránu, která existovala před tunelem, takže route 203.0.113.9 255.255.255.255 net_gateway ponechá přesně jednu adresu mimo něj. WireGuard potřebuje jiný přístup, protože wg-quick spravuje trasy sám: nastavte Table = off a přidejte výjimku do PostUp, s odpovídajícím PostDown, který ji odstraní. Obě formy vyjadřují stejný záměr a obě omezují výjimku na jednu adresu, místo aby oslabily tunel pro všechno.
Pro IPv6 bere stejná myšlenka prefix jednoho hostu a případ zabaleného transportu stojí za zapamatování: pokud vnější spojení samotného tunelu žije na pevné adrese, musí tato adresa zůstat mimo tunel, který nese, jinak klient směruje svůj vlastní transport do sebe.
Nebo vyjměte hlavní tabulku z rovnice
Když si několik služeb na hostu musí zachovat svou obvyklou cestu, přestaňte upravovat hlavní tabulku a dejte klientovi jeho vlastní. Síťový jmenný prostor s párem veth to dělá čistě: výchozí trasa klienta žije v jiném zásobníku a tunel používají jen procesy spuštěné uvnitř něj. Politické směrování se dostane na podobné místo pro jeden cíl, když odpovídající provoz pošle do vyhrazené tabulky, jejíž výchozí trasa stále ukazuje na fyzickou bránu. Oba přístupy nechávají hlavní tabulku hostu bez nové výchozí trasy, a to je vlastnost, která drží SSH v odpovídání.
Obojí je víc mechaniky než jedna trasa k hostu a obojí stojí za to, když musí tunel přežít víc než jedna věc na stroji.
Počítejte s tím, že připnutí může selhat
Trasa vázaná na vaši aktuální veřejnou adresu se zlomí ve chvíli, kdy vám ji poskytovatel přidělí znovu. Vzdálený server pak potřebuje cestu, která na této adrese nezávisí: konzolu, druhé rozhraní pro správu nebo jump host, který zůstane mimo tunel.
Dvě pojistky stojí deset minut. Watchdog, který zastaví klienta, když se během několika minut neobjeví potvrzovací přihlášení, promění uzamčení na zpoždění, a druhá SSH relace držená během změny otevřená dokazuje, že výjimka funguje, zatímco je tunel nahoře. Samotné keepalives tu nepomohou, protože cesta zmizela, místo aby jen lenošila; jen usnadní smrt si všimnout.
Ověřujte v pořadí, na kterém záleží
Připojte tunel, potvrďte, že trasa k vaší adrese stále vychází fyzickou bránou, a potom otevřete novou relaci. Pokud nová relace funguje a stará přesto umře, příčinou je sledování spojení nebo stavový firewall, ne směrování, což je jiná oprava.
Zapište připnutou adresu a příkaz, který ji prokázal, do záznamu o změnách. Další člověk, který na tom hostu spustí klienta, bude potřebovat obojí, a adresa se do té doby mohla změnit.