Błędy zapisu GRE na pptpd to nie problem z hasłem

Błąd zapisu GRE w logu, a pierwszy odruch to zresetowanie hasła użytkownika. Ten odruch jest prawie zawsze błędny. Te komunikaty opisują ścieżkę danych, a nie sprawdzanie poświadczeń: klient mógł pomyślnie się uwierzytelnić, a następnie zatrzymać się na etapie, w którym rejestruje się w sieci. Dwa różne komunikaty wskazują na dwa różne uszkodzenia i żadnego nie rozwiązuje nowe hasło.

Dwa komunikaty, dwa różne uszkodzenia

Błąd odczytu oznacza, że pakiety GRE nigdy nie docierają do demona albo są odrzucane przy wejściu. Połączenie sterujące może wyglądać całkowicie zdrowo, podczas gdy nic nie przechodzi ścieżką danych. Uwierzytelnianie to jedyna rzecz, która udowodnialnie działała.

Błąd zapisu zwykle oznacza, że sesja wynegocjowała coś, czego jądro lub klient nie mogą użyć. Kanał sterujący się zakończył, a opcje uzgodnione podczas tej wymiany nie odpowiadają temu, co punkty końcowe naprawdę potrafią. To niezgodność konfiguracji, a nie zdarzenie uwierzytelnienia.

Przeczytaj, który z dwóch się pojawia, zanim cokolwiek zmienisz. Prowadzą do różnych warstw, a traktowanie ich jako jednego objawu jest powodem, dla którego ten sam serwer jest łatany dwa razy z niepowiązanych przyczyn. Linia logu to jedyna darmowa diagnostyka, jaką dostajesz.

Protokół 47 to nie port 47

PPTP używa TCP 1723 do zestawienia połączenia, a GRE do przenoszenia ładunku. GRE to protokół IP 47, nie numer portu, więc reguła zapory, która otwiera port 47, nie zezwala na nic użytecznego.

Router na ścieżce potrzebuje funkcji passthrough PPTP albo wyraźnego zezwolenia na GRE. Bez tego uzgadnianie TCP się kończy, a tunel nigdy nie przenosi pakietu, co daje dokładnie powyższy błąd odczytu. Reguły portu 47 w zaporze to najczęściej zmarnowane popołudnie w tym protokole.

Obserwuj oba kierunki jednocześnie na serwerze, zamiast zgadywać, która strona odrzuca ruch: tcpdump -ni any port 1723 or proto gre.

Jeśli 1723 pokazuje zestawianie połączenia, a GRE milczy, blokada jest powyżej hosta. Jeśli GRE dociera, a demon nadal zawodzi, problem jest lokalny i opcje są następnym miejscem do sprawdzenia.

Zezwól na GRE tam, gdzie host naprawdę przekazuje

Wstawienie reguły forward dla GRE to rozsądny test na hoście, który przekazuje ruch tunelowy, i nie jest to polityka. Reguła testowa, która akceptuje wszystko jednego protokołu, jest diagnostyką, nie projektem. Zostaw ją wystarczająco długo, by się czegoś nauczyć, a potem zastąp regułą ograniczoną.

Dodaj regułę input dla pakietów adresowanych do samego serwera, bo łańcuch forward ich nie widzi. Potem obejrzyj liczniki reguły przed próbą połączenia i po niej, co mówi ci, czy pakiety w ogóle docierają.

Utrwal regułę przez usługę zapory dystrybucji, zamiast uruchamiać ją ponownie po każdym restarcie. Na hoście nftables dopasuj ip protocol gre zarówno w łańcuchu input, jak i forward.

Potwierdź, że moduł ppp_generic też jest załadowany, i sprawdź, czy śledzenie połączeń odrzuca kierunek powrotny. Oba dają błędy, które wyglądają jak problem z zaporą i nimi nie są. Brakujący moduł jądra wygląda dokładnie jak zablokowany protokół, dopóki tego nie sprawdzisz.

Dopasuj opcje do klienta, którego naprawdę masz

Poprawka z drugiego raportu jest w /etc/ppp/pptpd-options, gdzie przepis odrzuca PAP, CHAP i MSCHAP, komentuje odpowiednie linie require i zachowuje MPPE ze stanem. Ten przepis napisano dla jednej mieszanki klientów, a ślepe kopiowanie psuje typowy przypadek. Czytaj linie odrzucenia jako stwierdzenie o klientach autora, a nie jako zalecenie.

Klient Windows zwykle potrzebuje MS-CHAPv2 z MPPE-128. Zachowaj te wymagania i usuń tylko te opcje, których klient naprawdę nie może wynegocjować.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Wyłączenie szyfrowania, aby połączenie się udało, jest degradacją, nie naprawą. Przetestuj taki wariant na łączu laboratoryjnym, a potem przywróć szyfrowanie, zanim usługa spotka prawdziwych klientów. Połączenie, które działa niebezpiecznie, jest gorsze od tego, które uczciwie zawodzi.

Przeczytaj numer błędu klienta

Kod numeryczny klienta zawęża etap szybciej niż log serwera. Przeczytaj go, zanim przeczytasz cokolwiek innego. 691 oznacza, że poświadczenia zostały odrzucone, 721 oznacza, że serwer nigdy nie odpowiedział, a 619 oznacza, że połączenie się urwało. Dwie minuty z numerem oszczędzają godzinę z konfiguracją.

Porównaj ten kod z logiem serwera, zanim cokolwiek edytujesz, i po każdej zmianie testuj ponownie tym samym klientem. Inaczej drugie uszkodzenie chowa się za pierwszym i poprawka wygląda na nieskuteczną.

Gdy logowanie się udaje, a ruch się nie porusza, GRE pozostaje podejrzanym. To moment, by wrócić do przechwytu, a nie do magazynu poświadczeń.