Začněte tam, kde se zpráva objeví. Klient se připojí, tunel se zvedne a pak log oznámí, že příkaz pro přidání trasy v Linuxu selhal s File exists. Nic v této větě neodkazuje na certifikát, klíč nebo konfigurační soubor, i když to slova naznačují. Jádro popisuje svou směrovací tabulku a prefix, který jste požádali nainstalovat, už má záznam.

Sledujte vlastní posloupnost klienta: co požadoval, co tabulka už obsahovala, kdo tam ten záznam umístil, a teprve potom co změnit. Každý krok odstraňuje jednoho možného vlastníka.

Co klient vlastně požadoval

Před selháním klient zaznamená trasu, kterou hodlá přidat, obvykle jako cíl, síťovou masku, bránu a někdy metriku nebo tabulku. Ten řádek je požadavek. Chyba, která následuje, je odpověď jádra na něj, a obojí je třeba číst vedle sebe.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Nenulový návratový kód pomocníka pro trasy je méně informativní než text pod ním, protože různé odpovědi jádra dávají nenulový stav. Zachovejte přesnou zprávu; rozdíl mezi existujícím záznamem a nedostupnou bránou rozhoduje, která z následujících částí platí.

Čtěte existující trasu, ne jen adresu

Hledání stejného tečkovaného kvadru v tabulce nestačí. Objekt trasy je určen rodinou adres, tabulkou, cílovým prefixem, metrikou, protokolem a výstupním zařízením a záznamy sdílející prefix mohou legitimně koexistovat, když se tyto atributy liší. Sráží se celý objekt, ne text.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Poslední příkaz odpovídá na jinou otázku než první dva: ne co existuje, ale který záznam by jádro pro tento cíl právě teď vybralo. Oba pohledy jsou užitečné a rozcházejí se dost často na to, aby stálo za to je před jakýmkoli závěrem porovnat. Nesoulad mezi nimi je ten zajímavý případ, ne chyba zaokrouhlení.

Zapište prefix, tabulku, metriku a zařízení vedle neúspěšného požadavku. Pokud má existující záznam stejné atributy a stejný další skok, máte duplicitní instrukci, ne problém se směrováním.

Čtyři vlastníci, které může prefix mít

Připojené trasy pocházejí z přiřazené adresy a systém je znovu vytváří, kdykoli tato adresa existuje. Klient DHCP nebo správce připojení instaluje trasy jako součást svého životního cyklu. Jiný klient VPN už může stejný prefix nést. A místní háček nebo skript může přidat trasu, o které nic jiného neví.

Každý vlastník vyžaduje jinou opravu. Připojená trasa není vaše na smazání; její odstranění může přerušit místní přístup dřív, než bude tunel použitelný, a jádro ji vrátí. Trasu vlastněnou správcem je třeba měnit přes toho správce, ne ručním ip route del, které příští opětovné připojení zruší.

Zachovaný interface dělá stejný zmatek snazším. Když zařízení tunelu přežije opětovné připojení, trasy nainstalované vlastním kódem nastavení mohou při druhém běhu stále existovat, takže skript předpokládající čistý stav podruhé selže a poprvé funguje. Buď záměrně vymažte zastaralý záznam, nebo udělejte kód nastavení idempotentní.

block-local odpovídá na jinou otázku

Když profil posílá veškerý provoz tunelem, klient musí rozhodnout, co se stane s místní sítí. Přepínač block-local toto rozhodnutí mění tím, že směruje místní LAN tunelem a zachovává zdokumentovanou výjimku pro bránu LAN; je to volba dopravní politiky s viditelnými důsledky pro dostupnost.

Nevysvětluje, proč přidání trasy vrátilo chybu existujícího záznamu, a přijetí toho jako univerzální opravy skrývá skutečný konflikt za změnou politiky. Pokud vaše místní zdroje přestanou být dostupné po úpravě profilu, je tento přepínač jednou z prvních věcí ke kontrole; pokud přidání trasy selže, není to odpověď.

Berte to jako rozhodnutí o tom, které cíle zůstanou místní, učiněné záměrně a zapsané. Není to přepínač, který zkoušet, když log vypadá znepokojivě.

Uzavřete smyčku: odstraňte duplikát v jeho zdroji

Jakmile víte, který vlastník záznam drží, odstraňte duplicitní instrukci tam, kde je definována. Může to být řádek route v profilu, push ze serveru nebo háček, který už nemusí běžet.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Potom se znovu připojte a potvrďte tři věci: tunel se zvedne, zamýšlený cíl se přeloží na cestu, kterou jste chtěli, a selhání zmizí, aniž by se na jeho místě objevilo nové. Čistý log se špatně zvolenou cestou není oprava.

Pokud prefix znamená místní LAN na jedné straně a vzdálenou síť na druhé, problémem je překryv adres, ne duplikát, a žádné mazání neudělá oba významy pravdivými najednou. Ten případ potřebuje jiný plán pro jednu ze dvou sítí. Rozhodněte, která strana bude přečíslována, než se kterékoli dotknete.

Související články