GRE greške pisanja na pptpd nisu problem s lozinkom
Protokol 47 nije port 47. Čitajte dvije pptpd poruke kao dvije različite greške, dozvolite GRE gdje host prosljeđuje i zadržite MPPE umjesto da ga isključite.
Greška pisanja GRE u logu, a prvi instinkt je resetirati korisničku lozinku. Taj instinkt je gotovo uvijek pogrešan. Ove poruke opisuju putanju podataka, a ne provjeru vjerodajnica: klijent se možda uspješno autentificirao i zatim se zaustavio u fazi u kojoj se registrira na mreži. Dvije različite poruke ukazuju na dvije različite greške i nijedna se ne rješava novom lozinkom.
Dvije poruke, dvije različite greške
Greška čitanja znači da GRE paketi nikada ne stignu do demona ili se odbacuju na ulazu. Kontrolna veza može izgledati potpuno zdravo dok ništa ne prelazi putanju podataka. Autentifikacija je jedina stvar koja je dokazivo radila.
Greška pisanja obično znači da je sesija pregovarala nešto što jezgro ili klijent ne može koristiti. Kontrolni kanal je završen, a opcije dogovorene tijekom te razmjene ne odgovaraju onome što krajnje točke zapravo mogu raditi. To je neslaganje u konfiguraciji, a ne događaj autentifikacije.
Pročitajte koja se od dvije pojavljuje prije nego što išta promijenite. One vas vode na različite slojeve, a tretiranje kao jednog simptoma razlog je zašto se isti server krpa dva puta iz nepovezanih razloga. Linija u logu jedina je besplatna dijagnostika koju dobivate.
Protokol 47 nije port 47
PPTP koristi TCP 1723 za uspostavu poziva i GRE za prijenos korisnog tereta. GRE je IP protokol 47, a ne broj porta, pa firewall pravilo koje otvara port 47 ne dopušta ništa korisno.
Usmjerivač na putu treba PPTP passthrough značajku ili izričito dopuštenje za GRE. Bez toga TCP rukovanje završava i tunel nikada ne prenosi paket, što proizvodi točno gornju grešku čitanja. Pravila za port 47 u firewallu najčešće su protraćeno poslijepodne u ovom protokolu.
Promatrajte oba smjera istovremeno na serveru umjesto da nagađate koja strana odbacuje promet: tcpdump -ni any port 1723 or proto gre.
Ako 1723 pokazuje uspostavu poziva dok GRE ostaje tih, blokada je iznad hosta. Ako GRE stiže, a demon i dalje pada, problem je lokalni i opcije su sljedeće mjesto za pregled.
Dozvolite GRE gdje host stvarno prosljeđuje
Umetanje forward pravila za GRE razuman je test na hostu koji prosljeđuje tunelski promet i nije politika. Testno pravilo koje prihvaća sve jednog protokola je dijagnostika, a ne dizajn. Ostavite ga dovoljno dugo da nešto naučite, zatim ga zamijenite ograničenim pravilom.
Dodajte input pravilo za pakete upućene samom serveru, jer forward lanac ih ne vidi. Zatim gledajte brojače pravila prije i poslije pokušaja veze, što vam kaže dolaze li paketi uopće.
Trajno sačuvajte pravilo kroz firewall uslugu distribucije umjesto da ga ponovno pokrećete nakon svakog podizanja. Na nftables hostu uskladite ip protocol gre u input i forward lancu.
Potvrdite da je i modul ppp_generic učitan te provjerite odbacuje li praćenje veza povratni smjer. Oba stvaraju kvarove koji izgledaju kao firewall problem i nisu. Modul jezgre koji nedostaje izgleda točno kao blokirani protokol dok ne provjerite.
Uskladite opcije s klijentom koji stvarno imate
Ispravak iz drugog izvještaja nalazi se u /etc/ppp/pptpd-options, gdje recept odbija PAP, CHAP i MSCHAP, komentira odgovarajuće require linije i zadržava stateful MPPE. Taj je recept napisan za jednu mješavinu klijenata i slijepo kopiranje kvari uobičajeni slučaj. Čitajte linije odbijanja kao izjavu o tome koje je klijente autor imao, a ne kao preporuku.
Windows klijent obično treba MS-CHAPv2 s MPPE-128. Zadržite te zahtjeve i uklonite samo opcije koje klijent stvarno ne može pregovarati.
# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128Isključivanje enkripcije da bi veza uspjela je degradacija, a ne popravak. Testirajte takvu varijantu na laboratorijskoj vezi, zatim vratite enkripciju prije nego se usluga suoči s pravim klijentima. Veza koja radi nesigurno gora je od one koja pošteno pada.
Pročitajte broj greške klijenta
Numerički kod klijenta sužava fazu brže nego serverski log. Pročitajte ga prije bilo čega drugog. 691 znači da su vjerodajnice odbijene, 721 znači da server nikada nije odgovorio, a 619 znači da je veza prekinuta. Dvije minute s brojem štede sat s konfiguracijom.
Usporedite taj kod sa serverskim logom prije bilo kakvog uređivanja i ponovno testirajte istim klijentom nakon svake promjene. Inače se druga greška skriva iza prve i popravak izgleda nedjelotvorno.
Kada prijava uspije i promet se ne kreće, GRE ostaje osumnjičeni. To je trenutak da se vratite snimanju, a ne spremištu vjerodajnica.