OpenVPN pořád tlačí staré trasy? Zkontrolujte, co skutečně načetl

Přidáte trasu, restartujete službu, znovu se připojíte a tabulka klienta vypadá přesně jako dřív. Platit mohou dvě různé věci: server vaši úpravu nikdy nenačetl, nebo klient nenainstaloval to, co dostal. Společný mají jen příznak, takže prvním krokem je zjistit, který z těch dvou případů máte.

Srovnání níže postupuje od procesu ven, protože proces je jediná autorita v tom, který soubor platí.

Soubor, který jste upravili, a soubor, který proces čte

Začněte u unit a příkazového řádku, který vytvořila. Na hostiteli se systemd systemctl cat openvpn@server vypíše řádek ExecStart a instance unit obvykle odvozuje cestu ke konfiguraci z názvu instance, takže démon spuštěný jako openvpn@office čte jiný soubor než ten spuštěný jako openvpn@server. Porovnejte to s argv běžícího procesu. Nástroj pro správu konfigurace přidává další způsob, jak změnu ztratit: může napsat správný soubor na místo, které unit nikdy nezmiňuje, a úspěšný deploy pak vypadá jako nic.

Časová razítka to rychle vyřeší: je-li soubor novější než doba spuštění procesu, proces ho nemohl přečíst. Firmware routeru přidává třetí případ, protože mnoho modelů drží nastavení ve flash a konfiguraci při startu znovu sestavuje, což dělá úpravu souboru na disku úplně špatnou vrstvou.

Co server tlačí a co klient instaluje

Tlačená trasa musí projít dvěma filtry. Na serveru musí být v načtené konfiguraci, ne v zakomentovaném bloku ani v souboru specifickém pro klienta, jehož název nesedí. Na klientovi musí být pull zapnutý a žádný pull-filter nesmí volbu zahazovat. Připojte se s verbosity 4 a přečtěte tlačené volby, které klient hlásí: pokud se trasa v tom seznamu objeví, server udělal svou práci a klient se rozhoduje ji nenainstalovat.

Soubory specifické pro klienta jsou častým zdrojem zmatku. Soubor pojmenovaný podle common name certifikátu tlačí volby jen tomu klientovi a rozdíl v jediném znaku tlačení tiše zastaví, bez chyby na kterékoliv straně. Server zaznamenává common name, které viděl při připojení, takže tuto hodnotu porovnejte s názvem souboru, ne s tím, jak si myslíte, že se klient jmenuje.

Tlačený prefix a zpáteční trasa jsou různé problémy

Klient, který úmyslně ignoruje redirect-gateway, aby si zachoval místní cestu na internet, vytváří druhou, nesouvisející mezeru. Sondy serveru dorazí na adresu tunelu, ale odpovědi nikdy nedorazí, protože odpověď adresovaná IP tunelu serveru se směruje přes běžnou výchozí bránu klienta. Tlačená trasa podsítě za to nemůže; chybí trasa, která vrací provoz pro síť tunelu serveru zpět tunelovým zařízením.

Přidání této trasy na klientovi opraví odpovědi na sondy, které iniciuje server. Nenahrazuje tlačenou trasu podsítě a naopak to platí také, protože obě popisují opačné směry pohybu.

Porovnejte tabulky na obou koncích

Po každé změně se znovu připojte a přečtěte tabulku klienta pro tlačený prefix a pro tunelové zařízení. Pak testujte oběma směry: z klienta na hostitele v tlačené podsíti a z toho hostitele zpět ke klientovi. Trasa, která existuje, ale nenese provoz, znamená jedno ze tří: protistrana neprosměrovává, firewall tok zahazuje, nebo odpověď nemá cestu zpět.

Držte tři identifikátory pohromadě: cestu ke konfiguraci, název unit nebo instance a identitu klienta, se kterým jste testovali.

Ty tři dělají z příštího výskytu pětiminutovou kontrolu místo dalšího vyšetřování a přesně je potřebuje kolega, když se tunel stane problémem někoho jiného.

Problém s trasou, který přežije restart, často vůbec není problém směrování; závada je výš než tabulka, kterou pořád čtete.