OpenVPN-i „File exists“ marsruudil ei ole failiprobleem

Alustage sealt, kus sõnum ilmub. Klient ühendub, tunnel tõuseb ja seejärel teatab logi, et Linuxi marsruudi lisamise käsk ebaõnnestus veaga File exists. Miski selles lauses ei viita sertifikaadile, võtmele ega konfiguratsioonifailile, kuigi sõnad seda vihjavad. Kernel kirjeldab oma marsruutide tabelit ja prefiksil, mida palusite installida, on juba kirje.

Järgige kliendi enda järjestust: mida see küsis, mida tabel juba sisaldas, kes selle kirje sinna pani, ja alles siis, mida muuta. Iga samm eemaldab ühe võimaliku omaniku.

Mida klient tegelikult küsis

Enne tõrget logib klient marsruudi, mille ta kavatseb lisada, tavaliselt sihtkoha, võrgumaski, lüüsina ja mõnikord metrikana või tabelina. See rida on taotlus. Järgnev viga on kerneli vastus sellele, ja mõlemat tuleb lugeda kõrvuti.

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

Marsruudiabiprogrammi nullist erinev väljumisstaatus on vähem informatiivne kui selle all olev tekst, sest erinevad kerneli vastused annavad nullist erineva staatuse. Hoidke täpne sõnum alles; erinevus olemasoleva kirje ja kättesaamatu lüüsi vahel otsustab, milline järgmistest jaotistest kehtib.

Lugege olemasolevat marsruuti, mitte ainult aadressi

Tabelist sama punkti eraldatud neliku otsimine ei ole piisav. Marsruudiobjekti määravad aadressipere, tabel, sihtprefiks, meetrika, protokoll ja väljundseade, ning prefiksit jagavad kirjed võivad seaduslikult kõrvuti eksisteerida, kui need atribuudid erinevad. Kokku põrkab terve objekt, mitte 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

Viimane käsk vastab teistsugusele küsimusele kui kaks esimest: mitte see, mis on olemas, vaid see, millise kirje kernel selle sihtkoha jaoks praegu valiks. Mõlemad vaated on kasulikud ja need lahknevad piisavalt sageli, et neid enne järelduste tegemist võrrelda. Nendevaheline lahknevus on huvitav juhtum, mitte ümardamisviga.

Märkige prefiks, tabel, meetrika ja seade ebaõnnestunud taotluse kõrvale. Kui olemasoleval kirjel on samad atribuudid ja sama järgmine hüpe, on teil dubleeritud juhis, mitte marsruutimisprobleem.

Neli omanikku, mis prefiksil võib olla

Ühendatud marsruudid pärinevad määratud aadressist ja süsteem loob need uuesti alati, kui see aadress on olemas. DHCP-klient või ühendusehaldur paigaldab marsruudid oma elutsükli osana. Teine VPN-klient võib sama prefiksit juba kanda. Ja kohalik konks või skript võib lisada sellise, millest miski muu ei tea.

Iga omanik vajab erinevat parandust. Ühendatud marsruut ei ole sinu kustutada; selle eemaldamine võib katkestada kohaliku juurdepääsu enne, kui tunnel on kasutatav, ja kernel paneb selle tagasi. Halduri omanduses olevat marsruuti tuleks muuta selle halduri kaudu, mitte käsitsi ip route del-ga, mille järgmine taasühendamine tühistab.

Säilitatud liides teeb sama segaduse lihtsamaks. Kui tunneliseade jääb taasühendamisele vastu, võivad kohandatud seadistuskoodi paigaldatud marsruudid teisel käivitusel alles olla, nii et puhast olekut eeldav skript ebaõnnestub teisel korral ja töötab esimesel. Kas puhastage vananenud kirje teadlikult või tehke seadistuskood idempotentseks.

block-local vastab teistsugusele küsimusele

Kui profiil saadab kogu liikluse läbi tunneli, peab klient otsustama, mis juhtub kohaliku võrguga. Lipp block-local muudab seda otsust, suunates kohaliku LAN-i läbi tunneli ja jättes alles dokumenteeritud erandi LAN-i lüüsi jaoks; see on liikluspoliitika valik, millel on nähtavad tagajärjed kättesaadavusele.

See ei selgita, miks marsruudi lisamine tagastas olemasoleva kirje vea, ja selle universaalseks paranduseks pidamine peidab tegeliku konflikti poliitikamuudatuse taha. Kui teie kohalikud ressursid muutuvad pärast profiili muutmist kättesaamatuks, on see lipp üks esimesi asju, mida kontrollida; kui marsruudi lisamine ebaõnnestub, ei ole see vastus.

Käsitlege seda otsusena selle kohta, millised sihtkohad jäävad kohalikuks, mis on tehtud teadlikult ja kirja pandud. See ei ole lüliti, mida proovida, kui logi tundub murettekitav.

Sulgege ring: eemaldage duplikaat selle allikast

Kui teate, milline omanik kirjet hoiab, eemaldage dubleeritud juhis sealt, kus see on määratletud. See võib olla profiilis route rida, serverist tulev push või konks, mida ei ole enam vaja käivitada.

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

Seejärel ühenduge uuesti ja kinnitage kolm asja: tunnel tõuseb, kavandatud sihtkoht laheneb soovitud teele ja tõrge on kadunud, ilma et selle asemele ilmuks uus. Puhas logi vale valitud teega ei ole parandus.

Kui prefiks tähendab ühel pool kohalikku LAN-i ja teisel pool kaugvõrku, on probleem aadresside kattumine, mitte duplikaat, ja ükski kustutamine ei muuda mõlemat tähendust korraga tõeseks. See juhtum vajab kahest võrgust ühe jaoks teistsugust plaani. Otsustage, kumb pool ümber nummerdatakse, enne kui kumbagi puudutate.