OpenVPN „File exists“ maršrute nėra failo problema
Pranešimas ateina iš branduolio maršrutų lentelės, o ne iš failų sistemos. Perskaitykite įrašą, kuris jau valdo prefiksą, prieš keisdami LAN politiką.
Pradėkite ten, kur pasirodo pranešimas. Klientas prisijungia, tunelis pakyla, tada žurnalas praneša, kad Linux maršruto pridėjimo komanda nepavyko su File exists. Nė vienas to sakinio žodis nenurodo sertifikato, rakto ar konfigūracijos failo, nors žodžiai tai sufleruoja. Branduolys aprašo savo maršrutų lentelę, o prefiksas, kurį paprašėte įdiegti, jau turi įrašą.
Sekite paties kliento seką: ko jis paprašė, ką lentelė jau turėjo, kas ten įdėjo tą įrašą, ir tik tada, ką keisti. Kiekvienas žingsnis pašalina vieną galimą savininką.
Ko klientas iš tikrųjų prašė
Prieš nesėkmę klientas įrašo maršrutą, kurį ketina pridėti, paprastai kaip paskirties vietą, tinklo kaukę, šliuzą ir kartais kaip metriką ar lentelę. Ta eilutė yra užklausa. Po jos einanti klaida yra branduolio atsakymas, ir abu reikia skaityti greta.
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
Maršruto pagalbinės programos nenulinis išėjimo statusas yra mažiau informatyvus nei tekstas po juo, nes skirtingi branduolio atsakymai duoda nenulinį statusą. Išsaugokite tikslų pranešimą; skirtumas tarp esamo įrašo ir nepasiekiamo šliuzo nusprendžia, kuri iš tolesnių dalių taikoma.
Skaitykite esamą maršrutą, o ne tik adresą
Ieškoti lentelėje to paties taškinio ketvertuko nepakanka. Maršruto objektas identifikuojamas pagal adresų šeimą, lentelę, paskirties prefiksą, metriką, protokolą ir išvesties įrenginį, o įrašai, kurie dalijasi prefiksu, gali teisėtai egzistuoti greta, kai tie požymiai skiriasi. Susiduria visas objektas, o ne tekstas.
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
Paskutinė komanda atsako į kitą klausimą nei pirmosios dvi: ne ką egzistuoja, bet kurį įrašą branduolys pasirinktų tai paskirčiai dabar. Abu požiūriai naudingi, ir jie pakankamai dažnai nesutampa, kad verta juos palyginti prieš darant išvadas. Jų neatitikimas ir yra įdomus atvejis, o ne apvalinimo klaida.
Užrašykite prefiksą, lentelę, metriką ir įrenginį šalia nepavykusios užklausos. Jei esamas įrašas turi tuos pačius požymius ir tą patį kitą šuolį, turite dvigubą instrukciją, o ne maršrutizavimo problemą.
Keturi savininkai, kuriuos prefiksas gali turėti
Prijungti maršrutai ateina iš priskirto adreso ir sistema juos atkuria visada, kai tas adresas egzistuoja. DHCP klientas arba ryšio tvarkyklė įdiegia maršrutus kaip savo gyvavimo ciklo dalį. Kitas VPN klientas jau gali nešti tą patį prefiksą. O vietinis kabliukas ar scenarijus gali pridėti tokį, apie kurį niekas kitas nežino.
Kiekvienam savininkui reikia skirtingos pataisos. Prijungtas maršrutas nėra jūsų trinamas; jo pašalinimas gali nutraukti vietinį pristatymą prieš tai, kai tunelis taps naudojamas, ir branduolys jį grąžins. Tvarkyklės valdomą maršrutą reikia keisti per tą tvarkyklę, o ne rankiniu ip route del, kurį atšaukia kitas prisijungimas.
Išlaikytas sąsaja tą pačią painiavą palengvina. Kai tunelio įrenginys išgyvena prisijungimą, pasirinktinio sąrankos kodo įdiegti maršrutai gali išlikti antrojo paleidimo metu, todėl scenarijus, kuris remiasi švaria būsena, antrą kartą nepavyksta, o pirmą kartą veikia. Arba sąmoningai išvalykite pasenusį įrašą, arba padarykite sąrankos kodą idempotentišką.
block-local atsako į kitą klausimą
Kai profilis siunčia visą srautą per tunelį, klientas turi nuspręsti, kas nutiks vietiniam tinklui. Vėliavėlė block-local pakeičia tą sprendimą nukreipdama vietinį LAN per tunelį ir išsaugodama dokumentuotą išimtį LAN šliuzui; tai srauto politikos pasirinkimas su matomomis pasekmėmis pasiekiamumui.
Tai nepaaiškina, kodėl maršruto pridėjimas grąžino esamo įrašo klaidą, o priėmus tai kaip universalų taisymą tikrasis konfliktas paslepiamas už politikos pakeitimo. Jei jūsų vietiniai ištekliai tampa nepasiekiami po profilio redagavimo, ši vėliavėlė yra vienas pirmųjų dalykų, kuriuos reikia patikrinti; jei maršruto pridėjimas nepavyksta, tai nėra atsakymas.
Traktuokite tai kaip sprendimą, kurios paskirties vietos lieka vietinės, priimtą sąmoningai ir užrašytą. Tai nėra jungiklis, kurį reikia išbandyti, kai žurnalas atrodo keliantis nerimą.
Uždarykite ciklą: pašalinkite dublikatą jo šaltinyje
Kai žinote, kuris savininkas laiko įrašą, pašalinkite dvigubą instrukciją ten, kur ji apibrėžta. Tai gali būti route eilutė profilyje, serverio push arba kabliukas, kurio nebereikia vykdyti.
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
Tada prisijunkite iš naujo ir patvirtinkite tris dalykus: tunelis pakyla, numatyta paskirties vieta išsprendžiama į norimą kelią, ir nesėkmė dingsta neatsiradus naujai į jos vietą. Švarus žurnalas su neteisingai pasirinktu keliu nėra pataisa.
Jei prefiksas vienoje pusėje reiškia vietinį LAN, o kitoje – nuotolinį tinklą, problema yra adresų sutapimas, o ne dublikatas, ir joks trynimas nepadarys abiejų reikšmių teisingomis vienu metu. Tam atvejui reikia kito plano vienam iš dviejų tinklų. Nuspręskite, kuri pusė bus pernumeruota, prieš liesdami bet kurią.