Wspólny sekret vpnc czy twoje logowanie: które pole co przyjmuje?
Profil vpnc prosi o ID grupy, wspólny sekret grupy i logowanie XAuth, a ludzie wpisują hasło konta w niewłaściwe pole. Przypisz każde pole do jego roli.
Gdy ktoś po raz pierwszy daje ci profil vpnc, okno danych logowania pyta o cztery rzeczy i czyta się, jakby chciało jednego hasła. Nie chce: wspólny sekret grupy i indywidualne logowanie XAuth to osobne wartości z osobnymi właścicielami, a wpisanie hasła konta w polu grupy daje błąd, który wygląda jak złe hasło, a nie jak niewłaściwe pole. Właściwe odwzorowanie to całe zadanie. Protokół pod spodem jest projektem migracji kogoś innego, dlatego nic z tego nie jest argumentem za budowaniem nowych tuneli IKEv1.
Dwa sekrety, dwóch właścicieli, jedno okno
Wspólny sekret grupy należy do profilu bramy. Wszyscy, którzy łączą się przez ten profil, używają tej samej wartości, i właśnie dlatego nie może ona zidentyfikować osoby ani zostać odebrana jednemu laptopowi bez zmiany jej dla wszystkich pozostałych użytkowników profilu. Nazwa użytkownika i hasło XAuth należą natomiast do człowieka, a brama ocenia je w drugim etapie, gdy asocjacja IPsec jest już nawiązana.
To właśnie tę dwuetapową formę ludzie przeoczają. Nawiązanie tunelu i uwierzytelnienie użytkownika to różne wymiany z różnymi danymi wejściowymi, więc klient, który nigdy nie dociera do monitu o dane logowania, wcale nie poniósł porażki na logowaniu. Czytaj okno jako dwie kolumny, a nie jedną: wartości całego profilu po lewej, wartości osobiste po prawej. Gdy połączenie zawodzi, kolumna wypełniona ostatnio nie jest automatycznie tą winną.
Przypisz pola do roli, a nie do etykiety
vpnc nazywa swoje dyrektywy w dokumentacji projektu, a każdy interfejs graficzny nadaje im nowe nazwy. Przetłumacz rolę każdej wartości, a etykiety przestaną mieć znaczenie:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Interfejs, który obok pola grupy pokazuje „Nazwę użytkownika” i „Hasło”, nie jest błędny — to te same trzy wartości pod innymi nazwami. Psuje się to, gdy pole zostaje wypełnione, bo wartość do niego pasuje. Wspólny sekret grupy wklejony jako hasło użytkownika uwierzytelnia profil i potem zawodzi na etapie użytkownika; hasło konta wklejone jako wspólny sekret grupy zawodzi wcześniej, przed jakimkolwiek monitem, i wysyła ludzi do szukania problemu w zaporach ogniowych, choć mieszka on w polu tekstowym.
Czym nie jest identyfikator grupy
Słowo grupa skłania do błędnego odczytu. Identyfikator grupy jest tu selektorem, który mówi bramie, którą konfigurację profilu zastosować; nie mówi nic o członkostwie w katalogu, a zgodna nazwa po obu stronach jest przypadkiem, dopóki operator tego nie potwierdzi. Autoryzacja następuje po udanym XAuth, decyduje o niej to, z czym brama jest skonfigurowana się konsultować, i nic z tego nie jest widoczne w oknie klienta.
Ta sama ostrożność dotyczy wspólnego sekretu grupy. Znajomość go nie jest tożsamością, a krążenie jednego sekretu w zespole to decyzja operacyjna o skutkach, których klient nie może ci pokazać.
Rozstrzygnij niejednoznaczną instrukcję przed połączeniem
Stare notatki przekazania często zawierają wiersz typu „użyj dedykowanego publicznego IP”. To sformułowanie może oznaczać adres, z którego lista dozwolonych po drugiej stronie oczekuje przyjścia twojego ruchu, to właściwość wyjścia sieci operatora i nie ma nic wspólnego z punktem końcowym, który wpisujesz w polu bramy. Zapytaj, o który z dwóch chodzi, zanim wartość gdziekolwiek trafi. Wpisane odwrotnie wysyła każdy pakiet na adres, który nigdy nie odpowiada, a wynikający z tego limit czasu czyta się jak zablokowany port.
Poproś o cztery rzeczy zweryfikowanym kanałem organizacji: który klient i protokół są obsługiwane, którego punktu końcowego użyć, jaką tożsamość przedstawi brama i jak przekazywane są dane logowania. Trzymaj prawdziwe sekrety poza zrzutami ekranu, zgłoszeniami i współdzielonymi notatkami z rozwiązywania problemów. Nie wyłączaj sprawdzania certyfikatów i nie wklejaj starej listy szyfrów, aby inaczej skonfigurowana usługa wyglądała na zgodną, bo połączenie działające tylko przez osłabienie weryfikacji nie jest połączeniem, o którego zbudowanie proszono.
Zachowaj uczciwość starego profilu
IKEv1 jest przestarzały, a RFC 9395 to dokument, który się cytuje, gdy pojawia się kwestia migracji. Udane odwzorowanie pól nie jest dowodem, że protokół należy do nowego projektu; kupuje ono działające połączenie, dopóki zaplanowana jest wymiana, plus pisemny zakres i właściciela tej migracji.
Potem weryfikuj względem wymagania, a nie względem okna. Po połączeniu potwierdź, że interfejs tunelu ma oczekiwany adres i że wewnętrzny cel jest routowany przez niego; jeśli pierwotne wymaganie wskazywało adres wyjściowy dla listy dozwolonych, potwierdź także ten adres, bo to inny fakt niż samo działanie tunelu. Profil, który poprawnie się uwierzytelnia i nic nie routuje, wciąż nie wykonał zadania, dla którego powstał.