OpenVPN czy IKEv2: cztery kontrole przed wyborem protokołu

Wybór między OpenVPN i IKEv2 zwykle roztrząsa się jako kwestię protokołu, a takie ujęcie marnuje decyzję. Decyduje to, czy serwer i urządzenia obsługują ten sam kompletny profil oraz czy ten profil wytrzymuje sposób, w jaki przemieszczasz się między sieciami. Te dwa stosy nie przekładają się na siebie: plik OVPN nie jest profilem IKEv2 z inną składnią. Cztery kontrole wykonane po kolei odpowiadają na to pytanie szybciej niż jakakolwiek tabela funkcji.

Brakujący klient kończy dyskusję

Windows i macOS mają klienta IKEv2, więc profil IKEv2 nic dodatkowo nie kosztuje przy wdrożeniu i dziedziczy opcje przygotowania, które system już udostępnia. OpenVPN na tych samych maszynach oznacza klienta firmy trzeciej do zainstalowania, aktualizowania i wspierania, a ten klient musi akceptować każdą opcję używaną przez profil. Policz platformy, które musisz objąć, zanim porównasz cokolwiek innego, bo platforma bez działającego klienta w ogóle nie jest punktem porównania.

W Windows jedno polecenie wylicza istniejące profile i pokazuje, jakiego typu jest każdy z nich. Nazwa, którą wypisuje, jest nazwą używaną przez późniejsze kontrole.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Prośba o zainstalowanie klienta to prawdziwa odpowiedź w kolumnie OpenVPN na tych platformach i jest to zadanie wdrożeniowe, a nie ograniczenie protokołu. Żadne z rozwiązań nie usuwa kontroli zaufania, weryfikacji tożsamości ani konserwacji. Zapytaj, jak rozpowszechniane są profile, jak odnawiane są poświadczenia i jak usuwane jest zgubione urządzenie, zanim się zobowiążesz. Prosta instalacja wciąż może ukrywać procedurę odzyskiwania, której nikt nie chce uruchamiać w weekend.

Mobilność to wspólne ustawienie, nie obietnica protokołu

IKEv2 może używać MOBIKE, gdy oba końce go obsługują i włączą, co pozwala klientowi utrzymać tunel, gdy jego adres się zmienia. RFC 4555 definiuje to rozszerzenie, a warunkowe sformułowanie ma znaczenie: serwer, który ignoruje tę możliwość, zamiast tego ponownie negocjuje. Wynik może wyglądać identycznie przy przesyłaniu pliku i zupełnie inaczej przy połączeniu na żywo.

Przetestuj przejście, na którym naprawdę ci zależy, przy czymś działającym, co możesz obserwować. Zostaw ping -t <internal-host> działające w Windows lub zwykłe ping gdzie indziej, potem przełącz się z Wi-Fi na sieć komórkową i wypatruj przerw. Awaria MOBIKE pojawia się w dzienniku klienta jako pełna ponowna uwierzytelnienie, a nie jako cicha aktualizacja adresu. Mierzysz to, czy tunel przetrwa zmianę, a nie to, czy protokół reklamuje obsługę.

Klienci OpenVPN łączą się ponownie zgodnie z zachowaniem swojej platformy i timerami profilu, więc ten sam test może dać inną postać przerwy. Porównuj zdarzenie, które ma znaczenie dla twoich użytkowników, a nie etykietę na protokole.

Poświadczenia należą do usługi, nie do stosu

Certyfikaty i inne układy logowania należą do usługi, która kończy połączenie. Prośba o hasło w jednym kliencie nic nie mówi o zgodności z innym, a profil działający wobec innej bramy nic nie mówi o tej. Zachowaj reguły tożsamości serwera bez zmian, porównując oba stosy. Zmiana protokołu przed zidentyfikowaniem awarii zwykle daje drugi niezgodny profil.

Sprawdź poświadczenie, które klient przedstawi, zanim obwinisz którykolwiek protokół, bo wygasły lub źle wystawiony certyfikat zawodzi tak samo w obu przypadkach. Poniższe wyjście pokazuje podmiot, wystawcę i daty ważności bez czytania klucza prywatnego.

openssl x509 -in client.crt -noout -subject -issuer -dates

Do połączenia firmowego użyj metody publikowanej przez firmę i przestań traktować porównanie jak eksperyment. Jeśli sam porównujesz oba, najpierw sprawdź, czy obie opcje kończą się na jednej bramie, bo ten jeden szczegół decyduje, jak duża część wyniku dotyczy protokołu. Odmowa, która wskazuje poświadczenie, jest problemem poświadczenia i żadna zmiana protokołu tego nie naprawi.

Sprawdź, co tunel naprawdę routuje

Po połączeniu potwierdź, że potrzebna trasa istnieje i że nazwy się rozwiązują. Profil istniejący dla zasobów wewnętrznych może celowo zostawiać zwykłe przeglądanie na ścieżce lokalnej, a to decyzja polityki, nie usterka. Liczy się to, czy miejsca docelowe używane przez twój zespół są osiągalne przez tunel.

W Windows dwie komendy obejmują trasę i wyszukiwanie nazw. Odpowiedniki w Linuksie to ip route show default i resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Tunel, który wstaje i nie routuje niczego użytecznego, to częsty wynik, gdy profil skopiowano między usługami, a ogólny test łączności tego nie pokaże, bo interfejs jest podniesiony. Testuj zasób, który twoi użytkownicy otwierają pierwszy, a nie publiczny adres osiągalny dowolną ścieżką. Jeśli nazwa rozwiązuje się na publiczny adres, a trasa wskazuje do wnętrza tunelu, odpowiedź DNS i trasa należą do różnych decyzji i obie wymagają naprawy.

Po kontrolach rozważ utrzymanie

Żaden protokół nie jest bardziej utrzymywalny w sensie abstrakcyjnym. Utrzymanie zależy od tego, kto obsługuje bramę, jak profile docierają do urządzeń i jak szybko zgubione urządzenie traci dostęp. Prosty klient końcowy może stać przed trudniejszym w utrzymaniu serwerem, a bywa też odwrotnie. Zapytaj, który z dwóch twój zespół utrzyma po odejściu osoby, która go zbudowała.

Wybierz obsługiwane połączenie, które pokrywa pracę, a potem przetestuj je wobec dostępu, którego naprawdę potrzebujesz, a nie wobec listy funkcji. Zapisz, na której bramie kończy się każda opcja, bo dwie różne bramy czynią porównanie w równym stopniu sprawą tras, co protokołów. Powtórz cztery kontrole na urządzeniu, które naprawdę będziesz nosić, i zachowaj profil, który je przechodzi.