IKEv2 kontra L2TP/IPsec: który profil działa na twoim serwerze?
Jedna etykieta ukrywa dwa stosy, trzy rodzaje sekretu i inne zachowanie przy zmianie adresu. Rozplącz warstwy, zanim porównasz menu.
Obie nazwy stoją obok siebie w tej samej liście rozwijanej, co zachęca do wyboru między równymi. Nie są równe. L2TP to protokół tunelowania bez własnej poufności, a ochrona w usłudze L2TP/IPsec pochodzi z warstwy IPsec, która go otacza. IKEv2 negocjuje asocjację IPsec bezpośrednio i nie ma kroku tunelu w tunelu. Wiedza o tym, który stos oferuje twój serwer, decyduje o profilu, komunikatach i o tym, co się stanie, gdy laptop zmieni sieć.
Dwa stosy, jedna etykieta w kliencie
L2TP przenosi sesję punkt-punkt przez UDP na port 1701 i zostawia szyfrowanie temu, kto go otacza. Połącz go z IPsec i dostaniesz dwie warstwy: asocjację IPsec chroniącą ścieżkę i wewnątrz niej sesję L2TP przenoszącą ramki warstwy łącza użytkownika oraz uwierzytelnianie PPP.
IKEv2 tworzy asocjację sterującą, a potem jedną lub więcej asocjacji podrzędnych chroniących ruch, wszystko w jednej rodzinie wymian na UDP 500 i 4500. Nie ma wewnętrznego protokołu tunelowania ani negocjacji PPP.
Dane logowania: trzy sekrety na trzech warstwach
Tu znika większość czasu wsparcia. Profil L2TP/IPsec może poprosić o klucz wstępnie współdzielony dla warstwy IPsec oraz nazwę użytkownika i hasło dla wewnętrznej sesji PPP, a jedno i drugie sprawdzają różne komponenty. Współdzielony klucz należy do bramy jako całości, więc nikogo nie identyfikuje; dowodzi tylko, że druga strona zna sekret.
IKEv2 zwykle używa certyfikatów albo EAP z nazwą użytkownika i hasłem, a może też użyć klucza wstępnie współdzielonego. Te opcje nie są wymienne z parą L2TP. Reset hasła, który naprawia odrzucone logowanie EAP, nic nie robi dla wygasłego certyfikatu klienta, a choćbyś wielokrotnie wpisywał hasło konta, błędnego klucza bramy tym nie zaspokoisz. Gdy pojawi się komunikat, którego się nie spodziewałeś, zapytaj operatora, do której warstwy należy, zanim zaczniesz zgadywać.
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
Co zmienia MOBIKE, a czego nie
IKEv2 może przenieść asocjację na nowy adres, gdy oba końce obsługują MOBIKE, co obejmuje przypadek, gdy laptop wychodzi z wifi do hotspota telefonu bez rozbierania asocjacji bezpieczeństwa.
Nie utrzymuje jednak przy tym żywotności każdej aplikacji. Strumień transportowy i tak zmienia adres, gniazda przypisane do starego i tak się psują, a polityka przypinająca ruch do interfejsu i tak może go zgubić. Przetestuj przejście, które naprawdę wykonujesz, czy to opuszczenie sieci, wybudzenie ze snu czy powrót po długim bezczynie, i patrz na aplikację, a nie na etykietę Połączono.
Kształty awarii, które je rozdzielają
Profil L2TP/IPsec, który dociera do bramy i się zatrzymuje, zwykle zawodzi na jednym z dwóch komunikatów: kluczu współdzielonym albo danych PPP. Błędny klucz zwykle nie pokazuje w dzienniku klienta nic użytecznego, natomiast błędne hasło daje wyraźne odrzucenie uwierzytelnienia, i ta różnica mówi ci, gdzie szukać.
Profil IKEv2 zawodzi wcześniej i głośniej, gdy tożsamość lub certyfikat są błędne, bo asocjacja sterująca nigdy się nie kończy. Jeśli asocjacja się kończy, a ruch nadal zawodzi, problem przeniósł się do asocjacji podrzędnej, selektorów ruchu albo trasy, i żadna zmiana danych logowania nie pomoże.
Gdzie każde jeszcze pasuje
L2TP/IPsec trzyma się, bo jest na prawie każdym kliencie i nie wymaga dodatkowego oprogramowania, co ma znaczenie dla wykonawcy na urządzeniu, którym nie zarządzasz. Ceną jest dodatkowa warstwa, model współdzielonego sekretu i ponowne połączenie po każdej zmianie adresu.
IKEv2 lepiej pasuje do urządzeń zarządzanych: tożsamość oparta na certyfikacie, czystsza mobilność i jedna rodzina asocjacji, o której trzeba myśleć. Zawodzi też mocniej, gdy klient jest stary, więc sprawdź obsługiwaną przez platformę metodę uwierzytelniania, zanim zaprojektujesz wokół niej.
Testowanie profilu, który dostałeś
Najpierw potwierdź tryb po stronie serwera, potem wybierz profil klienta, który do niego pasuje. Testuj z dokładną nazwą hosta i poświadczeniami wydanymi dla tego profilu i sprawdzaj zasób prywatny, a nie publiczną witrynę.
Jeśli się łączy i nic nie ładuje, tunel działa, a trasa, DNS albo selektor ruchu nie. Zmiana protokołu w tym momencie restartuje diagnozę zamiast ją posunąć.