Az OpenVPN „File exists” üzenete egy útvonalon nem fájlprobléma
Az üzenet a kernel útvonaltáblájából származik, nem a fájlrendszerből. Olvassa el a bejegyzést, amely már birtokolja az előtagot, mielőtt módosítja a LAN-szabályzatot.
Kezdje ott, ahol az üzenet megjelenik. Egy kliens csatlakozik, az alagút feljön, majd a napló jelzi, hogy a Linux útvonal-hozzáadó parancsa File exists hibával meghiúsult. Ebben a mondatban semmi nem utal tanúsítványra, kulcsra vagy konfigurációs fájlra, bár a szavak ezt sugallják. A kernel az útvonaltábláját írja le, és az előtagnak, amelyet telepíteni kért, már van bejegyzése.
Kövesse a kliens saját sorrendjét: mit kért, mit tartalmazott már a tábla, ki helyezte oda azt a bejegyzést, és csak ezután, mit kell megváltoztatni. Minden lépés egy lehetséges tulajdonost távolít el.
Mit kért valójában a kliens
A hiba előtt a kliens naplózza az útvonalat, amelyet hozzá kíván adni, általában célként, hálózati maszkként, átjáróként és néha metrikaként vagy táblaként. Az a sor a kérés. Az ezt követő hiba a kernel válasza rá, és a kettőt egymás mellett kell olvasni.
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
Az útvonal-segéd nem nulla kilépési állapota kevésbé informatív, mint az alatta lévő szöveg, mert különböző kernelválaszok nem nulla állapotot eredményeznek. Őrizze meg a pontos üzenetet; a meglévő bejegyzés és az elérhetetlen átjáró közötti különbség dönti el, melyik következő szakasz érvényes.
Olvassa el a meglévő útvonalat, ne csak a címet
Nem elég ugyanazt a pontozott négyest keresni a táblában. Egy útvonalobjektumot a címcsaládja, táblája, cél-előtagja, metrikája, protokollja és kimeneti eszköze azonosít, és az előtagot megosztó bejegyzések jogszerűen létezhetnek egymás mellett, ha ezek az attribútumok eltérnek. Az egész objektum ütközik, nem a szöveg.
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
Az utolsó parancs más kérdésre válaszol, mint az első kettő: nem arra, mi létezik, hanem arra, melyik bejegyzést választaná a kernel ehhez a célhoz most. Mindkét nézet hasznos, és elég gyakran eltérnek ahhoz, hogy érdemes legyen összevetni őket, mielőtt bármit megállapít. A köztük lévő eltérés az érdekes eset, nem kerekítési hiba.
Jegyezze fel az előtagot, a táblát, a metrikát és az eszközt a sikertelen kérés mellé. Ha a meglévő bejegyzésnek ugyanazok az attribútumai és ugyanaz a következő ugrása, duplikált utasítása van, nem útvonalproblémája.
Négy tulajdonos, amely egy előtagé lehet
A kapcsolt útvonalak egy hozzárendelt címből származnak, és a rendszer újra létrehozza őket, amikor csak ez a cím létezik. Egy DHCP-kliens vagy kapcsolatkezelő a saját életciklusa részeként telepít útvonalakat. Egy másik VPN-kliens már hordozhatja ugyanazt az előtagot. És egy helyi hook vagy szkript hozzáadhat egyet, amelyről semmi más nem tud.
Minden tulajdonos más javítást igényel. A kapcsolt útvonal nem az öné törlésre; eltávolítása megszakíthatja a helyi hozzáférést, mielőtt az alagút használható lenne, és a kernel visszateszi. A kezelő tulajdonában lévő útvonalat azon a kezelőn keresztül kell módosítani, nem egy kézi ip route del-mal, amelyet a következő újracsatlakozás visszavon.
A megtartott interfész ugyanezt a zavart könnyíti meg. Amikor az alagút-eszköz túlél egy újracsatlakozást, az egyedi telepítőkód által telepített útvonalak a második futásban is jelen lehetnek, így a tiszta állapotot feltételező szkript másodszor meghiúsul, elsőre működik. Vagy tudatosan törölje az elavult bejegyzést, vagy tegye idempotenssé a telepítőkódot.
A block-local más kérdésre válaszol
Amikor egy profil az összes forgalmat az alagúton küldi, a kliensnek el kell döntenie, mi történik a helyi hálózattal. A block-local jelző ezt a döntést úgy változtatja meg, hogy a helyi LAN-t az alagúton keresztül irányítja, miközben megtartja a LAN átjárójára vonatkozó dokumentált kivételt; ez forgalmi szabályzati választás, látható következményekkel az elérhetőségre.
Nem magyarázza meg, miért adott vissza az útvonal hozzáadása meglévő bejegyzésre vonatkozó hibát, és egyetemes javításként elfogadva elrejti a tényleges konfliktust egy szabályzatváltozás mögé. Ha a helyi erőforrásai egy profil szerkesztése után elérhetetlenné válnak, ez a jelző az elsőként vizsgálandók egyike; ha az útvonal hozzáadása meghiúsul, nem ez a válasz.
Tekintse döntésnek arról, mely célok maradnak helyiek, amelyet szándékosan hoztak és írtak le. Ez nem egy kipróbálandó kapcsoló, amikor a napló riasztónak tűnik.
Zárja be a hurkot: távolítsa el a duplikátumot a forrásánál
Miután tudja, melyik tulajdonos tartja a bejegyzést, távolítsa el a duplikált utasítást ott, ahol definiálták. Ez lehet egy route sor a profilban, egy push a szerverről vagy egy hook, amelynek már nem kell futnia.
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
Ezután csatlakozzon újra, és erősítse meg három dolgot: az alagút feljön, a szándékolt cél a kívánt útvonalra oldódik fel, és a hiba eltűnik anélkül, hogy új jelenne meg a helyén. A tiszta napló rosszul választott útvonallal nem javítás.
Ha az előtag az egyik oldalon a helyi LAN-t, a másikon egy távoli hálózatot jelent, a probléma címátfedés, nem duplikátum, és semmilyen törlés nem teszi mindkét jelentést egyszerre igazzá. Ez az eset más tervet igényel a két hálózat egyikéhez. Döntse el, melyik oldalt számozzák újra, mielőtt bármelyikhez hozzányúlna.