Stan NEVPNManagera jest nieprawidłowy, dopóki nie wczytają się preferencje

Uruchom aplikację ponownie, zapytaj menedżera o stan połączenia, a zgłosi rozłączone, podczas gdy menu systemowe wyraźnie pokazuje działający tunel. Albo wywołanie zapisu zwraca błąd, który niczego nie wyjaśnia, albo wspólny sekret zostaje uznany za brakujący kilka sekund po przypisaniu. Trzy objawy, jeden mechanizm: menedżer to widok na systemowy magazyn, a widok czyta się jako pusty, dopóki ktoś go nie wczyta.

Zanim zaczniesz cokolwiek z tego debugować, ustal, którego API powinieneś używać. Tunel systemowy IPsec lub IKEv2 pasuje do wbudowanego menedżera; protokół, którego system nie implementuje, wymaga dostawcy tunelu z własną obsługą pakietów, i żadna kombinacja pól tego nie zmienia.

Menedżer to widok na magazyn

Utwórz lub pobierz menedżera, poproś go o wczytanie preferencji i pozwól obsługiwaczowi zakończenia skończyć, zanim odczytasz stan lub zmienisz ustawienia protokołu. Gdy zadaniem jest wyliczenie zapisanych konfiguracji, użyj wywołania wszystkich wariantów, zamiast używać jednej instancji do dwóch celów. Zanim wczytywanie dotrze, stan zwykle jest nieprawidłowy, a traktowanie nieprawidłowego jako wyłączonego to dokładnie ten błąd, przez który aplikacja wygląda źle dopiero po ponownym uruchomieniu.

Zapis podlega tej samej kolejności. Próba zapisu na menedżerze, który nigdy niczego nie wczytał, może się nie udać bez użytecznego komunikatu, bo nie ma zapisanej tożsamości, do której zmiana miałaby się odnieść. Wczytaj, zmień, zapisz, a potem odczytaj stan ponownie. Obiektem, z którym łączy się system, jest zapisany profil, a nie ten, który edytowałeś w pamięci.

Zmiany stanu przychodzą tylko wtedy, gdy patrzysz

Po wczytaniu preferencji stan przechodzi przez rozłączony, łączenie, połączony, ponowne potwierdzanie i rozłączanie. Zainicjuj interfejs jednym odczytem, a potem nasłuchuj powiadomienia o zmianie zamiast odpytwać z timerem. Odpytywanie działa na pierwszym planie i kłamie w tle, i tak aplikacje zostają z wskaźnikiem, który nigdy się nie kończy.

Powiadomienia przychodzą tylko wtedy, gdy aplikacja jest na pierwszym planie. Wszystko, co utrzymuje stan w tle, po ponownym uruchomieniu będzie wyglądać nieaktualnie, więc odświeżaj przy starcie i ponownie, gdy aplikacja wraca na pierwszy plan. Jeśli tunel należy do dostawcy, steruj nim przez odpowiedni obiekt sesji; zwykła właściwość połączenia nie modeluje cyklu życia dostawcy.

Sekrety to odwołania, nie łańcuchy

Zgłoszenie brakującego wspólnego sekretu rzadko oznacza, że nikt go nie przypisał. Obiekt protokołu chce odwołania: jednego dla hasła użytkownika i jednego dla klucza wstępnie współdzielonego IPsec. Przekazanie nil albo odwołania wyprowadzonego z niewłaściwego wpisu pęku kluczy daje tę samą skargę co puste miejsce. Błąd nazywa objaw i ukrywa przyczynę, dlatego ludzie wpisują ten sam sekret kilka razy.

Najpierw zapisz sekret jako element zwykłego hasła, a potem odczytaj trwałe odwołanie do niego. Trwałe odwołanie przeżywa ponowne uruchomienie, inaczej niż wskaźnik w pamięci, i to jest reprezentacja, którą serializuje profil. Wybierz klasę dostępności, która nadal pozwala na dostęp po odblokowaniu urządzenia, w przeciwnym razie tunel, który musi połączyć się ponownie na zablokowanym ekranie, nie przejdzie uwierzytelnienia z całkowicie prawidłowym sekretem.

Rozszerzenie ma własny widok pęku kluczy

Rozszerzenie sieciowe to osobny proces, więc domyślny dostęp aplikacji do pęku kluczy do niego nie dociera. Daj obu celom tę samą grupę dostępu do pęku kluczy w ich uprawnieniach, zapisz element raz w tej grupie i pozwól każdemu procesowi go czytać. Bez grupy rozszerzenie niczego nie znajduje i zgłasza błąd poświadczeń, którego aplikacja nie potrafi odtworzyć.

Jeśli dostawca jest konfigurowany przez swój obiekt konfiguracji dostawcy, nie osadzaj sekretu również w aplikacji. Dwie kopie rozjeżdżają się, a rozjazd objawia się jako złe poświadczenia, a nie jako duplikacja. Widget albo drugi proces zgłaszający inny stan ma to samo wyjaśnienie: każdy potrzebuje grupy i każdy musi wczytać preferencje przed odczytem.

Dopasuj API do protokołu

Wbudowany menedżer przenosi obiekty protokołów IPsec i IKEv2. Nie staje się ogólnym klientem SSL VPN dzięki dodatkowym polom, a niedopasowany profil może się czysto zapisać i mimo to nigdy nie połączyć. Zdecyduj, do której kategorii należysz, zanim zbadacz stan, bo błąd stanu i nieobsługiwany protokół wyglądają z zewnątrz identycznie.

Na następne uruchomienie lista kontrolna jest krótka: wczytaj preferencje, odczytaj stan, trzymaj subskrypcje zmian na pierwszym planie, odbuduj odwołania ze wspólnej grupy i potwierdź, że obiekt protokołu odpowiada API, które zaimplementowałeś. Przejście tej listy zajmuje minutę; zgadywanie jej zajmuje całe popołudnie.