Stejný .ovpn soubor se připojí z shellu a po importu do NetworkManager vyprší. Přirozený závěr je, že VPN je rozbitá. Pravděpodobnější vysvětlení je menší: NetworkManager soubor neuchoval, část z něj importoval do uloženého připojení a běžící tunel místo toho používá tato uložená data. Co soubor nyní říká, je pro obsah profilu nepodstatné.

Soubor není profil

Import je překlad, ne připojení. Volby, kterým zásuvný modul rozumí, se stanou klíči ve vpn.data slovníku připojení; volby, kterým nerozumí, se zahodí nebo zaznamenají jinde, a původní cesta je jen odkaz. Úprava zdrojového souboru poté na již uloženém připojení nic nezmění.

Tato mezera vysvětluje celou rodinu hlášení: sdílený klíč byl otočen, soubor byl aktualizován a tunel stále selhává. Uložený profil stále ukazuje na starou cestu nebo starou hodnotu a příkazový řádek dál funguje, protože čte soubor, který jste upravili. Dva klienti, dva zdroje pravdy a aktualizován byl jen jeden z nich.

Čtěte uložený profil, ne dialog

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

Použijte UUID, když dva profily sdílejí název, a ověřte, že typ služby je OpenVPN modul, který očekáváte, a ne jiný typ VPN, který je náhodou nainstalovaný. Potom porovnejte koncový bod, transport a odkazy na certifikáty s funkčním voláním.

Hodnota viditelná v grafickém editoru není důkazem, že byla uložena. Uložte, znovu otevřete a přečtěte ji zpět přes příkazový řádek; historické závady ukládání jsou důvod zkontrolovat uložená data, ne důkaz, že každé současné sestavení má stejnou chybu. Kontrola stojí jeden příkaz.

Dva klíče a směr, na kterém záleží

U připojení s ověřováním TLS ukládá modul cestu ke sdílenému klíči v ta a směr v ta-dir, pokud nasazení nějaký používá. Oba žijí ve slovníku dat profilu a oba musí odpovídat tomu, co server očekává.

Směr je rozhodnutí na straně serveru vyjádřené na klientovi. Vybrat směr proto, že ho má sousední profil, je způsob, jak funkční klíč začne selhávat při handshake. Pokud konfigurace serveru směr nemá, klient by si směr neměl vymýšlet.

Samotný soubor klíče musí být pro modul čitelný v kontextu, ve kterém skutečně běží. Omezený balíček má jiný pohled na souborový systém než běžná instalace na plochu, takže cesta, která existuje ve vašem shellu, může být pro službu neviditelná.

Aktualizujte jednu položku, ne slovník

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

Vedoucí plus aktualizuje jednotlivé položky slovníku. Přiřazení vpn.data bez něj nahradí celý slovník, a tak se jeden chybějící klíč promění v pět rozbitých nastavení. Přečtěte profil po změně znovu a potvrďte, že ostatní položky přežily. Slovník, který ztratil vzdálený koncový bod a certifikáty, je mnohem delší odpoledne než to, se kterým jste začali.

Připojte se znovu přes obvyklé ovládací prvky a sledujte fázi, která selhává. Pokud brána sdíleného klíče nyní projde a klient hlásí chybu certifikátu nebo ověřování uživatele, posunuli jste se kupředu a další vyšetřování je jiné.

Neslučujte režimy řídicího kanálu

tls-auth, tls-crypt, a tls-crypt-v2 jsou různá uspořádání. Soubor klíče, který vypadá podobně, je nečiní zaměnitelnými, a vyplnění polí TLS-Auth proto, že jiný profil obsahuje formátovaný klíč, vytvoří profil, který selhává způsobem připomínajícím špatný klíč.

Použijte mapování modulu, které odpovídá režimu v konfiguraci serveru. Když je režim nejasný, zeptejte se vlastníka serveru, místo abyste hádali z prvního řádku souboru.

Ponechte si cestu obnovy, když tunel nese vaši řídicí relaci. Uložená změna nemusí být použitá změna a úspěšný import není důkazem, že byla podporována každá zdrojová volba. Obě ty mezery stojí za to znát, než znovu připojíte spojení, přes které pracujete.

Související články