Trūkstamas VPN maršrutas NetworkManager: profilio politika ar scenarijus?

Prisijungiate, atsiranda tunelio sąsaja, o vieno prefikso, kurio jums reikia, tiesiog nėra lentelėje. Kitas žingsnis paprastai yra scenarijaus, kuris jį prideda, paieška. Ta paieška atveda prie atsakymų, kurie į profilį įklijuoja OpenVPN pagalbininką, ir pusė tų atsakymų situaciją pablogina, o ne pagerina, nes trūkstamas maršrutas turi tris galimus savininkus ir tik vienas iš jų yra trūkstamas scenarijus.

Nuspręskite, kuris savininkas atsakingas, prieš ką nors rašydami.

Trys savininkai, vienas trūkstamas prefiksas

Prefikso gali nebūti, nes niekas jo nepateikė, nes profilis jo atsisakė arba nes jis buvo įdiegtas ten, kur jūs nežiūrite. Tai skirtingi gedimai ir jie turi skirtingus sprendimus.

Pirmąjį patikrinti lengviausia: ar serveris ar papildinys kada nors pasiūlė maršrutą? Backend, kuris niekada negavo prefikso, negali jo įdiegti, o pagalbinis scenarijus negali išgalvoti pasiekiamumo, kurio partneris niekada neaprašė. Antrasis yra profilio politika, kuri gali slopinti maršrutus, kuriuos jungtis kitu atveju paimtų. Trečiasis yra lentelė arba taisyklė, kuri gali laikyti maršrutą vietoje, kurios numatytoji paieška niekada nepaiso.

Ketvirtasis savininkas esate jūs, vėliau: scenarijus, kuris prideda maršrutą prisijungiant, bet jo nepašalina atsijungiant. Tai sukuria prefiksą, kuris pergyvena tunelį, rodo į mirusią sąsają ir supainioja kitą žmogų, kuris derins mašiną.

Perskaitykite profilį prieš ką nors pridėdami

Pradėkite nuo išsaugotos jungties savybių. Skaitykite jas neišpildami paslapčių, o jei profilio pavadinimas dviprasmiškas, naudokite UUID.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type nurodo, kuris backend valdo jungtį, ir tai svarbu, nes papildinio duomenys būdingi backendui. Vieno papildinio priimamas raktas nėra palaikoma instrukcija kitam, todėl iš kito kliento dokumentacijos nukopijuotas fragmentas nieko neįrodo.

ipv4.ignore-auto-routes ir ipv4.never-default atsako į skirtingus klausimus. Pirmasis gali atmesti maršrutus, kuriuos jungtis kitu atveju paimtų automatiškai, o antrasis valdo, ar profilis gali tapti numatytuoju maršrutu. Profilis, kuris nepaiso automatinių maršrutų ir niekuo kitu nepasikliauja, prisijungs švariai ir beveik nieko neįdiegs.

ip -4 rule show
ip -4 route show table all

Šios dvi komandos išsprendžia trečiąją galimybę. Ieškokite savo prefikso kiekvienoje lentelėje, ne tik main, ir patikrinkite, ar politikos taisyklė nesiunčia atitinkamos paieškos kitur. Jei prefiksas yra kitoje lentelėje ir niekas jo netikrina, jūs neturite trūkstamo maršruto; jūs turite paiešką, kuri jo niekada nepasiekia.

Ko scenarijus negali pataisyti

Pagalbinio scenarijaus pridėjimas duoda NetworkManager vpn.data laukui vykdomą programą. Tai tikras mechanizmas, ir daugumai šių atvejų jis netinkamas, nes scenarijus gauna kontrolę po to, kai paties profilio politika jau nusprendė, ką priimti.

OpenVPN script-security yra kitas pasikartojantis sutrikimas. Tai OpenVPN nustatymas, kuris nustato, kokius scenarijus klientas gali vykdyti ir ką gali įdėti į jų aplinką; 3 lygis leidžia perduoti prisijungimo duomenis per aplinką, o tai yra sprendimas dėl slaptųjų duomenų tvarkymo, o ne maršrutizavimo taisymas. Jo įklijavimas į profilį, kurio backend nėra OpenVPN, arba jo padidinimas, kai nė vienam scenarijui jo nereikia, prideda poveikio paviršių nepridedant maršruto.

Tada yra perkrovimo refleksas. NetworkManager tarnybos perkrovimas nugriauna ir iš naujo pastato kiekvieną valdomą jungtį, įskaitant tą, per kurią esate prisijungę, jei dirbate nuotoliniu būdu. Tai trikdantis veiksmas, o ne nekenksminga diagnostika, ir serveryje tai gali būti skirtumas tarp sesijos, kuri išlieka, ir tokios, kuri neišlieka.

Sprendimas, iš eilės

Užduokite tris klausimus iš eilės. Ar partneris pateikė prefiksą, ką parodys backend žurnalas ar jo paties būsenos išvestis? Jei taip, ar profilis sukonfigūruotas priimti ir diegti maršrutus, ar juos slopina? Jei maršrutas kažkur egzistuoja, ar paieškos kelias teisingas srautui, kurį testuojate?

Tik kai pirmas atsakymas yra taip, antras taip ir trečias teisingas, papildomas scenarijus tampa pateisinamas, ir net tada turėtumėte paklausti, ar backend palaiko maršrutą natįviai. VPN nustatymų žinynas dokumentuoja service-type ir papildiniui būdingą duomenų žodyną, ir būtent ten reikia pradėti prieš darant prielaidą, kad raktas egzistuoja.

Po patvirtinto pataisymo prisijunkite iš naujo ir išbandykite paskirties vietą pagal adresą, o paskui pagal pavadinimą, tada atsijunkite ir vėl prisijunkite, kad patvirtintumėte, jog būsena kartojasi. Vienas savininkas, viena lentelė ir maršrutas, kuris išnyksta kartu su tuneliu, yra rezultatas, kurio verta siekti.