Dlaczego sam PPP CHAP nie może spełnić wymogu MPPE

Profil PPTP, który nalega na szyfrowanie, zwykle zawodzi w tym samym miejscu: PPP zgadza się na wymianę uwierzytelniającą, która nigdy nie wytwarza materiału kluczowego potrzebnego MPPE. Tunel wygląda na półżywy, hasło jest akceptowane, a łącze pada, zanim przejdzie przez nie jakikolwiek ruch. Sięganie do listy rozwijanej CHAP, aż coś się połączy, ukrywa rzeczywisty defekt, a jest nim umowa między metodą uwierzytelniania a polityką ochrony. Poniższe kontrole są uporządkowane tak, aby każda wykluczała tańszą przyczynę niż następna.

W jednym połączeniu PPTP biegną dwie negocjacje

PPTP przenosi zwykłą sesję PPP wewnątrz tunelu GRE, a oba negocjują osobno. Zewnętrzna warstwa decyduje, jak pakiety są kapsułkowane i jaki kanał sterowania istnieje; wewnętrzna sesja PPP decyduje, kto jest partnerem i jaka ochrona jedzie na wierzchu. Dlatego pytanie o hasło dowodzi czegoś tylko o warstwie wewnętrznej, a ukończony uścisk dłoni warstwy zewnętrznej nie dowodzi niczego o żadnej z nich. Profile zawodzą tutaj, bo ludzie debugują tunel, podczas gdy niezgodność siedzi wewnątrz PPP.

Zwykły CHAP to wymiana typu wyzwanie-odpowiedź z RFC 1994, zbudowana na wspólnym sekrecie i niczym więcej. MS-CHAPv2 to inna wymiana, z innymi komunikatami i innym wynikiem, znormalizowana w RFC 2759. Wspólne słowo w obu nazwach to jedyna rzecz, którą mają wspólną na przewodzie. Żadna nazwa nie mówi, co wytwarza wymiana, a to jedyna część, która ma znaczenie.

Dlatego opcja oznaczona po prostu jako CHAP jest niejednoznaczna w starym profilu. Gdy serwer chce MS-CHAPv2, a klient oferuje zwykły CHAP, kontrola łącza wciąż może się zakończyć i hasło wciąż może zostać przyjęte. Błąd przychodzi później, gdy serwer próbuje wyprowadzić klucze ochrony z wymiany, która nic nie wytworzyła.

Dopasuj wymaganą metodę do kluczy, które może wytworzyć

Klucze MPPE nie są ogólną właściwością PPP. Dla rodziny Microsoft CHAP wyprowadzanie jest określone w RFC 3079 i przyjmuje jako wejście wynik wymiany MS-CHAP, a nie wspólny sekret. Metody EAP docierają w to samo miejsce inną drogą, przy czym serwer uwierzytelniania zwraca klucze jako atrybuty MS-MPPE-Recv-Key i MS-MPPE-Send-Key. Zwykły CHAP nie występuje na żadnej z tych dróg i to jest cały powód istnienia tej niezgodności.

Konfiguracja, która wymaga MPPE, a jednocześnie odrzuca każdą metodę zdolną dostarczyć klucze, jest wewnętrznie sprzeczna. pppd rozwiązuje tę sprzeczność, odrzucając łącze, a nie wymyślając klucze, więc widocznym wynikiem jest sesja, która się uwierzytelnia, a następnie kończy w fazie sieciowej. Ponawianie po stronie klienta tego nie zmieni, dopóki serwer odrzuca jedyne metody, które coś wyprowadzają.

Wynikająca z tego zasada jest krótka: jeśli profil wymaga MPPE, metoda musi być wariantem MS-CHAP albo metodą EAP, której klucze serwer zwraca. Odrzucenie samego MS-CHAPv2 tego nie wymusza, bo MS-CHAPv1 też wyprowadza klucze i pozostaje dostępny, o ile nie zostanie odrzucony osobno; odrzucenie obu zostawia zwykły CHAP i PAP, które nic nie wyprowadzają i czynią wymóg niespełnialnym. Nazwij akceptowaną metodę wprost, zamiast wyliczać te, których nie lubisz. Rezygnacja z wymogu szyfrowania, by klient się połączył, jest obniżeniem, a nie naprawą.

Przeczytaj opcje serwera, zanim zaczniesz edytować klienta

Większość tych niezgodności jest widoczna na serwerze w dwóch plikach, a ich przeczytanie kosztuje mniej niż przebudowa klienta. Na punkcie końcowym PPTP w Linuksie odpowiednie ustawienia żyją w pliku opcji pppd, który przekazuje pptpd. Uruchom to na serwerze, a nie z ekranu stanu klienta. Zacznij od linii, które wymagają, odrzucają lub nazywają tryb ochrony:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Czytaj wyjście jako umowę, a nie jako listę flag. Linii, która wymaga MPPE, a jednocześnie odrzuca oba warianty MS-CHAP, nie może spełnić żaden klient, a brakujący wymóg dla metody MS-CHAP zostawia drzwi otwarte na wymiany, które nie dają kluczy. Następnie sprawdź, komu w ogóle wolno się uwierzytelniać, co rozstrzyga plik sekretów:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Zapisz trzy wartości, zanim cokolwiek zmienisz: protokół zewnętrzny, metodę uwierzytelniania wymaganą przez serwer oraz to, czy ochrona jest obowiązkowa, czy opcjonalna. Te trzy wyznaczają każdą późniejszą decyzję, a zgadywanie ich z okna klienta to droga, na której profil kończy jako na wpół skonfigurowany. Trzymaj plik otwarty podczas pracy, bo następna sekcja potrzebuje tych samych trzech wartości.

Zlokalizuj błąd według fazy PPP

PPP zgłasza błędy w fazach, a faza mówi, która klauzula umowy została złamana. Łącze, które nigdy nie opuszcza kontroli łącza, ma problem z kapsułkowaniem lub negocjacją, a to, które się uwierzytelnia i potem umiera, zwykle ma problem z polityką lub kluczem. Łącze, które zostaje podniesione i nic nie przenosi, przeszło do routingu, co jest innym śledztwem.

Dziennik zachowuje linie faz, a są one użyteczniejsze niż wyższy poziom debugowania. Poproś o procesy PPP i komunikaty ochrony, a potem odczytaj wynik uwierzytelniania przed wszystkim innym. Ostatnie linie zwykle nazywają klauzulę, która odrzuciła:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

W tym wyjściu najpierw szukaj wyniku uwierzytelniania, a potem skargi, że ochrona była wymagana, ale nie została wynegocjowana. Drugi komunikat jest podpisem powyższej sprzeczności i żadna liczba ponownych prób go nie usunie, dopóki serwer odrzuca jedyną metodę zdolną wytworzyć klucze. Warto nazwać dwie pułapki: podnoszenie poziomu debugowania bez czytania linii faz tworzy szum, a przechwytywanie materiału wyzwania lub haseł zamienia zadanie konfiguracyjne w wyciek danych logowania. Zapisz tę fazę, zanim zmienisz jakąkolwiek opcję.

Zaplanuj wyjście, zanim stary punkt końcowy zostanie wyłączony

MPPE to historyczny mechanizm ochrony łącza, a jego obecność nie czyni PPTP rozsądnym wyborem dla nowego wdrożenia. Obecne wytyczne Microsoftu już odradzają PPTP oraz L2TP/IPsec ze wstępnie współdzielonym kluczem w nowych wdrożeniach dostępu zdalnego. Utrzymywanie starego punktu końcowego przy życiu to decyzja o istniejącej usłudze, a nie szablon dla następnej.

Gdy punkt końcowy musi zostać, zapisz umowę: protokół zewnętrzny, wymaganą metodę uwierzytelniania, obowiązkową ochronę i wersję klienta, która ją negocjuje. Gdy może odejść, wybierz tożsamość bramy zamiennika, jego uwierzytelnianie klienta i miejsce, w którym będą żyć dane logowania, zanim dotkniesz starego profilu. Następnie zaplanuj trasy, DNS i zasoby, do których każdy użytkownik jest uprawniony. Zweryfikuj zamierzonego klienta wobec wymagań właściciela, a nie wobec działającego połączenia.

Celowa odmowa powinna pozostać odmową, bo powrót do trybu bez ochrony, by test przeszedł, zamienia porażkę polityki w ekspozycję. Stan końcowy to wspierana, udokumentowana umowa, a nie najmniejszy zestaw zmian, który pozwala jednej starej sesji się udać. Zostaw stary profil na miejscu, nieużywany i udokumentowany, dopóki zamiennik nie przejdzie tych samych kontroli.