«File exists» de OpenVPN sur itinero ne estas dosiera problemo

Komencu tie, kie la mesaĝo aperas. Kliento konektiĝas, la tunelo ekfunkcias, kaj poste la protokolo raportas, ke la Linux-komando por aldoni itineron malsukcesis kun File exists. Nenio en tiu frazo rilatas al atestilo, ŝlosilo aŭ agorda dosiero, kvankam la vortoj sugestas tion. La kerno priskribas sian itineran tabelon, kaj la prefikso, kiun vi petis instali, jam havas eron.

Sekvu la propran sinsekvon de la kliento: kion ĝi petis, kion la tabelo jam enhavis, kiu metis tiun eron tien, kaj nur poste kion ŝanĝi. Ĉiu paŝo forigas unu eblan posedanton.

Kion la kliento efektive petis

Antaŭ la malsukceso la kliento registras la itineron, kiun ĝi intencas aldoni, kutime kiel celon, retan maskon, enirejon kaj foje kiel metrikon aŭ tabelon. Tiu linio estas la peto. La sekva eraro estas la respondo de la kerno al ĝi, kaj ambaŭ legiĝu unu apud la alia.

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

Ne-nula elira stato de la itinera helpilo estas malpli informa ol la teksto sub ĝi, ĉar diversaj kernaj respondoj produktas ne-nulan staton. Konservu la precizan mesaĝon; la distingo inter ekzistanta ero kaj neatingebla enirejo decidas, kiu el la sekvaj sekcioj validas.

Legu la ekzistantan itineron, ne nur la adreson

Serĉi en la tabelo la saman punktitan kvadruplon ne sufiĉas. Itinera objekto identiĝas per sia adresfamilio, tabelo, cella prefikso, metriko, protokolo kaj eliga aparato, kaj eroj, kiuj dividas prefikson, povas laŭleĝe kunekzisti, kiam tiuj atributoj malsamas. Kolizias la tuta objekto, ne la teksto.

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

La lasta komando respondas al alia demando ol la du unuaj: ne kio ekzistas, sed kiun eron la kerno elektus por tiu celo ĝuste nun. Ambaŭ vidoj utilas, kaj ili malkonsentas sufiĉe ofte por esti komparindaj antaŭ ol vi konkludos ion. La malkongruo inter ili estas la interesa kazo, ne rondiga eraro.

Notu la prefikson, la tabelon, la metrikon kaj la aparaton apud la malsukcesa peto. Se la ekzistanta ero havas la samajn atributojn kaj la saman sekvan salteton, vi havas duobligitan instrukciadon, ne itineran problemon.

Kvar posedantoj, kiujn prefikso povas havi

Konektitaj itineroj venas de atribuita adreso kaj estas rekreataj de la sistemo ĉiam, kiam tiu adreso ekzistas. DHCP-kliento aŭ konekta administrilo instalas itinerojn kiel parton de sia propra vivociklo. Alia VPN-kliento eble jam portas la saman prefikson. Kaj loka hoko aŭ skripto povas aldoni unu, pri kiu nenio alia scias.

Ĉiu posedanto bezonas alian korekton. Konektita itinero ne estas via por forigi; forigi ĝin povas rompi lokan aliron antaŭ ol la tunelo estas uzebla, kaj la kerno remetos ĝin. Itineron posedatan de administrilo oni ŝanĝu tra tiu administrilo, ne per mana ip route del, kiun la sekva rekonekto nuligos.

Retenita interfaco faciligas la saman konfuzon. Kiam la tunela aparato postvivas rekonekton, itineroj instalitaj de propra agorda kodo povas ankoraŭ ĉeesti en la dua rulo, do skripto, kiu supozas puran staton, malsukcesas la duan fojon kaj funkcias la unuan. Aŭ intence forigu la malnoviĝintan eron, aŭ faru la agordan kodon idempota.

block-local respondas al alia demando

Kiam profilo sendas la tutan trafikon tra la tunelo, la kliento devas decidi, kio okazas al la loka reto. La flago block-local ŝanĝas tiun decidon per enkursigo de la loka LAN tra la tunelo, samtempe konservante la dokumentitan escepton por la LAN-enirejo; tio estas trafika politika elekto kun videblaj sekvoj por atingeblo.

Ĝi ne klarigas, kial aldono de itinero redonis eraron pri ekzistanta ero, kaj adopti ĝin kiel universalan riparon kaŝas la faktan konflikton malantaŭ politika ŝanĝo. Se viaj lokaj resursoj fariĝas neatingeblaj post redakto de profilo, ĉi tiu flago estas unu el la unuaj aferoj kontrolendaj; se aldono de itinero malsukcesas, ĝi ne estas la respondo.

Traktu ĝin kiel decidon pri tio, kiuj celoj restas lokaj, faritan intence kaj notitan. Ĝi ne estas ŝaltilo por provi, kiam la protokolo aspektas alarme.

Fermu la cirklon: forigu la duoblaĵon ĉe ĝia fonto

Post kiam vi scias, kiu posedanto tenas la eron, forigu la duobligitan instrukciadon tie, kie ĝi estas difinita. Tio povas esti route-linio en la profilo, puŝo de la servilo, aŭ hoko, kiu ne plu bezonas funkcii.

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

Poste rekonektu kaj konfirmu tri aferojn: la tunelo ekfunkcias, la celata celloko solviĝas al la vojo, kiun vi volis, kaj la malsukceso malaperis sen ke nova aperu en ĝia loko. Pura protokolo kun malĝuste elektita vojo ne estas riparo.

Se la prefikso signifas la lokan LAN unuflanke kaj malproksiman reton aliflanke, la problemo estas adresa interkovro, ne duoblaĵo, kaj nenia forigo igos ambaŭ signifojn samtempe veraj. Tiu kazo bezonas alian planon por unu el la du retoj. Decidu, kiu flanko estos renumerita, antaŭ ol tuŝi iun ajn.