Pushnuté trasy OpenVPN se neinstalují: časování, práva nebo zásady

Server tvrdí, že trasu pushnul, klient tvrdí, že je připojen, a cíl je přesto nedostupný. Přesně tento obrázek vytvářejí tři příčiny. Přidání trasy proběhlo dřív, než zařízení existovalo, klientovi chyběla práva změnit tabulku, nebo zásady klientovi nařídily ignorovat pushnuté volby.

Zvenčí vypadají stejně a vyžadují různé opravy. Přečtěte klientský log v místě, kde se rozhodnutí o trase přijímá.

Dokažte, že trasa chybí, ne že je jen rozbitá

Začněte důkazem, že trasa chybí, a ne že je rozbitá. V Linuxu ip route show dev tun0 vypíše, co klient nainstaloval na tunelovém zařízení. Ve Windows route print nebo Get-NetRoute ukáže totéž v tabulkové podobě.

Trasa, která existuje, ale nepředává provoz, je jiný problém. To přesouvá vyšetřování k pravidlům předávání a firewallu, ne k instalaci trasy.

Časování: přidání proběhlo dřív, než zařízení existovalo

Klient analyzuje PUSH_REPLY serveru poté, co je řídicí kanál navázán a co nakonfiguroval rozhraní. Teprve pak se dotkne směrovací tabulky, a to mechanismem, který platforma nabízí. Linux jde přes netlink; Windows používá API, které vyžaduje zvýšený token. Skript nebo klient, který přidává trasy hned po přečtení konfigurace, může proběhnout dřív, než zařízení TUN/TAP existuje, a jádro přidání odmítne.

Stejný závod vysvětluje, proč ručně napsaná trasa funguje, zatímco automatická ne: než ji napíšete, rozhraní už je nahoře.

route-delay existuje právě pro tento případ a route-up pojmenovává skript, který se spustí po nakonfigurování rozhraní a tras. Trasy závislé na adrese tunelu dejte do tohoto hooku, ne do rané fáze.

Práva: kdo smí měnit tabulku

Změna směrovací tabulky Windows vyžaduje zvýšený token. GUI spuštěné běžným uživatelem může nastavit adresu adaptéru přes službu a přesto trasu přidat nedokáže. Log pak ukáže chybu typu přístup odepřen, ne chybějící push.

Spuštění GUI jako správce nebo použití klienta založeného na službě tento výsledek mění. Naplánovaná úloha, která klienta spustí bez potřebného tokenu, nikoli.

Než cokoli změníte, ověřte pod jakým účtem klient skutečně běží. Verze a režim služby rozhodují, které příčiny jsou vůbec možné, takže obojí zaznamenejte vedle výstupu tras.

Zásady: pushnuté trasy lze záměrně zahodit

route-nopull nutí klienta ignorovat trasy, které server pushuje, včetně pushnuté výchozí trasy, zatímco adresa tunelu se stále přijímá. Pushnuté volby DNS a DHCP se zahazují stejnou direktivou. Takový klient není vadný; očekává výslovné řádky tras ve vlastní konfiguraci.

route-noexec je jiná kontrola: úplně zastaví klienta ve vykonávání změn tras. Topologie, kterou klient nedokáže zmapovat, může dát podobný výsledek, přičemž trasa se zaloguje jako odmítnutá, ne přidaná. Přečtěte řádek logu, který rozhodnutí hlásí, místo hádání, která ze tří příčin platí. Pak zkontrolujte efektivní profil, protože importér nebo nástroj správy může přidat volby, které uživatel nikdy needitoval.

Profil, který v textovém editoru vypadá čistě, může za běhu přesto nést přidanou direktivu.

Porovnejte seznam pushů s tabulkou

Po připojení položte seznam pushů serveru vedle tabulky klienta. V Linuxu to je ip route show dev tun0; ve Windows route print nebo Get-NetRoute. Pokud trasa chybí, opravte nejprve instalaci. Pokud existuje a provoz selhává, přejděte k zásadám předávání a firewallu.

Zaznamenejte verzi klienta, účet, pod kterým běží, a zda je založený na službě. Tyto tři skutečnosti řeknou dalšímu člověku, které příčiny byly vyloučeny.