Czy ta wtyczka NetworkManagera może uruchomić dwa VPN-y jednocześnie?

Na liście połączeń są dwa wpisy VPN, oba twierdzą, że są połączone, a tylko jeden z nich niesie ruch, którego oczekiwałeś. Albo drugi w ogóle odmawia startu i nikt nie potrafi powiedzieć, czy winna jest wtyczka, klient czy zapomniana polityka. Twierdzenia o limicie jednego VPN opisują konkretne implementacje, a implementacje się różnią. Najpierw przejdź przez możliwości, potem przez koordynację.

Policz zapisane profile, potem aktywacje

Zapisany profil to obiekt konfiguracji, a aktywne połączenie to działająca instancja. Lista wizualnie scala oba pojęcia, dlatego oba raporty brzmią prawdziwie. Zacznij od nazwania dokładnych obiektów wraz z ich UUID, bo wyświetlana nazwa nie jest unikalna, a stary import często dzieli etykietę z nowszym wpisem. Potem sprawdź osobno listę aktywnych i zobacz, które UUID się pojawiają. Dopiero wtedy wiesz, czy porównujesz dwie konfiguracje, czy dwa żywe tunele.

Aktywowanie tego samego UUID dwa razy to trzeci przypadek i nie jest to współbieżność. To reaktywacja jednej instancji.

Przeczytaj własne metadane wtyczki

Każda wtyczka VPN dostarcza mały plik metadanych, który czyta menedżer, a te pliki mogą deklarować, czy wtyczka obsługuje kilka połączeń naraz. Czytaj plik zainstalowany na tej maszynie, zamiast powtarzać to, co obecnie pisze projekt upstream, bo to pakiet dystrybucji decyduje, co naprawdę masz. Ta sama kontrola dotyczy każdego protokołu: odpowiedź dla jednej wtyczki nic nie mówi o innej. Zapisz wersję pakietu obok wyniku, żeby późniejsze porównanie coś znaczyło.

Stare porady o limicie jednego VPN opisywały starsze integracje. Nie jest to ani wiecznie prawdziwe, ani bezpieczne do przyjęcia jako stałe, a plik przed tobą rozstrzyga to lokalnie.

Współbieżne nie znaczy skoordynowane

To, że dwie wtyczki startują pomyślnie, dowodzi możliwości, a nie projektu. Dwa tunele, które oba oferują trasę domyślną, będą konkurować, a ten, który zainstalował swoją trasę ostatni, zwykle wygrywa, nie ogłaszając tego. Nakładające się zakresy prywatne mają ten sam problem w mniejszej formie.

Zdecyduj, które cele należą do którego profilu, zanim cokolwiek aktywujesz. Zmiana nazwy profilu nie rozróżnia celów.

DNS wybiera zwycięzcę, czy tego chcesz, czy nie

Ustawienia resolvera są na profil, a gdy dwa są aktywne, kolejność rozwiązywania zależy od polityki i priorytetu, a nie od intencji. Profil, który wstał ostatni, może po cichu posiadać każdą nazwę firmową.

Przypisz każdą prywatną przestrzeń nazw do resolvera, który ma na nią odpowiadać, i ustaw preferencję routingu świadomie, zamiast liczyć na kolejność. Potem przetestuj nazwę z każdej przestrzeni przy obu tunelach w górze, a potem ponownie z jednym z nich rozłączonym. Resolver, który działa tylko dopóki oba tunele są w górze, to projekt, który kogoś zaskoczy w najgorszym możliwym momencie.

Wdrażaj w stałej kolejności i sprawdzaj pomiędzy

Aktywuj jeden profil, sprawdź stan jego tras i resolvera, potem aktywuj drugi i sprawdź ponownie. Porównanie obu stanów mówi, co się zmieniło i który profil czym zarządza. Nie aktywuj obu i dopiero potem diagnozuj wynik.

Przetestuj każdy potrzebny zasób przez tunel, który ma go nieść, potem odłącz jeden profil i potwierdź, że drugi zachowuje swoje trasy, swój DNS i zamierzone zachowanie przy awarii. Jeśli wdrożona wtyczka naprawdę nie potrafi tego, czego potrzebujesz, wybierz wspierane uaktualnienie albo wyraźnie odizolowaną alternatywę, zamiast ożywiać przestarzały protokół obok menedżera. Drugi, osobny tunel, którego nikt nie zarządza, nie jest izolacją; to kolejne źródło zaskakujących tras.