Jeden profil, dva vlastníci: NetworkManager, nebo systemd

Se souborem .ovpn se nic neděje, dokud jej něco nevlastní. Na ploše Pi jsou pravděpodobnými vlastníky NetworkManager, který ukládá importované připojení do vlastního keyfile, a samostatná služební unit, která čte konfiguraci z adresáře. To jsou dva provozní modely s jiným úložištěm, jiným zacházením s přihlašovacími údaji a jinými pravidly aktivace. Vědomě si vybrat jeden z nich je celý úkol; kopírování souboru na obě místa jen dělá volbu náhodnou.

Oba mohou fungovat na jednom stroji, ale ne na stejném tunelu ve stejnou chvíli, a konflikt vypadá jako síťová závada, ne jako konfigurační.

Dva způsoby, jak vlastnit stejný tunel

Zásuvný modul OpenVPN v NetworkManageru přidává editor a službu, které za vás připojení spravují, a instalace programu OpenVPN tuto integraci nenainstaluje. Samostatná unit je opačné uspořádání: žádný editor, žádná integrace s plochou, jeden konfigurační soubor a ta oprávnění, která unit udělí. První drží stav připojení ve vlastní databázi, druhý jej drží tam, kde říkají profil a unit. Většina zmatku pramení z předpokladu, že importovaný profil a zkopírovaný soubor jsou stejný objekt.

Nejsou to dva pohledy na jednu věc. Úprava staženého souboru nemění ani to, co uložil NetworkManager, ani to, co čte unit, a kterýkoli z nich mohl postavit tunel, který jste právě otestovali.

Sledujte připojení, které plocha skutečně používá

Dokumentovaná operace importu, nmcli connection import type openvpn file office.ovpn, vytváří připojení přes zásuvný modul. Poznamenejte si jeho UUID a ten identifikátor pak používejte, protože názvy se upravují a dvě připojení mohou sdílet jeden popisek. nmcli connection show vypisuje, co existuje, a čtení vlastností samotného připojení vám řekne, ze kterého souboru pochází a co ukládá. Pokud UUID, které upravujete, není to, které plocha aktivuje, jsou vaše úpravy jen dekorace.

Tajemství žijí v úložišti vlastníka. Vysypat všechna uložená tajemství, abyste zjistili, který profil je aktivní, je pomalé a riskantní; zeptejte se místo toho objektu připojení a soukromý materiál držte tam, kde jej vlastník očekává.

Importované připojení nepotřebuje ke svému běhu grafickou relaci, ale stále může potřebovat zdroj přihlašovacích údajů. Zda se spustí bez dozoru, závisí na jeho oprávněních a tajemstvích, ne na přítomnosti plochy.

Přečtěte si šablonu unit dřív, než se na ni spolehnete

Když balíček dodává klientskou unit ve stylu upstream, instance pojmenovaná office odpovídá %i.conf v nakonfigurovaném adresáři unit, který je pro šablonu 2.6 /etc/openvpn/client. Přečtěte si nainstalovanou unit a případné doplňkové soubory, než uvěříte příkladu z návodu, protože distribuce přemisťují cesty. Ruční spuštění z terminálu nic nedokazuje o tom, jak služba vidí soubory, tajemství nebo oprávnění. Ani dialog pro heslo na ploše není důkazem, že neinteraktivní unit má schválený způsob, jak získat stejné heslo.

Dejte unit jen to, co potřebuje. Povolit celý sandbox služby proto, že jeden odkazovaný soubor je nečitelný, vyměňuje malou opravu oprávnění za velké vystavení, a chyba obvykle pojmenuje soubor, který potřebuje pozornost.

Odstavte duplikát, aniž byste ztratili přístup

Mohou-li oba vlastníci tunel spustit, jeden nakonec vyhraje ve špatnou chvíli a trasy a zařízení poraženého zůstanou pozadu. Odstraňte náhodný duplikát přes jeho vlastního vlastníka, nechte otevřenou cestu k obnovení a potvrďte, že zbývající vlastník se po restartu stále připojuje. Dvě vědomě oddělené VPN s různými zásadami směrování jsou jiná otázka návrhu, ne povolení, aby dvě cesty spuštění soutěžily o jedno připojení.

Pak si zapište životní cyklus, který jste přijali: ruční aktivace, přihlášení, nebo start a opětovné připojení. Zkontrolujte uložený koncový bod, ověření protistrany a prostředek, kterého má tunel dosáhnout, protože přeinstalace plochy nenahradí vědomí, která konfigurace běžela.