OpenVPN redirect-gateway: co každý přepínač dělá s trasami

Připojte se s redirect-gateway v profilu a výchozí trasa vašeho počítače může zmizet, rozdělit se na dvě nebo zůstat přesně tam, kde byla, podle přepínačů, které nikdo nečte dvakrát. Volba mění stav směrování a nic jiného, takže jediným spolehlivým důkazem toho, co udělala, je tabulka, kterou klient poté nainstaloval. Následuje tabulka po připojení, trasa, která udržuje samotný tunel živý, a provoz IPv6, který direktiva nikdy netvrdí, že pokrývá. Každý krok je příkaz, který můžete na klientovi spustit, dokud je tunel aktivní.

Co každý přepínač dělá s výchozí trasou

Bez jakéhokoli přepínače volba odstraní běžnou výchozí trasu a místo ní postaví tunel, takže stará brána z tabulky zmizí, dokud je spojení aktivní. Přidejte def1 a tato výchozí trasa zůstane v seznamu, přičemž práci odvedou dvě užší trasy. Přidejte bypass-dhcp a přežije i trasa DHCP, což je důležité v síti, kde se klient stále musí dostat na místní server DHCP. Seznam přepínačů na stránce manuálu OpenVPN 2.6 je dost krátký na jedno přečtení a každá položka mění, které trasy skončí v tabulce.

Zaslaná volba se po příchodu chová stejně, takže klientský profil nemusí obsahovat nic, zatímco tabulka vypadá plně přesměrovaná. To je normální: server poslal přepínače, klient je použil a místní soubor direktivu nikdy nezmínil. Když se zdá, že push nic nedělá, zkontrolujte filtr na straně klienta, který stažené volby přijímá nebo zahazuje, protože zahozená volba nevyvolá chybu na žádné straně.

def1 vyhrává specificitou, aniž by se dotkl vaší výchozí trasy

Dvě poloviny výchozí trasy společně pokrývají prostor IPv4, 0.0.0.0/1 a 128.0.0.0/1. Každá je konkrétnější než 0.0.0.0/0, takže je vyhledávání upřednostní, zatímco skutečná výchozí trasa zůstává v tabulce pro vše, co žádá nejméně konkrétní shodu.

Čtěte tabulku, ne profil, protože jen tabulka ukazuje, ve kterém z těchto případů jste. K jejich rozlišení stačí dva řádky:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Zaznamenejte rozhraní a metriku na každém řádku, ne jen cíl. Výchozí trasa ukazující do tunelu a dvojice polovin výchozí trasy ukazujících do tunelu popisují stejný záměr a selhávají jinak, když tunel spadne, protože v jednom případě záložní varianta stále existuje. Zapište obě pole do poznámky o změně. Přeživší záloha někdy udrží vzdálenou relaci živou dost dlouho na opravu tunelu a je to také to, co uniká provoz, když byl záměrem plný tunel.

Udržujte koncový bod tunelu dosažitelný

Klient potřebuje trasu k vzdálenému konci tunelu, která sama nevede tunelem. OpenVPN tuto hostitelskou trasu nainstaluje dřív, než změní cokoli jiného, a ruční úprava tras nebo druhý VPN klient ji mohou odebrat. Symptomem potom je spojení, které hlásí připojeno a pak nic nepředá.

Zeptejte se jádra, které rozhraní by použilo pro adresu koncového bodu, dokud je tunel aktivní. Odpověď musí uvést fyzické rozhraní a jeho bránu, nikdy tun0:

ip route get 198.51.100.20

Pokud toto hledání vrátí zařízení tunelu, tunel nese vlastní transport a zhroutí se, jakmile bude muset nějaký paket odejít. Místní prefixy, druhý adaptér a směrování podle zásad tu stále hrají roli, a proto přesměrování, které funguje na čistém notebooku, může selhat na hostiteli s rozhraním pro správu a dvěma výchozími trasami. Obvykle se obviňuje profil z toho, co udělal plán adres.

Provoz IPv6 dál používá svou vlastní tabulku

Přesměrování IPv4 nechává IPv6 být a obě rodiny se mění různými přepínači. Na hostiteli s duálním zásobníkem a funkční výchozí trasou v6 může provoz v4 zůstat plně uvnitř tunelu, zatímco každý cíl schopný v6 odchází přes fyzické rozhraní. Hostitel, který vypadá správně v jedné tabulce, uniká v druhé.

Po připojení zkontrolujte tabulku v6, místo abyste předpokládali, že ji tunel pokryl. Direktiva nese přepínače rodiny adres právě proto a profil, který je vynechá, zdědí to, co platforma dělá ve výchozím nastavení:

ip -6 route show default
ip -6 route get 2001:db8::10

Dokažte, které rozhraní aplikace používá

Stav připojeno není blokování a změna trasy není nouzový vypínač. Pokud má přímý provoz přestat, když tunel selže, tato zásada žije ve firewallu a potřebuje vlastní test.

Testujte cestu, kterou aplikace skutečně jde, ne cestu, kterou popisuje profil. Nejprve si vyžádejte trasu, poté postupně přivažte požadavek na každé rozhraní a porovnejte, co hlásí vzdálená strana:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Pokud oba požadavky vrátí stejnou adresu, aplikace tunel nepoužívá, i když směrovací tabulka říká, že by měla. Pokud uspěje jen požadavek vázaný na tunel, fyzická cesta je pro tento cíl filtrovaná a tunel dělá, o co jste požádali. Zapište přepínače, nainstalované trasy, hledání koncového bodu a oba výsledky odchodu do záznamu o změně, aby další člověk zdědil fakta místo snímku obrazovky.