PPTP twierdzi, że hasło jest błędne: która poprawka przychodzi pierwsza?

Profile PPTP, które upierają się, że hasło jest błędne, mówią coś węższego, niż to brzmi. Sekret jest sprawdzany na samym końcu łańcucha, który zaczyna się od negocjacji możliwości, więc każde niezgodność wcześniej w tym łańcuchu ujawnia się jako błąd uwierzytelniania. Dlatego resetowanie hasła, wpisywanie go ponownie ani tworzenie profilu od nowa niczego nie zmienia. Najpierw przeczytaj negocjację, potem wybierz poprawkę zależnie od tego, jak dużą część ścieżki kontrolujesz.

Dlaczego sekret nigdy nie jest sprawdzany

Uwierzytelnianie PPP jest negocjowane: serwer proponuje metody, klient odpowiada tym, co potrafi, i obie strony uzgadniają jedną, zanim zostaną wymienione jakiekolwiek dane logowania. Gdy serwer oferuje tylko EAP-PEAP, a pppd klienta go nie implementuje, rozmowa kończy się na etapie propozycji. Serwer zapisuje błąd uwierzytelniania, bo to ten etap zawiódł, a nie dlatego, że hasło zostało porównane i uznane za niewystarczające.

Dlatego błąd jest identyczny przy błędnym haśle i przy niezgodności metody. Tylko dziennik je rozróżnia, i to tylko wtedy, gdy klient może być szczegółowy.

Czytaj negocjację, nie ostatni błąd

Uruchom połączenie na pierwszym planie z włączonym debugowaniem i czytaj wiersze uwierzytelniania od góry. Dziennik podaje proponowaną metodę, przyjętą metodę i miejsce, w którym wymiana się zatrzymała. Profil, który nigdy nie wychodzi z CHAP lub MSCHAPv2, podczas gdy serwer oczekuje PEAP, to problem metody, a nie danych logowania. Ostatni wiersz tego dziennika to miejsce, w którym klient się poddał, a nie miejsce, w którym jest przyczyna.

sudo pppd call provider debug nodetach

Zachowaj ten wynik. To także dowód, którego właściciel sieci potrzebuje przed zmianą polityki serwera, i rozstrzyga pytanie, czy hasło w ogóle było w grze.

Druga przyczyna kryje się w pliku sekretów

Jeśli dziennik pokazuje, że metody się zgadzają, spójrz na plik przechowujący sekret. Znak nowej linii lub spacja na końcu wpisane w pole hasła są wysyłane jako część hasła, więc serwer porównuje inny ciąg niż ten, który wpisałeś. Plik wygląda poprawnie w edytorze i właśnie dlatego przeżywa tyle prób.

sudo cat -A /etc/ppp/chap-secrets

Znak dolara oznacza koniec każdego wiersza w tym wyniku. Pole hasła z czymkolwiek przed tym znakiem albo zabłąkana spacja między polami wymaga przepisania z cudzysłowami, które dokumentuje narzędzie.

Wybierz poprawkę zależnie od tego, do kogo należy serwer

Jeśli serwer jest twój, zezwolenie na MSCHAPv2 dla tego konta to najmniejsza zmiana, i powinieneś zanotować, że świadomie zaakceptowałeś słabszą metodę. Jeśli należy do kogoś innego, uczciwą poprawką jest klient implementujący EAP-PEAP; łatanie pppd czyni niezgodność twoim problemem konserwacyjnym. Jeśli wybór protokołu jest nadal otwarty, PPTP jest najsłabszą częścią projektu, a migracja zwykle kosztuje mniej niż utrzymywanie załatanego klienta przy życiu. Zapisz tę decyzję obok profilu, aby następna osoba nie otwierała jej ponownie.

Niezależnie od wybranej drogi przetestuj potem z drugiej maszyny w innej sieci. Zapisany profil może nadal oferować starą metodę i sprawiać, że poprawiony serwer wygląda na zepsuty. Następnie usuń ustawienie debugowania, ponieważ szczegółowe dzienniki PPP mogą na współdzielonej stacji roboczej przechwycić więcej, niż chcesz.