Aplikacja VPN dostawcy kontra NetworkManager: kto jest właścicielem stanu?
Profil nazywa wtyczkę, a nie zachowanie klienta dostawcy. Zmapuj, kto odpowiada za rejestrację, DNS, blokowanie i aktualizacje, zanim przełączysz zarządzany laptop.
Importowanie profilu to nie to samo co zastąpienie klienta. NetworkManager przechowuje typ wtyczki razem z danymi i sekretami specyficznymi dla wtyczki, a wtyczka, która jest właścicielem tego typu, decyduje, co może robić połączenie. Wszystko, co aplikacja dostawcy nakłada na wierzch, od rejestracji po trwałe blokowanie, żyje poza plikiem. To, czy przełączenie jest bezpieczne, zależy od tego, na których z tych warstw naprawdę polegasz.
Plik nazywa wtyczkę, a nie zestaw funkcji
Dokumentacja ustawień VPN w NetworkManager opisuje typ usługi, który wybiera wtyczkę, a także nieprzejrzysty słownik danych i słownik sekretów interpretowane tylko przez wtyczkę. Profil to kontrakt z jedną implementacją, a nie opis zachowania, które może odtworzyć dowolny klient. Dwaj klienci mogą mówić tym samym protokołem i mimo to różnić się tym, o czym negocjują i które ścieżki danych włączają. Nazwa protokołu mówi, czym jest tunel, nigdy zaś, co robi z nim otaczający klient.
Porównuj więc wymagania, a nie opakowania. Pytanie nie brzmi, czy alternatywa potrafi się połączyć, bo zwykle potrafi; brzmi, czy każde wymaganie, które czyniło pierwotnego klienta akceptowalnym, przetrwa przeprowadzkę. Zapisz te wymagania, zanim cokolwiek zainstalujesz, inaczej porównanie zamieni się w polowanie na to, co pęknie pierwsze.
Co aplikacja dostawcy dodaje wokół tunelu
Klienci dostawców zwykle łączą rejestrację i kontrole stanu urządzenia, przepływ drugiego składnika z własnym interfejsem, trwałe blokowanie, kanał aktualizacji i narzędzia wsparcia. Część tego stoi obok protokołu, a część jest osobnym produktem, który jedynie dzieli instalator. NetworkManager może zastąpić tunel i jego trasowanie, a skrypty dyspozytora mogą wyzwalać działania, gdy zmieni się stan połączenia. Nie odtwarza jednak silnika blokowania, przepływu odnawiania certyfikatu ani założenia o tym, który użytkownik może podnieść połączenie.
Więcej komponentów nie znaczy bezpieczniej, a mniej nie znaczy słabiej. Pytanie brzmi, który komponent egzekwuje politykę, której kazano ci przestrzegać. Jeśli audytor zapyta, co blokuje ruch, gdy tunel padnie, odpowiedź musi nazwać coś, co rzeczywiście to robi, a profil, który tylko się łączy, nie jest tą odpowiedzią.
Gdzie własność naprawdę się różni
Czytaj to jako mapę własności, a nie listę kontrolną, bo awarie poniżej są lukami we własności i żadna ilość konfiguracji klienta ich nie zamyka. Każdy wiersz nazywa warstwę, stronę, która zwykle ją dziś trzyma, i miejsce, w którym luka pojawia się najpierw.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Do każdego wiersza dopisz obserwację, którą możesz powtórzyć, a nie wrażenie o kliencie. Nazwa rozwiązana przez zamierzony resolver, trasa, która znika, gdy tunel się zatrzyma, i zablokowane połączenie po symulowanym zerwaniu to trzy obserwacje, które razem pokrywają większość tabeli. Zapisz obserwację obok wymagania, które dowodzi, i zachowaj te nieudane, bo nieudana obserwacja to jedyna część zapisu, która przewiduje następny incydent.
Przełączanie bez nakładającej się własności
Uruchamianie jednocześnie klienta dostawcy i połączenia NetworkManager dla tej samej usługi to najczęstszy sposób, w jaki te porównania idą źle. Oba instalują trasy, oba mogą ustawić DNS i oba mogą dotknąć stanu zapory. To, co wtedy mierzysz, to trzeci układ, który nie odpowiada udokumentowanemu zachowaniu żadnego z dwóch klientów.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Pierwsze polecenie mówi, czy profil jest w ogóle typu VPN. Drugie pokazuje typ usługi wtyczki i które sekrety są zapisane, co ma znaczenie, gdy klucza oczekuje się od agenta, a nie z pliku. Dziennik to miejsce, w którym wtyczka załadowana, ale niezdolna do negocjacji, to powie. Jeśli żadne z trzech nie pokaże problemu, luka tkwi w warstwach polityki nad tunelem, a nie w połączeniu.
Odłącz starego klienta przed włączeniem nowego połączenia, zachowaj identyczne punkty końcowe i konto, i zapisz, który komponent odpowiada za trasy, ustawienia resolvera i blokowanie. To właśnie ta notatka nie pozwala następnej aktualizacji skończyć się dwoma właścicielami.