MSCHAPv2 nie jest protokołem VPN: najpierw zapytaj o tunel
Hasło i słowo MSCHAPv2 nie tworzą połączenia. Zapytaj, który tunel przenosi wymianę, a potem dopasuj do niego profil klienta.
Nazwy użytkowników i hasła podróżują wewnątrz nośnika, a MSCHAPv2 nazywa tylko metodę, która podróżuje. Zapytaj, który tunel go przenosi, zanim wybierzesz profil klienta, bo ten sam ciąg konta pojawia się w układach, które nie dzielą ani jednej linii kodu. Każdy przekazany profil koduje obie decyzje, nawet gdy instrukcja drukuje tylko jedną z nich. Kolejność poniżej to, na co operator potrafi odpowiedzieć bez zgadywania i co możesz sprawdzić bez przechwytywania pakietów.
Uwierzytelnianie jedzie wewnątrz tunelu
VPN podejmuje dwie decyzje, które wyglądają jak jedna: jak strony budują chroniony kanał i jak człowiek dowodzi w nim tożsamości. Druga jest wydrukowana na instrukcji, bo to ją wpisuje człowiek. Pierwsza decyduje, czy w ogóle zadziała jakikolwiek klient, i właśnie ją ludzie pomijają. Poproś operatora, aby najpierw nazwał nośnik, a potem metodę, w tej kolejności. Dwa połączenia mogą wymagać tej samej nazwy konta i tego samego hasła, nie dzieląc pod polem logowania żadnej implementacji.
Dlatego ustawienia skopiowane ze sprawdzonego telefonu kolegi mogą zawieść na twoim, nawet gdy serwer akceptuje oba poświadczenia. Różnicą nigdy nie było poświadczenie; był nią profil, który je otacza. obie strony mają rację i nic się nie łączy to zwykle dokładnie to pomieszanie, i wyjaśnia się, gdy tylko nośnik zostanie nazwany.
Trzy miejsca, w których pojawia się ta sama metoda
W PPP krok uwierzytelniania czeka, aż istnieje łącze, a RFC 2759 definiuje MS-CHAPv2 jako ten krok, dlatego metoda pojawia się w L2TP oraz w starszych wdrożeniach PPTP. Tunel kończy się pierwszy, a negocjacja PPP odbywa się w jego wnętrzu, więc nieudany etap PPP może zostawić tunel jako ustanowiony w dzienniku serwera. Czytaj te dwa etapy osobno, zanim wyciągniesz wniosek, że poświadczenia zostały odrzucone. Klient skonfigurowany pod L2TP może więc być całkowicie poprawny i nadal być niewłaściwym klientem dla bramy, która mówi tylko IKEv2.
IKEv2 zamiast tego umieszcza EAP-MSCHAPv2 wewnątrz wymiany kluczy, więc to samo poświadczenie zawodzi w innym momencie i objawia się jako błąd uwierzytelniania, a nie błąd sesji. Profil IKEv2 platformy Android jest codziennym przykładem i prosi o certyfikat lub identyfikator serwera zamiast opcji PPP. Nazwa konta jest identyczna w obu układach, więc nie powie ci, który masz. Rozstrzyga to tylko lista obsługiwanych protokołów u operatora.
VPN oparty na TLS dodaje trzeci układ, z własnymi polami nazwy użytkownika i hasła i bez MS-CHAPv2 nigdzie w wymianie. Widok pola hasła nie jest więc dowodem na protokół za nim, bo formularz jest zbudowany tak, by wyglądał znajomo. Potwierdź protokół z dokumentacji serwera, a nie z kształtu okna klienta.
Odpowiedzi, których naprawdę potrzebujesz
Wyślij prośbę jako listę, bo na listę trudno odpowiedzieć połowicznie. Poproś o protokół tunelu, metodę w jego wnętrzu i klienta, którego operator obsługuje na twojej platformie. Potem poproś o tożsamość i ustawienia zaufania bramy, format konta i to, co powinno być osiągalne po podniesieniu połączenia.
Pierwsze trzy decydują, czy w ogóle dostaniesz działający profil. Ostatnie trzy decydują, czy ten profil robi to, czego wymaga praca. Trzymaj odpowiedź przy zgłoszeniu, bo następna osoba zada te same sześć pytań. Tam, gdzie brakuje odpowiedzi, traktuj lukę jako decyzję, której operator jeszcze nie podjął, a nie jako coś, co możesz wywnioskować.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
Nie łagodź weryfikacji bramy
Serwer również dowodzi swojej tożsamości klientowi, a ta połowa wymiany nie jest ozdobą. Wyłączenie weryfikacji certyfikatu, aby uparty profil się połączył, akceptuje każdy odpowiadający punkt końcowy, w tym taki, do którego nikt nie zamierzał dotrzeć. Ukrywa też prawdziwą niezgodność zamiast ją rozwiązać, co przesuwa awarię na późniejszy i mniej oczywisty moment. Profil, który wymaga wyłączonej kontroli, wskazuje na coś, czego nie potrafi zweryfikować.
Niezgodność to zwykle nazwa, bo certyfikat wydany dla jednej nazwy hosta zawodzi, gdy profil wybiera adres. Wybieraj nazwę zamiast wyłączać kontrolę. Prywatny urząd certyfikacji zawodzi, gdy urządzenie nigdy nie dostało korzenia, a poprawką jest rozprowadzenie tego korzenia zatwierdzoną drogą. Środowiska zarządzane oczekują, że operator dostarczy tożsamość i kotwicę zaufania, a profil odwoła się do obu. Gdy pola brakuje, poproś o artefakt zamiast rezygnować z weryfikacji.
Dopasuj profil, a potem udowodnij każdy etap
Gdy nośnik jest znany, podążaj za udokumentowanym procesem tego klienta i wpisuj tylko pola, o które prosi. Dodatkowe pola wypełnione dlatego, że istnieją, wciąż są błędnymi wartościami i zawodzą później niż wymagane. Zapisz profil bez zmian po pierwszym udanym połączeniu, aby późniejszą zmianę można było porównać z czymś, o czym wiadomo, że działa.
Następnie sprawdzaj etapami: tunel się ustala, użytkownik się uwierzytelnia, pojawiają się przydzielony adres i trasy, a jedna dozwolona usługa odpowiada. Każdy etap zostawia własną linię dziennika na serwerze, a czytanie ich po kolei zamienia mgliste zgłoszenie w konkretne ustalenie. Jeśli platforma nie obsługuje już układu opisanego przez operatora, to rozmowa o migracji, a nie powód, by włączać na urządzeniu wszystkie stare opcje. Nośnik, metoda i profil to trzy osobne odpowiedzi, a działające połączenie ma wszystkie trzy zgodne.