«File exists» i OpenVPN në një rrugë nuk është problem skedari

Filloni aty ku shfaqet mesazhi. Një klient lidhet, tuneli ngrihet dhe më pas regjistri raporton se komanda e shtimit të rrugës në Linux dështoi me File exists. Asgjë në atë fjali nuk i referohet një certifikate, një çelësi ose një skedari konfigurimi, edhe pse fjalët e sugjerojnë këtë. Kernel-i po përshkruan tabelën e vet të rrugëve, dhe prefiksi që kërkuat të instalohej ka tashmë një hyrje.

Ndiqni sekuencën e vetë klientit: çfarë kërkoi, çfarë përmbante tashmë tabela, kush e vendosi atë hyrje atje dhe vetëm pastaj çfarë duhet ndryshuar. Çdo hap heq një pronar të mundshëm.

Çfarë po kërkonte në të vërtetë klienti

Përpara dështimit klienti regjistron rrugën që synon të shtojë, zakonisht si destinacion, maskë rrjeti, portë dhe ndonjëherë si metrikë ose tabelë. Ajo rresht është kërkesa. Gabimi që vijon është përgjigja e kernelit, dhe të dyja duhet të lexohen krah për krah.

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

Një status daljeje jo zero nga ndihmësi i rrugëve është më pak informativ se teksti poshtë tij, sepse përgjigje të ndryshme të kernelit japin status jo zero. Ruani mesazhin e saktë; dallimi midis një hyrjeje ekzistuese dhe një porte të paarritshme vendos cilat nga seksionet vijuese zbatohen.

Lexoni rrugën ekzistuese, jo vetëm adresën

Kërkimi në tabelë për të njëjtin katërshe me pika nuk mjafton. Objekti i rrugës identifikohet nga familja e adresave, tabela, prefiksi i destinacionit, metrika, protokolli dhe pajisja e daljes, dhe hyrjet që ndajnë një prefiks mund të bashkëjetojnë ligjërisht kur këto atribute ndryshojnë. Përplaset objekti i plotë, jo teksti.

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

Komanda e fundit përgjigjet një pyetjeje të ndryshme nga dy të parat: jo çfarë ekziston, por cilën hyrje kernel-i do të zgjidhte për atë destinacion tani. Të dyja këndvështrimet janë të dobishme, dhe ato ndryshojnë mjaft shpesh sa ia vlen t'i krahasosh përpara se të konkludosh diçka. Mospërputhja midis tyre është rasti interesant, jo një gabim rrumbullakimi.

Shënoni prefiksin, tabelën, metrikën dhe pajisjen pranë kërkesës së dështuar. Nëse hyrja ekzistuese ka të njëjtat atribute dhe të njëjtin hap tjetër, keni një udhëzim të dyfishuar dhe jo një problem rrugëtimi.

Katër pronarë që mund të ketë një prefiks

Rrugët e lidhura vijnë nga një adresë e caktuar dhe sistemi i rikrijon sa herë që ajo adresë ekziston. Një klient DHCP ose një menaxher lidhjesh instalon rrugë si pjesë e ciklit të vet të jetës. Një klient tjetër VPN mund të mbajë tashmë të njëjtin prefiks. Dhe një grep ose skript lokal mund të shtojë një që asgjë tjetër nuk e di.

Çdo pronar kërkon një korrigjim tjetër. Një rrugë e lidhur nuk është e juaja për ta fshirë; heqja e saj mund të prishë aksesin lokal përpara se tuneli të jetë i përdorshëm, dhe kernel-i do ta kthejë. Një rrugë në pronësi të menaxherit duhet ndryshuar përmes atij menaxheri, jo me një ip route del manual që lidhja tjetër e anulon.

Një ndërfaqe e mbajtur e bën të njëjtën konfuzion më të lehtë. Kur pajisja e tunelit mbijeton një rilidhje, rrugët e instaluara nga kodi i konfigurimit të personalizuar mund të jenë ende të pranishme në ekzekutimin e dytë, kështu që një skript që supozon gjendje të pastër dështon herën e dytë dhe funksionon herën e parë. Ose pastroni qëllimisht hyrjen e vjetruar ose bëni kodin e konfigurimit idempotent.

block-local përgjigjet një pyetjeje tjetër

Kur një profil dërgon të gjithë trafikun përmes tunelit, klienti duhet të vendosë çfarë ndodh me rrjetin lokal. Flamuri block-local e ndryshon atë vendim duke e drejtuar LAN-in lokal përmes tunelit, ndërsa ruan përjashtimin e dokumentuar për portën e LAN; ky është një zgjedhje e politikës së trafikut me pasoja të dukshme për arritshmërinë.

Nuk shpjegon pse shtimi i një rrugë ktheu një gabim hyrjeje ekzistuese, dhe adoptimi i tij si riparim universal fsheh konfliktin e vërtetë pas një ndryshimi politike. Nëse burimet tuaja lokale bëhen të paarritshme pas redaktimit të një profili, ky flamur është një nga gjërat e para për të kontrolluar; nëse shtimi i një rrugë dështon, nuk është përgjigjja.

Trajtojeni si një vendim për atë se cilat destinacione mbeten lokale, marrë qëllimisht dhe shkruar. Nuk është një çelës për ta provuar kur regjistri duket alarmant.

Mbyllni ciklin: hiqni dublikatën në burimin e saj

Pasi të dini cili pronar e mban hyrjen, hiqni udhëzimin e dyfishuar aty ku është përcaktuar. Mund të jetë një rresht route në profil, një push nga serveri ose një grep që nuk ka më nevojë të ekzekutohet.

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

Më pas rilidhuni dhe konfirmoni tre gjëra: tuneli ngrihet, destinacioni i synuar zgjidhet në shtegun që dëshironit, dhe dështimi zhduket pa u shfaqur një i ri në vendin e tij. Një regjistër i pastër me një shteg të zgjedhur gabimisht nuk është riparim.

Nëse prefiksi nënkupton LAN-in lokal nga njëra anë dhe një rrjet të largët nga ana tjetër, problemi është mbivendosje adresash dhe jo dublikatë, dhe asnjë fshirje nuk do t'i bëjë të dyja kuptimet të vërteta njëkohësisht. Ai rast kërkon një plan tjetër për një nga dy rrjetet. Vendosni cila anë do të rinumërohet përpara se të prekni ndonjërën.