OpenVPN nutrūksta po DHCP atnaujinimo: išsaugokite pabaigos taško maršrutą

Tunelis prisijungia, tada nuomos atnaujinimas prieigos jungtyje jį nužudo, o žurnalas kaltina laiko limitą, o ne maršrutą. VPN konfigūracijoje niekas nepasikeitė, ir tai yra užuomina: pasikeitė kažkas už jos ribų. DHCP įvykis perrašė adresą arba vartus, o maršrutas į mazgą, kuris laikė tunelio pabaigos tašką pasiekiamą, dabar rodo į kitą šuolį, kurio nebėra. Tai nuosavybės problema anksčiau, nei maršrutizavimo problema.

Palyginkite simptomą su pusiau numatytaisiais maršrutais

Su redirect-gateway def1 OpenVPN įdiegia 0.0.0.0/1 ir 128.0.0.0/1, o ne pakeičia numatytąjį maršrutą. Kartu šie du padengia visą adresų erdvę, ir jie įveikia 0.0.0.0/0 vien prefikso ilgiu. Todėl bet kokia paskirties vieta be konkretesnio atitikimo patenka į tunelį.

Pabaigos taškui reikia išimties. OpenVPN prideda maršrutą į serverio adresą per pirminius prieigos vartus prieš įtraukiant pusiau numatytuosius, kad inkapsuliuoti paketai galėtų išeiti. Kai ta išimtis išnyksta arba išlaiko kito šuolio reikšmę, kurio nebėra, paties tunelio išoriniai paketai atitinka pusiau numatytąjį maršrutą ir grąžinami atgal į tunelį. Rezultatas yra ryšys, kuris miršta kitame keepalive arba rankos paspaudime, o žurnale nėra nieko, kas primintų maršrutizavimo klaidą.

Patvirtinkite lentelės formą prieš ką nors kitą liesdami. ip route show turėtų išvardyti abi puses ir maršrutą į mazgą serverio adresui; kai maršruto į mazgą nėra, likusiam tyrimui yra akivaizdus pradžios taškas.

Kodėl pusiau numatytieji laimi nekeičiant metrikos

Mažesnė metrika neįveikia ilgesnio prefikso. Maršrutai /1 laimi todėl, kad branduolys pirmiausia sutapatina konkretiausią maršrutą, taigi metrikos padidinimas numatytajame maršrute nieko nekeičia klausimu, kur eina į tunelį nukreiptas srautas. Metrikų vaikymasis yra dažniausias klaidingas posūkis šioje diagnostikoje.

Patikrinkite pasirinkimą su ip route get 203.0.113.10, pakeisdami jį tikruoju serverio adresu. Atsakymas įvardija sąsają ir kitą šuolį, kuriuos branduolys iš tikrųjų naudotų, ir tai informatyviau nei skaityti lentelę ir apie ją svarstyti.

Vykdykite šią komandą prieš tunelio pradžią, jam veikiant ir po nuomos įvykio. Trys atsakymai iš vienos komandos, ir nukrypimo taškas tampa matomas.

Padarykite tris momentines nuotraukas, o ne vieną

Surinkite prieigos adresą, prieigos vartus, pabaigos taško paskirties vietą, pasirinktą maršrutą ir visas politikos taisykles trimis momentais: sukonfigūravus prieigos jungtį, prisijungus VPN ir po nuomos ar operatoriaus įvykio. Kiekviena nuotrauka yra sauja komandų, ir jos turi prasmę tik kartu. Viena nuotrauka po gedimo fiksuoja būseną, o ne perėjimą. Surašykite komandas į mažą scenarijų, kad kiekviena nuotrauka būtų daroma vienodai.

Laikykite nuotraukas viename faile su laiko žymomis, nes vėliau įdomus klausimas yra eiliškumas. Ar DHCP įvykis atėjo prieš tai, kai OpenVPN atnaujino savo maršrutą, ar po to? Atsakymas nulemia, kas turi tai sutaisyti. Laiko žyma iš neteisingo laikrodžio yra blogiau nei jokios, todėl imkite ją iš mazgo, kuris valdo maršrutizavimo lentelę.

Kai pabaigos taškas sukonfigūruotas kaip vardas, o ne adresas, išspręskite jį ir kiekvienoje nuotraukoje. DNS pokytis prieigos jungtyje gali perkelti pabaigos tašką visiškai neliesdamas jokio maršruto.

Nuspręskite, kuris komponentas atnaujina išimtį

dhcpcd sistemoje kabliukai paleidžiami iš kabliukų katalogo ir iš išėjimo kabliuko, o valdytojo režimas apimtimi skiriasi nuo režimo pagal sąsają. Kad ir ką darytų kabliukas, jis turi būti idempotentinis, nes atnaujinimai gali ateiti būriais.

Patikimas savininkas yra integracija, kuri jau pažįsta abi puses: tinklo valdytojas, valdantis VPN ryšį, arba unit, išdėstytas po prieigos jungties pakilimo. Kabliuko pridėtas statinis maršrutas veikia iki kito vartų pakeitimo, o tada sugenda lygiai taip pat. Jei vis dėlto naudojate kabliuką, leiskite jam vykdymo metu skaityti dabartinius vartus, o ne kietai užkoduoti tuos, kuriuos matėte šiandien.

Užfiksuokite savininką konfigūracijoje. Kitas žmogus, derinantis prisijungimą iš naujo, turi žinoti, kad už išimties maršrutą atsakingas kabliukas, o ne VPN.

Tikrinkite gyvavimo ciklą, o ne tik prisijungimą iš naujo

Priverstinai atnaujinkite su dhcpcd -n eth0 arba atleisdami ir iš naujo paimdami nuomą, tada dar kartą patikrinkite ip route get pabaigos taškui. Padarykite tai du kartus, nes antrasis paleidimas pagauna kabliukus, pridedančius pasikartojančius maršrutus. Tada paleiskite iš naujo, nes patvarumas yra kita savybė nei teisingumas.

Tunelis, kuris išgyvena atnaujinimą ir paleidimą iš naujo, turi savininką ir veikiančią išimtį. Tas, kuris išgyvena tik rankinį paleidimą iš naujo, neturi nė vieno, ir suges kitame įvykyje, kurio negalite suplanuoti.