OpenVPN sitt «File exists» på ei rute er ikkje eit filproblem

Byrja der meldinga dukkar opp. Ein klient koplar til, tunnelen kjem opp, og deretter rapporterer loggen at Linux-kommandoen for å leggje til ruta mislukkast med File exists. Ingenting i den setninga viser til eit sertifikat, ein nøkkel eller ei konfigurasjonsfil, sjølv om orda antydar det. Kjernen skildrar rutetabellen sin, og prefikset du bad om å installere har alt ei oppføring.

Fylg den eigen rekkjefølgja til klienten: kva han bad om, kva tabellen alt inneheldt, kven som plasserte oppføringa der, og først deretter kva som skal endrast. Kvart steg fjernar ein mogleg eigar.

Kva klienten eigentleg bad om

Før feilen loggar klienten ruta han har tenkt å leggje til, vanlegvis som destinasjon, nettmaske, gateway og stundom som metrikk eller tabell. Den linja er førespurnaden. Feilen som følgjer er svaret frå kjernen, og dei to bør lesast 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

Ein ikkje-null utgangsstatus frå rutehjelparen er mindre informativ enn teksten under han, fordi ulike kjernesvar gir ein ikkje-null status. Ta vare på den nøyaktige meldinga; skiljet mellom ei eksisterande oppføring og ein utilgjengeleg gateway avgjer kva av dei neste delane som gjeld.

Les den eksisterande ruta, ikkje berre adressa

Å søkje i tabellen etter same prikka firedel er ikkje nok. Eit ruteobjekt blir identifisert av adressefamilien, tabellen, destinasjonsprefikset, metrikken, protokollen og utgangseininga, og oppføringar som deler eit prefiks kan lovleg eksistere side om side når desse attributta er ulike. Det er heile objektet som kolliderer, ikkje 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 svarar på eit anna spørsmål enn dei to første: ikkje kva som finst, men kva oppføring kjernen ville velje for den destinasjonen akkurat no. Begge visingane er nyttige, og dei er usamde ofte nok til å vere verd å samanlikne før du konkluderer med noko. Uoverensstemminga mellom dei er det interessante tilfellet, ikkje ein avrundingsfeil.

Noter prefikset, tabellen, metrikken og eininga ved sida av den mislukka førespurnaden. Viss den eksisterande oppføringa har dei same attributta og same neste hopp, har du ein duplisert instruks og ikkje eit ruteproblem.

Fire eigarar eit prefiks kan ha

Tilkopla ruter kjem frå ei tildelt adresse og blir attskapte av systemet kvar gong den adressa finst. Ein DHCP-klient eller ein tilkoplingshandsamar installerer ruter som ein del av sin eigen livssyklus. Ein annan VPN-klient kan alt bere det same prefikset. Og ein lokal hook eller eit skript kan leggje til ein som ingenting anna veit om.

Kvar eigar treng ei anna retting. Ei tilkopla rute er ikkje di å slette; å fjerne ho kan bryte lokal tilgang før tunnelen er brukbar, og kjernen set ho tilbake. Ei rute som ein handsamar eig bør endrast gjennom den handsamaren, ikkje med ein manuell ip route del som neste attoppkopling angrar.

Eit behalde grensesnitt gjer den same forvirringa lettare. Når tunneleininga overlever ei attoppkopling, kan ruter installerte av tilpassa oppsettkode framleis vere til stades ved andre køyring, slik at eit skript som reknar med ein rein tilstand feilar andre gong og verkar første gong. Anten tøm den utdaterte oppføringa med vilje eller gjer oppsettkoden idempotent.

block-local svarar på eit anna spørsmål

Når ein profil sender all trafikk gjennom tunnelen, må klienten avgjere kva som skjer med det lokale nettet. Flagget block-local endrar denne avgjerda ved å rute det lokale LAN-et gjennom tunnelen medan det dokumenterte unntaket for LAN-gatewayen blir halde; dette er eit trafikkpolitisk val som har synlege konsekvensar for tilgjenge.

Det forklarar ikkje kvifor tilføying av ei rute returnerte ein feil om eksisterande oppføring, og å vedta det som ei universell reparasjon skjuler den verkelege konflikten bak ei policyendring. Viss dei lokale ressursane dine sluttar å vere tilgjengelege etter ein profilendra, er dette flagget ein av dei første tinga å undersøkje; viss tilføying av ei rute mislukkast, er det ikkje svaret.

Handsam det som ei avgjerd om kva destinasjonar som blir verande lokale, teken med vilje og skriven ned. Det er ikkje ein brytar å prøve når loggen ser alarmande ut.

Lukk sirkelen: fjern duplikatet ved kjelda

Når du veit kva eigar som held oppføringa, fjernar du den dupliserte instruksen der han er definert. Det kan vere ei route-linje i profilen, eit push frå tenaren eller ein hook som ikkje lenger treng å køyre.

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

Kopla deretter til på nytt og stadfest tre ting: tunnelen kjem opp, den tiltenkte destinasjonen blir løyst til vegen du ønskte, og feilen er borte utan at ein ny dukkar opp i staden. Ein rein logg med feil vald veg er ikkje ei retting.

Viss prefikset tyder det lokale LAN-et på den eine sida og eit eksternt nettverk på den andre, er problemet ei adresseoverlapp og ikkje eit duplikat, og inga mengd sletting vil gjere begge tydingane sanne samstundes. Det tilfellet treng ein annan plan for eitt av dei to nettverka. Bestem kva side som skal omnummererast før du rører nokon av dei.