OpenVPNs «File exists» på en rute er ikke et filproblem

Begynn der meldingen vises. En klient kobler til, tunnelen kommer opp, og deretter rapporterer loggen at Linux-kommandoen for å legge til ruten mislyktes med File exists. Ingenting i den setningen viser til et sertifikat, en nøkkel eller en konfigurasjonsfil, selv om ordene antyder det. Kjernen beskriver rutetabellen sin, og prefikset du ba om å installere har allerede en oppføring.

Følg klientens egen rekkefølge: hva den ba om, hva tabellen allerede inneholdt, hvem som plasserte oppføringen der, og først deretter hva som skal endres. Hvert steg fjerner én mulig eier.

Hva klienten faktisk ba om

Før feilen logger klienten ruten den har tenkt å legge til, vanligvis som destinasjon, nettmaske, gateway og noen ganger som metrikk eller tabell. Den linjen er forespørselen. Feilen som følger er kjernens svar på den, og de to bør leses side om side.

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 ikke-null utgangsstatus fra rutehjelperen er mindre informativ enn teksten under den, fordi ulike kjernesvar gir en ikke-null-status. Ta vare på den nøyaktige meldingen; skillet mellom en eksisterende oppføring og en utilgjengelig gateway avgjør hvilken av de neste delene som gjelder.

Les den eksisterende ruten, ikke bare adressen

Å søke i tabellen etter samme prikkede firedel er ikke nok. Et ruteobjekt identifiseres av adressefamilien, tabellen, destinasjonsprefikset, metrikken, protokollen og utenhetsenheten, og oppføringer som deler et prefiks kan lovlig eksistere side om side når disse attributtene er forskjellige. Det er hele objektet som kolliderer, ikke teksten.

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

Den siste kommandoen svarer på et annet spørsmål enn de to første: ikke hva som finnes, men hvilken oppføring kjernen ville velge for den destinasjonen akkurat nå. Begge visningene er nyttige, og de er uenige ofte nok til å være verdt å sammenligne før du konkluderer med noe. Uoverensstemmelsen mellom dem er det interessante tilfellet, ikke en avrundingsfeil.

Noter prefikset, tabellen, metrikken og enheten ved siden av den mislykkede forespørselen. Hvis den eksisterende oppføringen har de samme attributtene og samme neste hopp, har du en duplisert instruksjon og ikke et ruteproblem.

Fire eiere et prefiks kan ha

Tilkoblede ruter kommer fra en tildelt adresse og gjenskapes av systemet hver gang den adressen finnes. En DHCP-klient eller en tilkoblingsbehandler installerer ruter som en del av sin egen livssyklus. En annen VPN-klient kan allerede bære det samme prefikset. Og en lokal hook eller et skript kan legge til en som ingenting annet vet om.

Hver eier trenger en annen korreksjon. En tilkoblet rute er ikke din å slette; å fjerne den kan bryte lokal tilgang før tunnelen er brukbar, og kjernen setter den tilbake. En rute som eies av en behandler bør endres gjennom den behandleren, ikke med en manuell ip route del som neste gjenoppkobling angrer.

Et beholdt grensesnitt gjør den samme forvirringen lettere. Når tunneleenheten overlever en gjenoppkobling, kan ruter installert av tilpasset oppsettkode fortsatt være til stede ved andre kjøring, slik at et skript som antar en ren tilstand feiler andre gang og virker første gang. Enten tøm den utdaterte oppføringen bevisst eller gjør oppsettkoden idempotent.

block-local svarer på et annet spørsmål

Når en profil sender all trafikk gjennom tunnelen, må klienten avgjøre hva som skjer med det lokale nettverket. Flagget block-local endrer denne avgjørelsen ved å rute det lokale LAN-et gjennom tunnelen mens det dokumenterte unntaket for LAN-gatewayen beholdes; dette er et trafikkpolitisk valg med synlige konsekvenser for tilgjengeligheten.

Det forklarer ikke hvorfor tilføying av en rute returnerte en feil om eksisterende oppføring, og å vedta det som en universell reparasjon skjuler den faktiske konflikten bak en policyendring. Hvis de lokale ressursene dine slutter å være tilgjengelige etter en profilredigering, er dette flagget en av de første tingene å undersøke; hvis tilføying av en rute mislykkes, er det ikke svaret.

Behandle det som en avgjørelse om hvilke destinasjoner som forblir lokale, tatt bevisst og skrevet ned. Det er ikke en bryter å prøve når loggen ser alarmerende ut.

Lukk sirkelen: fjern duplikatet ved kilden

Når du vet hvilken eier som holder oppføringen, fjerner du den dupliserte instruksjonen der den er definert. Det kan være en route-linje i profilen, et push fra serveren eller en hook som ikke lenger trenger å kjøre.

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

Koble deretter til på nytt og bekreft tre ting: tunnelen kommer opp, den tiltenkte destinasjonen løses til veien du ønsket, og feilen er borte uten at en ny dukker opp i dens sted. En ren logg med feil valgt vei er ikke en rettelse.

Hvis prefikset betyr det lokale LAN-et på den ene siden og et eksternt nettverk på den andre, er problemet en adresseoverlapp og ikke et duplikat, og ingen mengde sletting vil gjøre begge betydningene sanne samtidig. Det tilfellet trenger en annen plan for ett av de to nettverkene. Bestem hvilken side som skal omnummereres før du rører noen av dem.