Import w NetworkManager nie udaje się z plikami OpenVPN i WireGuard

Wybrałem Importuj z pliku… w Ustawieniach GNOME, wybrałem profil, który działa z klientem dostawcy, i okno zamknęło się, nie dodając nic do listy. Na drugim laptopie import się zakończył, połączenie pojawiło się pod nazwą profilu, a potem nie powiodło się przy pierwszym zapytaniu o uwierzytelnienie. NetworkManager nigdy nie uruchamia twojego pliku .ovpn ani wg-quick tak, jak jest. Przekazuje plik parserowi, parser zamienia go na własny format połączenia NetworkManagera i od tego momentu tunel jest budowany z tego sparsowanego obiektu — sekrety, trasy, DNS i wszystko inne. Więc użyteczne pytanie nie brzmi, dlaczego plik jest zepsuty, ale czy parsowanie się odbyło i co zachowało.

Co import naprawdę robi z plikiem

Dla OpenVPN parser mieszka w pakiecie wtyczki, a tworzone przez niego połączenie wskazuje na usługę D-Bus taką jak org.freedesktop.NetworkManager.openvpn. Nie ma wtyczki, nie ma parsera: typ jest nieznany dla nmcli, a graficzna lista dodawania VPN może w ogóle nie pokazywać pozycji importu. WireGuard różni się pod jednym ważnym względem — NetworkManager ma własne ustawienia WireGuard od serii 1.30, więc nie ma osobnego pakietu wtyczki, ale czytnik wg-quick istnieje tylko w kompilacjach, które go dostarczają.

Tak czy inaczej plik jest czytany raz. Wynik jest zapisywany jako keyfile w /etc/NetworkManager/system-connections/, nazwany po połączeniu, należący do roota i nieczytelny dla innych użytkowników, bo zawiera materiał kluczy. Ten keyfile jest teraz połączeniem; późniejsza edycja oryginalnego .ovpn niczego nie zmienia.

Trzy objawy należą do trzech różnych etapów. Brak pozycji importu lub nieznany typ oznacza, że brakuje wtyczki albo wersji. Błąd importu nazywający dyrektywę oznacza, że parser przeczytał plik i odrzucił jego część. Połączenie, które istnieje, ale nigdy się nie aktywuje, oznacza, że sparsowany obiekt jest niekompletny albo serwer go odrzuca. Ustal, który z trzech przypadków masz, zanim cokolwiek edytujesz.

Potwierdź wtyczkę, zanim zaczniesz debugować profil

Brakująca wtyczka wygląda dokładnie jak uszkodzony profil, więc najpierw sprawdź pakiet. W Debianie i Ubuntu obsługa OpenVPN jest dostarczana jako network-manager-openvpn plus pomocnik pulpitu; w Fedorze to pakiety NetworkManager-openvpn i NetworkManager-openvpn-gnome; w Archu to networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Następnie zaimportuj z bezwzględnej ścieżki: nmcli connection import type openvpn file /home/you/profile.ovpn. Ścieżki względne zwykle działają, ale powłoka, która zmieniła katalog, zamienia szybki import w objazd. Dla WireGuard sprawdź nmcli --version i upewnij się, że strona jądra istnieje z modprobe wireguard; import, który udaje się na maszynie bez modułu, zostawia cię z połączeniem, którego urządzenie nigdy się nie pojawia. dokumentacja nmcli opisuje podkomendę import i akceptowane nazwy typów. Jeśli type wireguard jest odrzucane od razu, kompilacja jest starsza od tej funkcji i właściwym krokiem jest pakiet dystrybucji albo backport — a nie kopiowanie konfiguracji do dowolnego katalogu w nadziei, że coś ją przeczyta.

Czytaj połączenie OpenVPN, a nie .ovpn

Gdy połączenie istnieje, czytaj sparsowane ustawienia zamiast ponownie czytać plik: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Chcesz remote i port, transport, materiał tożsamości — ca, cert, key, tls-auth lub tls-crypt — oraz metodę uwierzytelniania. W profilu z hasłem klucza prywatnego dodaj sudo nmcli --show-secrets connection show "Work VPN" i spójrz na flagi secret: 0 to none, więc sekret leży w keyfile; 1 to agent-owned; 2 to not-saved, czyli nigdy nie jest zapisywany do keyfile; 4 to not-required, czyli sekret w ogóle nie jest potrzebny. To bity, nie skala, więc 3 to po prostu agent-owned plus not-saved. Sekret, o który pytają raz na sesję, to agent-owned (1), przy czym agent o niego pyta; nie ma na to osobnego numeru flagi. Niezgodność flag to zwykła przyczyna, dla której profil łączy się z apletu pulpitu, a zawodzi ze skryptu albo przy starcie.

Najszybciej zobaczysz, co parser odrzucił, prosząc wtyczkę o zapisanie pliku z powrotem i porównując go: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Dyrektywy, które znikną w tym diffie, nie będą istnieć w momencie połączenia. Hooki to zwykli podejrzani — script-security, up, down i route-up oczekują skryptu uruchamianego z podwyższonymi uprawnieniami i celowo nie są przenoszone. Nie obniżaj weryfikacji i nie dawaj dodatkowych uprawnień, żeby import się udał; nieobsługiwana opcja zwykle odzwierciedla zestaw funkcji wtyczki, a nie nieosiągalny serwer. Przenieś to zachowanie do skryptu dispatcher NetworkManagera albo do polityki po stronie serwera.

Potwierdź też, że pola tożsamości przetrwały: odniesienie CA, remote-cert-tls i dowolna kontrola nazwy, na której opierał się profil. Połączenie, które wstaje bez nich, może rozmawiać z czymkolwiek, co odpowiada na tym adresie.

Czytaj połączenie WireGuard, a nie plik wg-quick

Plik wg-quick to format z semantyką powłoki; zaimportowane połączenie to zbiór ustawień. PrivateKey staje się kluczem prywatnym interfejsu, Address — jednym lub kilkoma adresami IPv4 i IPv6, DNS mapuje się na właściwości resolvera NetworkManagera, MTU mapuje się na wireguard.mtu (własna wartość domyślna wg-quick to 1420), a każdy blok peer staje się wpisem peer z kluczem publicznym, endpointem, dozwolonymi IP i persistent keepalive. Wypisz to, co zapisano, za pomocą nmcli --show-secrets connection show wg0; jeśli lista peerów nie pojawia się w tym wyjściu, przeczytaj keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Nie przetrwa połówka wg-quick związana z powłoką. PreUp, PostUp, PreDown, PostDown i Table to zachowanie tego narzędzia, a nie atrybuty interfejsu WireGuard, więc nic ich nie uruchamia po imporcie. Jeśli oryginał używał Table = off, żeby nie ruszać trasy domyślnej, nowsze wydania NetworkManagera udostępniają w tym celu ip4-auto-default-route i ip6-auto-default-route; ustaw je jawnie, zamiast zakładać, że połączenie zachowuje się jak skrypt. Hook, który dodawał własną trasę, potrzebuje tej trasy w ustawieniach routingu połączenia, inaczej po prostu jej zabraknie.

Daj połączeniu dokładnie jednego właściciela

Klasyczna późniejsza awaria to połączenie, które działa do następnego rozruchu, a potem wpada w pętlę. Zwykle [email protected] był jeszcze włączony z poprzedniego eksperymentu albo klient dostawcy uruchamiał własnego demona, i dwóch właścicieli pisało trasy i DNS dla tego samego celu. NetworkManager ustawia resolver swoją drogą, wg-quick pisze przez resolvconf i wygrywa ostatni piszący — więc rozwiązywanie nazw działa, potem się zatrzymuje, potem znowu działa. Sprawdź systemctl status wg-quick@wg0, nmcli connection show --active i ip link show type wireguard, a potem wyłącz drugiego właściciela, zamiast dostrajać jego metrykę.

Jeśli naprawdę potrzebujesz obu, daj im osobne interfejsy i rozłączne dozwolone IP, i pozwól dokładnie jednemu z nich zainstalować trasę domyślną. Dwie trasy domyślne z różnymi metrykami to nie split tunnel; to wyścig rozstrzygany przez usługę, która startuje druga. A po ponownym połączeniu obejrzyj ponownie zastosowany stan — jednorazowa ręczna zmiana resolvera, która naprawia wszystko, nie jest dowodem, że import jest kompletny.

Sprawdź ruchem i przetrwaj restart

Podnieś połączenie za pomocą nmcli connection up "Work VPN", a potem czytaj stan, adres i trasy zamiast ufać ikonie: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default i prawdziwe zapytanie o nazwę, która rozwiązuje się tylko wewnątrz tunelu. Handshake albo udany ping dowodzi tylko, że kryptografia działa; nic nie mówi o przekazywaniu, prefiksach split tunnel czy prywatnym DNS — a to zwykle się psuje.

Potem zrestartuj i powtórz. Zachowanie autoconnect, zmieniona nazwa interfejsu i wtyczka ładowana po urządzeniu to awarie, które widać tylko przy czystym rozruchu. journalctl -u NetworkManager -b --no-pager | tail -n 40 pokazuje, co demon zrobił z tym połączeniem w tym rozruchu. Dla drugiego komputera skopiuj keyfile i trzymaj go jako własność roota z trybem 600, albo użyj nmcli connection export dla OpenVPN i zaimportuj ponownie powstały .ovpn — ścieżka eksportu nie ma odpowiednika dla WireGuard, więc ten kierunek to kopia pliku albo świeży import z chronionego oryginału.

Krótka wersja, po kolei: potwierdź wtyczkę albo wersję NetworkManagera, zaimportuj z bezwzględnej ścieżki, odczytaj sparsowane ustawienia wraz z flagami secret, porównaj eksport OpenVPN z oryginałem, sprawdź hooki i trasy po stronie WireGuard, wyłącz każdego drugiego właściciela, a potem po restarcie zweryfikuj rozwiązywanie nazwy i tabelę tras. Gdy połączenie przejdzie to wszystko, plik profilu, od którego się zaczęło, może wrócić do chronionego magazynu.