NM OpenVPN: la konservita profilo ne estas via .ovpn-dosiero

La sama .ovpn dosiero konektiĝas el ŝelo kaj eksvalidiĝas post importo en NetworkManager. La natura konkludo estas, ke la VPN estas rompita. La pli probabla klarigo estas pli malgranda: NetworkManager ne konservis la dosieron, ĝi importis parton de ĝi en konservitan konekton, kaj la kuranta tunelo anstataŭe uzas tiujn konservitajn datumojn. Kion ajn la dosiero nun diras, tio ne rilatas al tio, kion enhavas la profilo.

La dosiero ne estas la profilo

Importo estas traduko, ne muntado. Agordoj, kiujn la kromaĵo komprenas, fariĝas ŝlosiloj en la vpn.data vortaro de la konekto; agordoj, kiujn ĝi ne komprenas, estas forĵetitaj aŭ registritaj aliloke, kaj la originala vojo estas nur referenco. Redakti la fontdosieron poste ŝanĝas nenion pri la konekto jam konservita.

Tiu breĉo klarigas tutan familion de raportoj: la komuna ŝlosilo estis rotaciita, la dosiero estis ĝisdatigita, kaj la tunelo ankoraŭ malsukcesas. La konservita profilo ankoraŭ montras al la malnova vojo aŭ la malnova valoro, kaj la komandlinio daŭre funkcias ĉar ĝi legas la dosieron, kiun vi redaktis. Du klientoj, du fontoj de vero, kaj nur unu el ili estis ĝisdatigita.

Legu la konservitan profilon, ne la dialogon

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

Uzu la UUID kiam du profilo dividas nomon, kaj konfirmu, ke la servotipo estas la OpenVPN kromaĵo, kiun vi atendas, ne alia VPN-tipo, kiu hazarde estas instalita. Poste komparu la finpunkton, la transporton kaj la atestilsignojn kun la funkcianta alvoko.

Valoro videbla en grafika redaktilo ne pruvas, ke ĝi estis konservita. Konservu, remalfermu kaj relegu ĝin per la komandlinio; historiaj konservaj difektoj estas kialo kontroli la konservitajn datumojn, ne pruvo, ke ĉiu nuna konstruo havas la saman cimon. La kontrolo kostas unu komandon.

Du ŝlosiloj, kaj direkto, kiu gravas

Por konekto uzanta TLS-aŭtentikigon, la kromaĵo konservas la vojon de la komuna ŝlosilo en ta kaj la direkton en ta-dir, kiam la surmetado uzas unu. Ambaŭ loĝas en la datumvortaro de la profilo, kaj ambaŭ devas kongrui kun tio, kion la servilo atendas.

Direkto estas decido de la servila flanko esprimita sur la kliento. Elekti unu ĉar najbara profilo havas ĝin estas la maniero, kiel funkcianta ŝlosilo komencas malsukcesi manpremon. Se la servila agordo estas sendirekta, la kliento ne devus elpensi direkton.

La ŝlosildosiero mem devas esti legebla de la kromaĵo en la kunteksto, en kiu ĝi efektive funkcias. Limigita pako havas alian vidon de la dosiersistemo ol ordinara labortabla instalaĵo, do vojo, kiu ekzistas en via ŝelo, povas esti nevidebla por la servo.

Ĝisdatigu unu eron, ne la vortaron

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

La ĉefa pluso ĝisdatigas unuopajn vortarerajn erojn. Asigni vpn.data sen ĝi anstataŭigas la tutan vortaron, kaj tiel unu mankanta ŝlosilo fariĝas kvin rompitaj agordoj. Relugu la profilon post la ŝanĝo kaj konfirmu, ke la aliaj eroj postvivis. Vortaro, kiu perdis sian malproksiman finpunkton kaj siajn atestilojn, estas multe pli longa posttagmezo ol tiu, kun kiu vi komencis.

Rekonektiĝu per la normalaj regiloj kaj observu la stadion, kiu malsukcesas. Se la pordego de la komuna ŝlosilo nun pasas kaj la kliento raportas atestilan aŭ uzantan aŭtentikigan eraron, vi antaŭeniris kaj la sekva esploro estas alia.

Ne kunfandu la reĝimojn de la regkanalo

tls-auth, tls-crypt, kaj tls-crypt-v2 estas malsamaj aranĝoj. Ŝlosildosiero, kiu aspektas simila, ne igas ilin interŝanĝeblaj, kaj plenigi la kampojn TLS-Auth ĉar alia profilo enhavas formatitan ŝlosilon produktas profilon, kiu malsukcesas tiamaniere, kiu similas malĝustan ŝlosilon.

Uzu la kromaĵan mapadon, kiu kongruas kun la reĝimo en la servila agordo. Kiam la reĝimo estas neklara, demandu la servilposedanton anstataŭ diveni el la unua linio de la dosiero.

Konservu rekuperan vojon, kiam la tunelo portas vian administran seancon. Konservita ŝanĝo ne nepre estas aplikita ŝanĝo, kaj sukcesa importo ne pruvas, ke ĉiu fonta agordo estis subtenata. Ambaŭ breĉoj indas esti konataj antaŭ ol vi rekonektos la ligilon, tra kiu vi laboras.