OpenVPN se "File exists" op 'n roete is nie 'n lêerprobleem nie

Begin by die plek waar die boodskap verskyn. 'n Kliënt maak verbinding, die tonnel kom op, en dan berig die log dat die Linux-roete-byvoegopdrag met File exists misluk het. Niks in daardie sin verwys na 'n sertifikaat, 'n sleutel of 'n konfigurasielêer nie, al suggereer die woorde dit. Die kernel beskryf sy roetetabel, en die voorvoegsel wat jy gevra het om te installeer, het reeds 'n inskrywing.

Volg die kliënt se eie volgorde: waarvoor dit gevra het, wat die tabel reeds bevat het, wie daardie inskrywing daar gesit het, en eers daarna wat om te verander. Elke stap verwyder een moontlike eienaar.

Waarvoor die kliënt eintlik gevra het

Voor die mislukking teken die kliënt die roete aan wat dit wil byvoeg, gewoonlik as 'n bestemming, 'n netmasker, 'n gateway en soms 'n metrieke waarde of tabel. Daardie reël is die versoek. Die fout wat volg, is die kernel se antwoord daarop, en die twee hoort langs mekaar wanneer jy die log lees.

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

'n Nie-nul-uitgangstatus van die roete-hulpprogram is minder insiggewend as die teks daaronder, want verskillende kernel-reaksies lewer 'n nie-nul-status. Hou die presiese boodskap; die onderskeid tussen 'n bestaande inskrywing en 'n onbereikbare gateway bepaal watter van die volgende afdelings van toepassing is.

Lees die bestaande roete, nie net die adres nie

Dit is nie genoeg om die tabel vir dieselfde vierdubbele punt te deursoek nie. 'n Roete-objek word geïdentifiseer deur sy adresfamilie, tabel, bestemmingsvoorvoegsel, metrieke waarde, protokol en uitvoertoestel, en inskrywings wat 'n voorvoegsel deel, kan wettig saam bestaan wanneer daardie eienskappe verskil. Wat bots, is die hele objek, nie die teks nie.

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

Die laaste opdrag beantwoord 'n ander vraag as die eerste twee: nie wat bestaan nie, maar watter inskrywing die kernel op die oomblik vir daardie bestemming sou kies. Albei sienings is nuttig, en hulle stem dikwels genoeg nie ooreen om dit te vergelyk voordat jy enige gevolgtrekking maak. 'n Wanverhouding tussen hulle is die interessante geval, nie 'n afrondingsfout nie.

Teken die voorvoegsel, die tabel, die metrieke waarde en die toestel langs die mislukte versoek aan. As die bestaande inskrywing dieselfde eienskappe en dieselfde volgende sprong het, het jy 'n duplikaatopdrag eerder as 'n roeteprobleem.

Vier eienaars wat 'n voorvoegsel kan hê

Gekoppelde roetes kom van 'n toegewysde adres en word deur die stelsel herskep wanneer daardie adres bestaan. 'n DHCP-kliënt of 'n verbindingsbestuurder installeer roetes as deel van sy eie lewensiklus. 'n Ander VPN-kliënt dra dalk reeds dieselfde voorvoegsel. En 'n plaaslike haak of script kan een byvoeg waarvan niks anders weet nie.

Elke eienaar het 'n ander regstelling nodig. 'n Gekoppelde roete is nie joune om te verwyder nie; dit kan plaaslike toegang breek voordat die tonnel bruikbaar is, en die kernel sal dit terugplaas. 'n Roete wat deur 'n bestuurder besit word, moet deur daardie bestuurder verander word, nie met 'n handmatige ip route del wat die volgende herverbinding ongedaan maak nie.

'n Behoute koppelvlak maak dieselfde verwarring makliker. Wanneer die tonneltoestel 'n herverbinding oorleef, kan roetes wat deur pasgemaakte opstelkode geïnstalleer is, steeds op die tweede lopie teenwoordig wees, so 'n script wat 'n skoon bladsy aanvaar, misluk die tweede keer en werk die eerste keer. Maak die verouderde inskrywing doelbewus skoon of maak die opstelkode idempotent.

block-local beantwoord 'n ander vraag

Wanneer 'n profiel alle verkeer deur die tonnel stuur, moet die kliënt besluit wat met die plaaslike netwerk gebeur. Die block-local-vlag verander daardie besluit deur die plaaslike LAN deur die tonnel te lei terwyl die gedokumenteerde uitsondering vir die LAN-gateway behou word, wat 'n verkeersbeleidkeuse is met sigbare gevolge vir bereikbaarheid.

Dit verduidelik nie waarom 'n roete-byvoeging 'n bestaande-inskrywing-fout opgelewer het nie, en om dit as 'n universele herstelling aan te neem, verberg die werklike konflik agter 'n beleidsverandering. As jou plaaslike hulpbronne ná 'n profielwysiging onbereikbaar raak, is hierdie vlag een van die eerste dinge om na te gaan; as 'n roete-byvoeging misluk, is dit nie die antwoord nie.

Behandel dit as 'n besluit oor watter bestemmings plaaslik bly, doelbewus geneem en neergeskryf. Dit is nie 'n skakelaar om te probeer wanneer die log alarms maak nie.

Maak die kring toe: verwyder die duplikaat by sy bron

Sodra jy weet watter eienaar die inskrywing hou, verwyder die duplikaatopdrag waar dit gedefinieer is. Dit kan 'n route-reël in die profiel wees, 'n stoot van die bediener af, of 'n haak wat nie meer hoef te loop nie.

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 dan weer en bevestig drie dinge: die tonnel kom op, die beoogde bestemming los op na die pad wat jy wou hê, en die fout is weg sonder dat 'n nuwe een in sy plek verskyn. 'n Skoon log met 'n verkeerde gekose pad is nie 'n regstelling nie.

As die voorvoegsel die plaaslike LAN aan die een kant en 'n afgeleë netwerk aan die ander kant beteken, is die probleem 'n adresoorvleueling eerder as 'n duplikaat, en geen hoeveelheid skrapping sal albei betekenisse gelyktydig waar maak nie. Daardie geval verg 'n ander plan vir een van die twee netwerke. Besluit watter kant hernommer gaan word voordat jy enige een aanraak.