Mesajul „File exists” al OpenVPN pe o rută nu este o problemă de fișier

Începeți acolo unde apare mesajul. Un client se conectează, tunelul urcă, apoi jurnalul raportează că comanda de adăugare a rutei din Linux a eșuat cu File exists. Nimic din acea propoziție nu se referă la un certificat, o cheie sau un fișier de configurare, deși cuvintele sugerează asta. Nucleul își descrie tabela de rute, iar prefixul pe care l-ați cerut instalat are deja o intrare.

Urmați secvența clientului însuși: ce a cerut, ce conținea deja tabela, cine a plasat acea intrare acolo și abia apoi ce trebuie schimbat. Fiecare pas elimină un posibil proprietar.

Ce cerea de fapt clientul

Înainte de eșec, clientul înregistrează ruta pe care intenționează să o adauge, de obicei ca destinație, mască de rețea, gateway și uneori ca metrică sau tabel. Acea linie este cererea. Eroarea care urmează este răspunsul nucleului, iar cele două trebuie citite alături.

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

Un cod de ieșire diferit de zero al ajutorului de rute este mai puțin informativ decât textul de sub el, pentru că răspunsuri diferite ale nucleului produc un cod diferit de zero. Păstrați mesajul exact; distincția dintre o intrare existentă și un gateway inaccesibil decide care dintre secțiunile următoare se aplică.

Citiți ruta existentă, nu doar adresa

Căutarea în tabel a aceluiași cvadruplu punctat nu este suficientă. Un obiect rută este identificat prin familia de adrese, tabel, prefixul destinației, metrică, protocol și dispozitivul de ieșire, iar intrările care împart un prefix pot coexista legitim atunci când acele atribute diferă. Ceea ce se ciocnește este obiectul întreg, nu textul.

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

Ultima comandă răspunde la o întrebare diferită de primele două: nu ce există, ci ce intrare ar alege nucleul pentru acea destinație acum. Ambele perspective sunt utile și diferă suficient de des încât merită comparate înainte de a concluziona ceva. Neconcordanța dintre ele este cazul interesant, nu o eroare de rotunjire.

Notați prefixul, tabela, metrica și dispozitivul lângă cererea eșuată. Dacă intrarea existentă are aceleași atribute și același salt următor, aveți o instrucțiune duplicată, nu o problemă de rutare.

Patru proprietari pe care îi poate avea un prefix

Rutele conectate provin dintr-o adresă atribuită și sunt recreate de sistem ori de câte ori acea adresă există. Un client DHCP sau un manager de conexiuni instalează rute ca parte a propriului ciclu de viață. Un alt client VPN poate transporta deja același prefix. Iar un hook sau un script local poate adăuga una pe care nimic altceva nu o știe.

Fiecare proprietar necesită o corecție diferită. O rută conectată nu este a dumneavoastră pentru ștergere; eliminarea ei poate întrerupe accesul local înainte ca tunelul să fie utilizabil, iar nucleul o va pune la loc. O rută deținută de un manager trebuie schimbată prin acel manager, nu cu un ip route del manual pe care următoarea reconectare îl anulează.

O interfață păstrată face aceeași confuzie mai ușoară. Când dispozitivul tunelului supraviețuiește unei reconectări, rutele instalate de codul de configurare personalizat pot fi încă prezente la a doua rulare, astfel încât un script care presupune o stare curată eșuează a doua oară și funcționează prima dată. Fie ștergeți deliberat intrarea învechită, fie faceți codul de configurare idempotent.

block-local răspunde la o altă întrebare

Când un profil trimite tot traficul prin tunel, clientul trebuie să decidă ce se întâmplă cu rețeaua locală. Indicatorul block-local schimbă această decizie rutând LAN-ul local prin tunel, păstrând excepția documentată pentru gateway-ul LAN; este o alegere de politică a traficului cu consecințe vizibile asupra accesibilității.

Nu explică de ce adăugarea unei rute a returnat o eroare de intrare existentă, iar adoptarea ei ca reparație universală ascunde conflictul real în spatele unei schimbări de politică. Dacă resursele dumneavoastră locale devin inaccesibile după editarea unui profil, acest indicator este unul dintre primele lucruri de verificat; dacă adăugarea unei rute eșuează, nu este răspunsul.

Tratați-l ca pe o decizie privind destinațiile care rămân locale, luată deliberat și consemnată. Nu este un comutator de încercat când jurnalul pare alarmant.

Închideți bucla: eliminați duplicatul la sursa lui

Odată ce știți ce proprietar deține intrarea, eliminați instrucțiunea duplicată acolo unde este definită. Poate fi o linie route în profil, un push de la server sau un hook care nu mai trebuie rulat.

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

Apoi reconectați-vă și confirmați trei lucruri: tunelul urcă, destinația dorită se rezolvă pe calea pe care o voiați, iar eșecul dispare fără să apară altul în locul lui. Un jurnal curat cu o cale aleasă greșit nu este o corecție.

Dacă prefixul înseamnă LAN-ul local pe o parte și o rețea îndepărtată pe cealaltă, problema este o suprapunere de adrese, nu un duplicat, iar nicio ștergere nu va face ambele semnificații adevărate simultan. Acel caz necesită un plan diferit pentru una dintre cele două rețele. Decideți care parte va fi renumerotată înainte de a atinge vreuna.