Mankanta VPN-itinero en NetworkManager: profila politiko aŭ skripto?
La tunelo konektiĝas kaj unu prefikso neniam aperas. Decidu inter profila politiko, kromaĵaj datumoj kaj dua itinera posedanto antaŭ ol aldoni helpan skripton.
Vi konektiĝas, la tunela interfaco aperas, kaj unu prefikso, kiun vi bezonas, simple ne estas en la tabelo. La sekva paŝo kutime estas serĉo pri skripto, kiu aldonas ĝin. Tiu serĉo kondukas al respondoj, kiuj enmetas OpenVPN-helpilon en profilon, kaj duono de tiuj respondoj plimalbonigas la situacion anstataŭ plibonigi ĝin, ĉar mankanta itinero havas tri eblajn posedantojn kaj nur unu el ili estas mankanta skripto.
Decidu, kiu posedanto respondecas, antaŭ ol vi skribos ion ajn.
Tri posedantoj, unu mankanta prefikso
La prefikso povas manki ĉar neniu liveris ĝin, ĉar la profilo rifuzis ĝin, aŭ ĉar ĝi estis instalita ie, kie vi ne rigardas. Tiuj estas malsamaj paneoj kaj ili havas malsamajn riparojn.
La unua estas la plej facila por kontroli: ĉu la servilo aŭ la kromaĵo iam proponis la itineron? Backend, kiu neniam ricevis la prefikson, ne povas instali ĝin, kaj helpa skripto ne povas elpensi atingeblon, kiun la partnero neniam priskribis. La dua estas profila politiko, kiu povas subpremi itinerojn, kiujn la konekto alie prenus. La tria estas tabelo aŭ regulo, kiu povas teni la itineron en loko, kiun la defaŭlta serĉado neniam konsultas.
Kvara posedanto estas vi, poste: skripto, kiu aldonas la itineron ĉe konekto sed ne forigas ĝin ĉe malkonekto. Tio produktas prefikson, kiu postvivas la tunelon, montras al morta interfaco kaj konfuzas la sekvan personon, kiu sencimigos la maŝinon.
Legu la profilon antaŭ ol aldoni ion ajn
Komencu per la propraj ecoj de la konservita konekto. Legu ilin sen elverŝi sekretojn, kaj uzu la UUID se la profila nomo estas ambigua.
nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office
vpn.service-type diras al vi kiu backend posedas la konekton, kaj tio gravas ĉar kromaĵaj datumoj estas specifaj por la backend. Ŝlosilo akceptata de unu kromaĵo ne estas subtenata instrukcio por alia, do fragmento kopiita el dokumentaro de alia kliento ne estas pruvo pri io ajn.
ipv4.ignore-auto-routes kaj ipv4.never-default respondas malsamajn demandojn. La unua povas malakcepti itinerojn, kiujn la konekto alie prenus aŭtomate, kaj la dua regas, ĉu la profilo rajtas fariĝi la defaŭlta itinero. Profilo, kiu ignoras aŭtomatajn itinerojn kaj fidas al nenio alia, konektiĝos pure kaj instalos preskaŭ nenion.
ip -4 rule show
ip -4 route show table all
Tiuj du komandoj solvas la trian eblecon. Serĉu vian prefikson en ĉiu tabelo, ne nur en main, kaj kontrolu, ĉu politika regulo sendas la rilatan serĉadon aliloken. Se la prefikso ĉeestas en alia tabelo kaj nenio konsultas ĝin, vi ne havas mankantan itineron; vi havas serĉadon, kiu neniam atingas ĝin.
Kion skripto ne povas ripari
Aldoni helpan skripton donas al vpn.data de NetworkManager programon por ruli. Tio estas reala mekanismo, kaj ĝi estas la malĝusta por la plej multaj el ĉi tiuj kazoj, ĉar la skripto ricevas kontrolon post kiam la propra politiko de la profilo jam decidis, kion akcepti.
script-security de OpenVPN estas la alia ripetiĝanta konfuzo. Ĝi estas OpenVPN-agordo, kiu regas, kiujn skriptojn la kliento rajtas plenumi kaj kion ĝi rajtas meti en ilian medion; nivelo 3 permesas pasigi akreditaĵojn tra la medio, kio estas decido pri traktado de sekretoj, ne ripari itinaron. Enmeti ĝin en profilon, kies backend ne estas OpenVPN, aŭ altigi ĝin kiam neniu skripto bezonas ĝin, aldonas ekspozicion sen aldoni itineron.
Poste estas la restartiga reflekso. Restartigi la servon NetworkManager disŝiras kaj rekonstruas ĉiun administritan ligon, inkluzive tiun, tra kiu vi estas konektita, se vi laboras malproksime. Ĝi estas ĝena ago, ne sendanĝera diagnozo, kaj sur servilo ĝi povas esti la diferenco inter sesio, kiu postvivas, kaj unu, kiu ne.
La decido, laŭ ordo
Demandu tri demandojn sinsekve. Ĉu la partnero liveris la prefikson, kion montros la protokolo de la backend aŭ ĝia propra stata eligo? Se jes, ĉu la profilo estas agordita por akcepti kaj instali itinerojn, aŭ ĉu ĝi subpremas ilin? Se la itinero ekzistas ie, ĉu la serĉa vojo estas ĝusta por la trafiko, kiun vi testas?
Nur kiam la unua respondo estas jes, la dua estas jes kaj la tria estas ĝusta, suplementa skripto fariĝas defendebla, kaj eĉ tiam vi devus demandi, ĉu la backend subtenas la itineron denaske. La referenco pri VPN-agordoj dokumentas service-type kaj la kromaĵ-specifan datuman vortaron, kaj tie oni devas komenci antaŭ ol supozi, ke ŝlosilo ekzistas.
Post aprobita korekto, rekonektiĝu kaj testu la celon laŭ adreso kaj poste laŭ nomo, tiam malkonektiĝu kaj rekonektiĝu por konfirmi, ke la stato estas ripetebla. Unu posedanto, unu tabelo kaj itinero, kiu malaperas kun la tunelo, estas la rezulto inda.