ifconfig-noexec vaši SSH relaci neudrží: co vlastně dělá
Potlačuje vlastní nastavení adresy rozhraní OpenVPN. Nezajišťuje zpětnou trasu pro SSH, nevypíná každou změnu tras a nedodává chybějící adresu.
Někde ve vlákně fóra se ifconfig-noexec nabízí jako oprava, která udrží SSH relaci živou, když se tunel zvedne. Zdůvodnění zní uvěřitelně, dokud si nezkontrolujete, čeho se volba dotýká. Brání OpenVPN nakonfigurovat adresu rozhraní tunelu a tyto hodnoty předává skriptům; o tom, kam jdou odpovědi na vaše správní spojení, neříká nic. Kdo věří opaku, dostane tunel bez použitelné adresy a SSH relaci, která stejně umírá.
Co volba vlastně deleguje
Ve výchozím nastavení klient zvedne tunelové zařízení a přiřadí místní a vzdálenou adresu, kterou mu dal server. S nastavenou ifconfig-noexec se tento krok přeskočí a vyjednané hodnoty se exportují do prostředí skriptu, aby je mohlo použít něco jiného.
Vlastnictví se přesouvá. Na jeho místě se nic nevymýšlí.
Otázka, kterou volba odpovídá, tedy je, kdo konfiguruje rozhraní, a otázka, kterou neodpovídá, je, jak se pakety dostanou zpět k vám. Držte to oddělené, jinak strávíte večer úpravami tras, abyste vykompenzovali rozhraní bez adresy.
Tři podobné volby s různými úkoly
Tuhle rodinu je snadné si splést, protože názvy se liší jedním slovem a příznaky se překrývají. Přečtěte si, co každá potlačuje, než si některou vyberete.
| Volba | Co přestane probíhat |
|---|---|
ifconfig-noexec | Vlastní konfigurace tunelové adresy OpenVPN; hodnoty jdou místo toho do skriptů |
route-noexec | Automatické přidávání a odebírání tras; údaje o trase jdou do skriptu |
route-nopull | Trasy zasílané serverem a související volby jako DNS se odmítají |
Jsou to alternativy k pochopení jednotlivě, ne sada k slepení dohromady. Potlačení konfigurace adresy nepotlačuje změny tras, pravidla firewallu ani zasílané volby, které nesou DNS. Delegovaný skript také může měnit trasy, a to je rozhodnutí, které předáváte, místo abyste se mu vyhýbali.
Pokud klient dodavatele obaluje engine, použijte jeho podporovanou integraci, místo abyste do profilu hodili direktivu nízké úrovně a doufali, že obal ji respektuje. Obaly často regenerují profil při připojení, takže ruční úprava zmizí bez chyby. Zkontrolujte, kde klient drží svá nastavení, než strávíte večer u souboru. Platí to pro každý řádek tabulky, ne jen pro ten, kvůli kterému jste přišli.
SSH relace, kterou jste chtěli chránit
SSH spojení má zdrojovou adresu, cílovou adresu a zpětnou cestu. Na serveru, který právě nainstaloval plný tunel jako výchozí, odpověď na vaši veřejnou adresu odpovídá tunelu a VPN brána ji zahodí.
Nic v konfiguraci adresy rozhraní tunelu to nemění.
Opraví to konkrétnější trasa pro vaši správní adresu přes bránu před tunelem, nebo pravidlo zásad, které ten provoz řídí, plus filtrovací nastavení, která aplikuje váš hostitel. Ty dva problémy se někdy objevují společně, a právě tak se jeden považuje za lék na druhý. Testujte je odděleně: zvedněte tunel bez volby, podívejte se na adresu rozhraní a zpětnou cestu, a pak rozhodněte, který ze dvou je skutečně rozbitý.
Co musí delegovaný skript převzít
Pokud opravdu chcete, aby rozhraní konfiguroval jiný vlastník, vypište práci: použijte místní a vzdálenou adresu, zvedněte zařízení, při rozpojení adresování obnovte nebo odstraňte a totéž zopakujte po opětovném připojení. Hodnoty z jedné úspěšné relace nesmí být natvrdo zadrátované, protože server může příště přidělit jinou dvojici.
Proměnné prostředí, které klient exportuje, jsou jediný podporovaný vstup pro tuto práci.
env | grep -E '^ifconfig_|^route_'Uvnitř skriptu route-up jsou ty proměnné dostupné; z cron úlohy nebo ručního shellu nikoli. Ověřte, který hook životního cyklu vaše verze používá, a ověřte, že hook běží s dostatečným oprávněním měnit rozhraní, protože klient už mohl přejít na neprivilegovaného uživatele.
Testujte celý životní cyklus, ne jednu relaci
Zvedněte tunel, zkontrolujte adresu na zařízení, pak se znovu připojte a zkontrolujte ji zas. Konfigurace, která funguje jednou a při druhém pokusu selže, obvykle znamená, že delegovaný krok běží jen při prvním připojení.
Pak otestujte obě kritéria přijetí společně: nové SSH spojení zamýšlenou správní cestou funguje a povolená aplikace používá tunel správně.
Starý SSH relace, která náhodou přežije, zatímco tunel nemá adresu, není úspěch, a je to přesně stav, který tato volba vytváří, když nikdo práci nepřevezme. Zkontrolujte nejdřív adresu rozhraní, pak správní zpětnou cestu, pak aplikaci. Pokud jsou dvě ze tří špatné, volba přesunula práci, aniž by jí dala vlastníka.