OpenVPN's "File exists" op een route is geen bestandsprobleem

Begin waar het bericht verschijnt. Een client verbindt, de tunnel komt op, en dan meldt het log dat de Linux-opdracht om de route toe te voegen is mislukt met File exists. Niets in die zin verwijst naar een certificaat, een sleutel of een configuratiebestand, ook al suggereren de woorden dat. De kernel beschrijft zijn routetabel, en het prefix dat u wilde installeren heeft al een vermelding.

Volg de eigen volgorde van de client: wat hij vroeg, wat de tabel al bevatte, wie die vermelding daar heeft geplaatst, en pas daarna wat er moet veranderen. Elke stap verwijdert één mogelijke eigenaar.

Wat de client werkelijk vroeg

Vóór de fout logt de client de route die hij wil toevoegen, meestal als bestemming, netmasker, gateway en soms als metriek of tabel. Die regel is het verzoek. De fout die volgt is het antwoord van de kernel, en beide moeten naast elkaar worden gelezen.

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

Een niet-nul exitstatus van de routehulp is minder informatief dan de tekst eronder, omdat verschillende kernelreacties een niet-nul status opleveren. Bewaar het exacte bericht; het onderscheid tussen een bestaande vermelding en een onbereikbare gateway bepaalt welke van de volgende secties geldt.

Lees de bestaande route, niet alleen het adres

In de tabel zoeken naar hetzelfde gestippelde viertal is niet genoeg. Een routeobject wordt geïdentificeerd door zijn adresfamilie, tabel, bestemmingsprefix, metriek, protocol en uitvoerapparaat, en vermeldingen die een prefix delen kunnen legaal naast elkaar bestaan wanneer die kenmerken verschillen. Wat botst is het hele object, niet de tekst.

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

De laatste opdracht beantwoordt een andere vraag dan de eerste twee: niet wat bestaat, maar welke vermelding de kernel nu voor die bestemming zou kiezen. Beide weergaven zijn nuttig, en ze verschillen vaak genoeg om ze te vergelijken voordat u iets concludeert. De mismatch ertussen is het interessante geval, geen afrondingsfout.

Noteer het prefix, de tabel, de metriek en het apparaat naast het mislukte verzoek. Als de bestaande vermelding dezelfde kenmerken en dezelfde volgende hop heeft, hebt u een dubbele instructie en geen routingprobleem.

Vier eigenaren die een prefix kan hebben

Verbonden routes komen van een toegewezen adres en worden door het systeem opnieuw aangemaakt wanneer dat adres bestaat. Een DHCP-client of een verbindingsbeheerder installeert routes als onderdeel van zijn eigen levenscyclus. Een andere VPN-client draagt mogelijk al hetzelfde prefix. En een lokale hook of script kan er een toevoegen waar niets anders van weet.

Elke eigenaar vereist een andere correctie. Een verbonden route is niet van u om te verwijderen; verwijderen kan lokale toegang breken voordat de tunnel bruikbaar is, en de kernel zet hem terug. Een route van een beheerder moet via die beheerder worden gewijzigd, niet met een handmatige ip route del die de volgende herverbinding ongedaan maakt.

Een behouden interface maakt dezelfde verwarring makkelijker. Wanneer het tunnelapparaat een herverbinding overleeft, kunnen routes die door aangepaste setupcode zijn geïnstalleerd bij de tweede run nog aanwezig zijn, waardoor een script dat een schone toestand aanneemt de tweede keer faalt en de eerste keer werkt. Maak de verouderde vermelding bewust schoon of maak de setupcode idempotent.

block-local beantwoordt een andere vraag

Wanneer een profiel al het verkeer door de tunnel stuurt, moet de client beslissen wat er met het lokale netwerk gebeurt. De vlag block-local verandert die beslissing door het lokale LAN door de tunnel te routeren terwijl de gedocumenteerde uitzondering voor de LAN-gateway behouden blijft; dat is een verkeersbeleidskeuze met zichtbare gevolgen voor bereikbaarheid.

Het verklaart niet waarom het toevoegen van een route een fout over een bestaande vermelding teruggaf, en het als universele reparatie aannemen verbergt het werkelijke conflict achter een beleidswijziging. Als uw lokale bronnen na een profielbewerking onbereikbaar worden, is deze vlag een van de eerste dingen om te controleren; als het toevoegen van een route mislukt, is het niet het antwoord.

Behandel het als een beslissing over welke bestemmingen lokaal blijven, bewust genomen en opgeschreven. Het is geen schakelaar om te proberen wanneer het log alarmerend lijkt.

Sluit de lus: verwijder het duplicaat bij de bron

Zodra u weet welke eigenaar de vermelding heeft, verwijdert u de dubbele instructie waar die is gedefinieerd. Dat kan een route-regel in het profiel zijn, een push van de server of een hook die niet meer hoeft te draaien.

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

Verbind daarna opnieuw en bevestig drie dingen: de tunnel komt op, de beoogde bestemming wordt opgelost naar het pad dat u wilde, en de fout is weg zonder dat er een nieuwe voor in de plaats komt. Een schoon log met een verkeerd gekozen pad is geen oplossing.

Als het prefix aan de ene kant het lokale LAN betekent en aan de andere kant een extern netwerk, is het probleem een adresoverlap en geen duplicaat, en geen enkele verwijdering maakt beide betekenissen tegelijk waar. Dat geval vraagt een ander plan voor een van de twee netwerken. Bepaal welke kant opnieuw wordt genummerd voordat u een van beide aanraakt.