OpenVPN stále tlačí staré trasy? Skontrolujte, čo načítal

Pridáte trasu, reštartujete službu, znova sa pripojíte a tabuľka klienta vyzerá presne ako predtým. Platiť môžu dve rôzne veci: server vašu úpravu nikdy nenačítal alebo klient nenainštaloval to, čo dostal. Spoločný majú len príznak, takže prvým krokom je zistiť, ktorý z tých dvoch prípadov máte.

Porovnanie nižšie postupuje od procesu von, pretože proces je jediná autorita v tom, ktorý súbor platí.

Súbor, ktorý ste upravili, a súbor, ktorý proces číta

Začnite pri unit a príkazovom riadku, ktorý vytvorila. Na hostiteľovi so systemd systemctl cat openvpn@server vypíše riadok ExecStart a instance unit zvyčajne odvodzuje cestu ku konfigurácii z názvu instance, takže démon spustený ako openvpn@office číta iný súbor než ten spustený ako openvpn@server. Porovnajte to s argv bežiaceho procesu. Nástroj na správu konfigurácie pridáva ďalší spôsob, ako stratiť zmenu: môže napísať správny súbor na miesto, ktoré unit nikdy neuvádza, a úspešný deploy potom vyzerá ako nič.

Časové značky to rýchlo vyriešia: ak je súbor novší než čas spustenia procesu, proces ho nemohol prečítať. Firmvér routera pridáva tretí prípad, pretože mnoho modelov drží nastavenia vo flash a konfiguráciu pri štarte znova skladá, čo robí úpravu súboru na disku úplne nesprávnou vrstvou.

Čo server tlačí a čo klient inštaluje

Tlačená trasa musí prejsť dvoma filtrami. Na serveri musí byť v načítanej konfigurácii, nie v zakomentovanom bloku ani v súbore špecifickom pre klienta, ktorého názov nesedí. Na klientovi musí byť pull zapnuté a žiadny pull-filter nesmie voľbu zahadzovať. Pripojte sa s verbosity 4 a prečítajte tlačené voľby, ktoré klient hlási: ak sa trasa v tom zozname objaví, server urobil svoju prácu a klient sa rozhoduje ju nenainštalovať.

Súbory špecifické pre klienta sú častým zdrojom zmätku. Súbor pomenovaný podľa common name certifikátu tlačí voľby len tomu klientovi a rozdiel v jedinom znaku tlačenie ticho zastaví, bez chyby na ktorejkoľvek strane. Server zaznamenáva common name, ktoré videl pri pripojení, takže túto hodnotu porovnajte s názvom súboru, nie s tým, ako si myslíte, že sa klient volá.

Tlačený prefix a spätná trasa sú rôzne problémy

Klient, ktorý úmyselne ignoruje redirect-gateway, aby si zachoval miestnu cestu na internet, vytvára druhú, nesúvisiacu medzeru. Sondy servera dorazia na adresu tunela, ale odpovede nikdy neprídu, pretože odpoveď adresovaná IP tunela servera sa smeruje cez bežnú predvolenú bránu klienta. Tlačená trasa podsiete za to nemôže; chýba trasa, ktorá vracia prevádzku pre sieť tunela servera späť cez tunelové zariadenie.

Pridanie tejto trasy na klientovi opraví odpovede na sondy, ktoré iniciuje server. Nenahrádza tlačenú trasu podsiete a naopak to platí tiež, pretože obe opisujú opačné smery pohybu.

Porovnajte tabuľky na oboch koncoch

Po každej zmene sa znova pripojte a prečítajte tabuľku klienta pre tlačený prefix a pre tunelové zariadenie. Potom testujte oboma smermi: z klienta na hostiteľa v tlačenej podsieti a z toho hostiteľa späť ku klientovi. Trasa, ktorá existuje, ale nenesie prevádzku, znamená jedno z troch: protistrana nepreposiela, firewall tok zahadzuje, alebo odpoveď nemá cestu späť.

Držte tri identifikátory pohromade: cestu ku konfigurácii, názov unit alebo instance a identitu klienta, s ktorým ste testovali.

Tieto tri robia z ďalšieho výskytu päťminútovú kontrolu namiesto ďalšieho vyšetrovania a presne ich potrebuje kolega, keď sa tunel stane problémom niekoho iného.

Problém s trasou, ktorý prežije reštart, často vôbec nie je problém smerovania; porucha je vyššie než tabuľka, ktorú stále čítate.