Serwer VPN na Pi: zacznij od aplikacji w telefonie, nie od przepisu

Większość instalacji VPN na Pi zaczyna się od przepisu na serwer, a kończy telefonem, który nie potrafi się połączyć. Kolejność jest odwrotna. Klient w telefonie implementuje konkretny protokół z konkretną wymianą uwierzytelniania, a serwer musi pasować do tej wymiany, a nie odwrotnie. Wybranie najpierw aplikacji zamienia popołudnie debugowania w krótką listę kontrolną.

Kolejność, która oszczędza przebudowę

Zapisz system operacyjny telefonu i dokładną aplikację VPN, zanim cokolwiek zainstalujesz na Pi. Ta para decyduje, który protokół jest w ogóle możliwy. Aplikacja klienta nie staje się innym klientem tylko dlatego, że profil przypadkiem zawiera znane pole.

Wspólny sekret w profilu albo znajomo wyglądający numer portu nie zamienia jednego protokołu w drugi. Wymiana albo odpowiada temu, co implementuje aplikacja, albo zawodzi na etapie, który daje bardzo mało do czytania. Nie ma diagnostyki, która prostymi słowami mówi "zły protokół". Dostajesz przekroczenie limitu czasu, błąd certyfikatu albo cichą pętlę ponowień, i wszystko to wygląda jak problem serwera.

Gdy aplikacja jest ustalona, wybór serwera się zawęża, a reszta instalacji ma cel.

Co aplikacja w telefonie faktycznie implementuje

Opublikowana lista klientów opisuje aplikację, a nie usługę. Aplikacja OpenVPN Connect dla Androida oczekuje serwera OpenVPN; nie dostarcza strony serwera. Nie staje się też klientem IPsec ani L2TP, gdy profil wygląda podobnie.

Ta różnica ma największe znaczenie przy starszym poradniku. Przepisy napisane dla protokołu, który obecna aplikacja porzuciła, nadal zainstalują się czysto na Pi i nadal zawiodą na telefonie, co czyta się jako błąd konfiguracji, a nie jako niezgodność protokołu.

Sprawdź w aktualnej dokumentacji aplikacji, jakie formaty profilu importuje, zanim zwiążesz się z pakietem serwera. Pięć minut czytania jest lepsze od przebudowy.

Czteroczęściowa umowa

Zapisz cztery rzeczy i trzymaj je razem: system operacyjny i wersję aplikacji w telefonie, implementację serwera na Pi, politykę uwierzytelniania i zaufania oraz zewnętrzny punkt końcowy. Każda z czterech może unieważnić pozostałe trzy.

Aktualizacja aplikacji, zmiana pakietu serwera albo nowy urząd certyfikacji łamią umowę, a awaria z telefonu za każdym razem wygląda tak samo. Właśnie zapisane cztery pozwalają ustalić, która część się przesunęła.

Dane logowania mają osobne zadania

Zdecyduj, czy profil używa certyfikatów klienta, nazwy użytkownika i hasła, czy obsługiwanej kombinacji, i dopasuj oba końce. Tożsamość serwera i materiał zaufanego CA też muszą odpowiadać temu, co zaakceptuje klient.

Publiczny certyfikat CA i jego prywatny klucz podpisujący to różne obiekty. Do profilu telefonu należy tylko część publiczna. Umieszczenie klucza podpisującego w telefonie oddaje możliwość tworzenia tożsamości, co jest przeciwieństwem celu CA. Traktuj ten plik jako najwrażliwszy obiekt w całej instalacji.

Użyj obsługiwanego przez usługę przepływu eksportu i importu, zamiast składać profil ręcznie. Ręcznie zbudowane profile zwykle zawierają dyrektywy tylko dla komputerów, które aplikacja mobilna ignoruje lub odrzuca.

Przede wszystkim nie zastępuj walidacji certyfikatu opcją "akceptuj dowolny serwer", aby stary przykład się połączył. To zamienia problem zgodności w obejście uwierzytelniania i zwykle przetrwa do produkcji, bo działa.

Osiągalność to osobna umowa

Telefon musi dotrzeć do zewnętrznego punktu końcowego serwera przez rzeczywisty układ nadrzędny. Tłumaczenie adresów domowego routera, filtrowanie i NAT operatora znajdują się pomiędzy. Dynamiczna nazwa DNS daje punktowi końcowemu tylko stabilną nazwę; nie tworzy ścieżki przychodzącej.

Następnie określ, do czego klient może dotrzeć po połączeniu: prefiksy prywatne albo pełne wyjście do internetu, ich ścieżki przekazywania i odpowiedzi, zachowanie DNS oraz czy IPv6 jest w zakresie. Udane logowanie nie dowodzi niczego z tego.

Zaakceptuj zamierzony telefon i profil bezpośrednio, wraz ze sprawdzeniem, że nieautoryzowany zasób pozostaje nieosiągalny i że odebranie naprawdę usuwa dostęp. Sukces z klientem desktopowym potwierdza ten klient desktopowy, a nie telefon w twojej ręce. Lista OpenVPN Connect jest konkretnym przykładem aplikacji klienckiej, która oczekuje pasującej usługi.