OpenVPN:s "File exists" på en rutt är inte ett filproblem

Börja där meddelandet visas. En klient ansluter, tunneln kommer upp och sedan rapporterar loggen att Linux-kommandot för att lägga till rutten misslyckades med File exists. Inget i den meningen hänvisar till ett certifikat, en nyckel eller en konfigurationsfil, även om orden antyder det. Kärnan beskriver sin rutttabell, och prefixet du bad att installera har redan en post.

Följ klientens egen ordning: vad den bad om, vad tabellen redan innehöll, vem som placerade posten där, och först därefter vad som ska ändras. Varje steg tar bort en möjlig ägare.

Vad klienten faktiskt bad om

Före felet loggar klienten rutten den tänker lägga till, vanligtvis som destination, nätmask, gateway och ibland som metrik eller tabell. Den raden är begäran. Felet som följer är kärnans svar på den, och de två bör läsas sida vid sida.

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

En icke-noll utgångsstatus från rutthjälparen är mindre informativ än texten under den, eftersom olika kärnsvar ger en icke-noll-status. Behåll det exakta meddelandet; skillnaden mellan en befintlig post och en onåbar gateway avgör vilket av de följande avsnitten som gäller.

Läs den befintliga rutten, inte bara adressen

Att söka i tabellen efter samma punktade fyrdel räcker inte. Ett ruttobjekt identifieras av sin adressfamilj, tabell, destinationsprefix, metrik, protokoll och utenhetsenhet, och poster som delar ett prefix kan lagligt samexistera när dessa attribut skiljer sig. Det är hela objektet som kolliderar, inte texten.

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

Det sista kommandot besvarar en annan fråga än de två första: inte vad som finns, utan vilken post kärnan skulle välja för den destinationen just nu. Båda vyerna är användbara, och de är oense tillräckligt ofta för att vara värda att jämföra innan du drar någon slutsats. Oöverensstämmelsen mellan dem är det intressanta fallet, inte ett avrundningsfel.

Notera prefixet, tabellen, metriken och enheten bredvid den misslyckade begäran. Om den befintliga posten har samma attribut och samma nästa hopp har du en dubblerad instruktion och inte ett ruttproblem.

Fyra ägare ett prefix kan ha

Anslutna rutter kommer från en tilldelad adress och återskapas av systemet varje gång den adressen finns. En DHCP-klient eller en anslutningshanterare installerar rutter som en del av sin egen livscykel. En annan VPN-klient kan redan bära samma prefix. Och en lokal hook eller ett skript kan lägga till en som ingenting annat vet om.

Varje ägare behöver en annan korrigering. En ansluten rutt är inte din att radera; att ta bort den kan bryta lokal åtkomst innan tunneln är användbar, och kärnan sätter tillbaka den. En rutt som ägs av en hanterare bör ändras genom den hanteraren, inte med en manuell ip route del som nästa återanslutning ångrar.

Ett bevarat gränssnitt gör samma förvirring lättare. När tunneleenheten överlever en återanslutning kan rutter som installerats av anpassad konfigurationskod fortfarande finnas vid andra körningen, så ett skript som antar ett rent tillstånd misslyckas andra gången och fungerar första gången. Antingen rensa den inaktuella posten medvetet eller gör konfigurationskoden idempotent.

block-local besvarar en annan fråga

När en profil skickar all trafik genom tunneln måste klienten avgöra vad som händer med det lokala nätverket. Flaggan block-local ändrar det beslutet genom att dirigera det lokala LAN:et genom tunneln samtidigt som det dokumenterade undantaget för LAN-gatewayen behålls; det är ett trafikpolitiskt val med synliga konsekvenser för nåbarheten.

Det förklarar inte varför tillägget av en rutt returnerade ett fel om befintlig post, och att anta det som en universell reparation döljer den faktiska konflikten bakom en policyändring. Om dina lokala resurser slutar vara nåbara efter en profilredigering är denna flagga en av de första sakerna att undersöka; om tillägget av en rutt misslyckas är det inte svaret.

Behandla det som ett beslut om vilka destinationer som förblir lokala, fattat medvetet och nedskrivet. Det är ingen brytare att pröva när loggen ser alarmerande ut.

Slut cirkeln: ta bort dubbletten vid dess källa

När du vet vilken ägare som håller posten tar du bort den dubblerade instruktionen där den är definierad. Det kan vara en route-rad i profilen, en push från servern eller en hook som inte längre behöver köras.

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

Anslut sedan igen och bekräfta tre saker: tunneln kommer upp, den avsedda destinationen löses till den väg du ville ha, och felet är borta utan att ett nytt dyker upp i dess ställe. En ren logg med fel vald väg är inte en korrigering.

Om prefixet betyder det lokala LAN:et på ena sidan och ett fjärrnätverk på den andra är problemet en adressöverlappning och inte en dubblett, och ingen mängd radering gör båda betydelserna sanna samtidigt. Det fallet behöver en annan plan för ett av de två näten. Bestäm vilken sida som ska numreras om innan du rör någon av dem.