OpenVPNs "File exists" på en rute er ikke et filproblem

Begynd der, hvor beskeden vises. En klient opretter forbindelse, tunnelen kommer op, og derefter rapporterer loggen, at Linux-kommandoen til at tilføje ruten mislykkedes med File exists. Intet i den sætning henviser til et certifikat, en nøgle eller en konfigurationsfil, selv om ordene antyder det. Kernen beskriver sin rutetabel, og det præfiks, du bad om at installere, har allerede en post.

Følg klientens egen rækkefølge: hvad den bad om, hvad tabellen allerede indeholdt, hvem der placerede den post der, og først derefter hvad der skal ændres. Hvert trin fjerner én mulig ejer.

Hvad klienten faktisk bad om

Før fejlen logger klienten den rute, den agter at tilføje, normalt som en destination, en netmaske, en gateway og nogle gange en metrik eller tabel. Den linje er anmodningen. Fejlen, der følger, er kernens svar på den, og de to bør læses 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-nul-exitstatus fra rutehjælperen er mindre oplysende end teksten under den, fordi forskellige kernesvar giver en ikke-nul-status. Behold den præcise besked; forskellen mellem en eksisterende post og en uopnåelig gateway afgør, hvilke af de næste afsnit der gælder.

Læs den eksisterende rute, ikke kun adressen

Det er ikke nok at søge i tabellen efter den samme prikkede kvadruppel. Et ruteobjekt identificeres ved sin adressefamilie, tabel, destinationspræfiks, metrik, protokol og outputenhed, og poster, der deler et præfiks, kan lovligt eksistere side om side, når disse attributter er forskellige. Det er hele objektet, der 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 sidste kommando besvarer et andet spørgsmål end de to første: ikke hvad der findes, men hvilken post kernen ville vælge til den destination lige nu. Begge visninger er nyttige, og de er uenige ofte nok til at være værd at sammenligne, før du konkluderer noget. Uoverensstemmelsen mellem dem er det interessante tilfælde, ikke en afrundingsfejl.

Notér præfikset, tabellen, metrikken og enheden ved siden af den mislykkede anmodning. Hvis den eksisterende post har de samme attributter og det samme næste hop, har du en duplikeret instruktion og ikke et ruteproblem.

Fire ejere et præfiks kan have

Forbundne ruter kommer fra en tildelt adresse og genskabes af systemet, hver gang den adresse findes. En DHCP-klient eller en forbindelsesmanager installerer ruter som en del af sin egen livscyklus. En anden VPN-klient bærer måske allerede det samme præfiks. Og et lokalt hook eller script kan tilføje en, som intet andet kender.

Hver ejer kræver en anden rettelse. En forbundet rute er ikke din at slette; at fjerne den kan bryde lokal adgang, før tunnelen er brugbar, og kernen sætter den tilbage. En rute, der ejes af en manager, bør ændres gennem den manager, ikke med en manuel ip route del, som den næste genopkobling fortryder.

En bibeholdt grænseflade gør den samme forvirring lettere. Når tunneleenheden overlever en genopkobling, kan ruter installeret af tilpasset opsætningskode stadig være til stede ved anden kørsel, så et script, der antager en ren tilstand, fejler anden gang og virker første gang. Ryd enten den forældede post bevidst, eller gør opsætningskoden idempotent.

block-local besvarer et andet spørgsmål

Når en profil sender al trafik gennem tunnelen, skal klienten beslutte, hvad der sker med det lokale netværk. Flaget block-local ændrer den beslutning ved at rute det lokale LAN gennem tunnelen og samtidig bevare den dokumenterede undtagelse for LAN-gatewayen; det er et trafikpolitisk valg med synlige konsekvenser for tilgængeligheden.

Det forklarer ikke, hvorfor tilføjelsen af en rute returnerede en fejl om en eksisterende post, og at vedtage det som en universel reparation skjuler den faktiske konflikt bag en politisk ændring. Hvis dine lokale ressourcer holder op med at være tilgængelige efter en profilredigering, er dette flag en af de første ting at undersøge; hvis tilføjelsen af en rute mislykkes, er det ikke svaret.

Betragt det som en beslutning om, hvilke destinationer der forbliver lokale, truffet bevidst og skrevet ned. Det er ikke en kontakt, man prøver, når loggen ser alarmerende ud.

Luk cirklen: fjern dubletten ved dens kilde

Når du ved, hvilken ejer der holder posten, skal du fjerne den duplikerede instruktion, hvor den er defineret. Det kan være en route-linje i profilen, et push fra serveren eller et hook, der ikke længere behøver at kø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

Genopkobl derefter og bekræft tre ting: tunnelen kommer op, den tilsigtede destination opløses til den vej, du ønskede, og fejlen er væk, uden at en ny dukker op i dens sted. En ren log med en forkert valgt vej er ikke en rettelse.

Hvis præfikset betyder det lokale LAN på den ene side og et fjernnetværk på den anden, er problemet et adresseoverlap snarere end en dublet, og ingen mængde sletning vil gøre begge betydninger sande på én gang. Det tilfælde kræver en anden plan for et af de to netværk. Beslut, hvilken side der skal omnummereres, før du rører nogen af dem.