GRE-skrivefeil på pptpd er ikkje eit passordproblem

GRE-skrivefeil i loggen, og den fyrste innskya er å nullstilla passordet til brukaren. Den innskya er nesten alltid feil. Desse meldingane skildrar datastien, ikkje kontrollen av innloggingsdata: klienten kan ha autentisert seg med hell og deretter stoppa på trinnet der han registrerer seg på nettet. To ulike meldingar peikar på to ulike feil, og ingen av dei blir løyst med eit nytt passord.

To meldingar, to ulike feil

Ein lesefeil tyder at GRE-pakkane aldri når daemonen, eller blir kasta på veg inn. Kontrollsambandet kan sjå heilt friskt ut medan ingenting kryssar datastien. Autentiseringa er det einaste som provande fungerte.

Ein skrivefeil tyder vanlegvis at økta forhandla fram noko kjernen eller klienten ikkje kan bruka. Kontrollkanalen vart fullført, og alternativa som vart avtalte i den utvekslinga, passar ikkje med det endepunkta faktisk kan gjera. Det er ein konfigurasjonsusemje, ikkje ei autentiseringshending.

Les kva av dei to som dukkar opp før du endrar noko. Dei sender deg til ulike lag, og å handsame dei som eitt symptom er grunnen til at same tenar blir patcha to gonger av urelaterte årsaker. Logglinja er den einaste gratis diagnosen du får.

Protokoll 47 er ikkje port 47

PPTP brukar TCP 1723 for å setja opp anropet og GRE for å bera nyttelasta. GRE er IP-protokoll 47, ikkje eit portnummer, så ein brannmurregel som opnar port 47 tillèt ingenting nyttig.

Ein ruter på vegen treng ein PPTP-passthrough-funksjon eller ei eksplisitt GRE-tillating. Utan det blir TCP-handtrykket fullført, og tunnelen ber aldri ein pakke, noko som gjev nøyaktig lesefeilen ovanfor. Port 47-reglar i ein brannmur er den mest bortkasta ettermiddagen i denne protokollen.

Overvak båe retningane samstundes på tenaren i staden for å gjeta kva side som kastar trafikken: tcpdump -ni any port 1723 or proto gre.

Viss 1723 viser anropsoppsett medan GRE held seg stille, er blokkeringa ovanfor verten. Viss GRE kjem og daemonen framleis feilar, er problemet lokalt, og alternativa er neste stad å sjå.

Tillat GRE der verten faktisk sender vidare

Å setja inn ein forward-regel for GRE er ein rimeleg test på ein vert som sender tunneltrafikk vidare, og det er ikkje ein policy. Ein testregel som godtek alt av éin protokoll, er ein diagnose, ikkje eit design. Lat han stå lenge nok til å læra noko, og byt han deretter ut med ein avgrensa regel.

Legg til ein input-regel for pakkar som er adresserte til tenaren sjølv, fordi forward-kjeda ikkje ser dei. Sjå deretter på regelteljarane før og etter eit tilkopingsforsøk, noko som fortel deg om pakkane i det heile kjem fram.

Gjer regelen varig gjennom brannmortenesta til distribusjonen i staden for å køyre han på nytt etter kvar omstart. På ein nftables-vert brukar du ip protocol gre både i input- og forward-kjeda.

Stadfest at modulen ppp_generic også er lasta, og sjekk om tilkopingssporing kastar retningsreturen. Båe gjev feil som ser ut som eit brannmurproblem og ikkje er det. Ein manglande kjernemodul ser nøyaktig ut som ein blokkert protokoll til du sjekkar.

Tilpass alternativa til klienten du faktisk har

Rettinga frå den andre rapporten ligg i /etc/ppp/pptpd-options, der oppskrifta avviser PAP, CHAP og MSCHAP, kommenterer ut dei tilsvarande require-linjene og held på tilstandsbasert MPPE. Den oppskrifta vart skriven for éin klientblanding, og blind kopiering øydelegg det vanlege tilfellet. Les avvisingslinjene som ei utsegn om kva klientar forfattaren hadde, ikkje som ei tilråding.

Ein Windows-klient treng vanlegvis MS-CHAPv2 med MPPE-128. Hald på desse krava og fjern berre alternativa klienten verkeleg ikkje kan forhandle.

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

Å slå av kryptering for å få ein tilkopling til å lukkast er ei nedgradering, ikkje ein reparasjon. Test ein slik variant på ei laboratorielinje, og gjenopprett deretter krypteringa før tenesta møter ekte klientar. Tilkoplinga som fungerer usikkert, er verre enn den som feilar ærleg.

Les feilnummeret til klienten

Den numeriske koden til klienten snevrar inn trinnet raskare enn tenarloggen. Les han før du les noko anna. 691 tyder at innloggingsdataa vart avviste, 721 tyder at tenaren aldri svara, og 619 tyder at tilkoplinga fall. To minutt med nummeret sparar ein time med konfigurasjonen.

Samanlikn den koden med tenarloggen før du redigerer noko, og test på nytt med same klient etter kvar endring. Elles skjuler ein annan feil seg bak den fyrste, og rettinga ser ineffektiv ut.

Når pålogginga lukkast og ingen trafikk bevegar seg, er GRE framleis den mistenkte. Det er augneblinken for å gå tilbake til fangsten i staden for innloggingsdatalageret.