GRE-skrivefeil på pptpd er ikke et passordproblem

GRE-skrivefeil i loggen, og den første innskytelsen er å tilbakestille brukerens passord. Den innskytelsen er nesten alltid feil. Disse meldingene beskriver datastien, ikke legitimasjonskontrollen: klienten kan ha autentisert seg vellykket og deretter stoppet på trinnet der den registrerer seg på nettverket. To forskjellige meldinger peker på to forskjellige feil, og ingen av dem løses med et nytt passord.

To meldinger, to forskjellige feil

En lesefeil betyr at GRE-pakkene aldri når daemonen, eller at de forkastes på vei inn. Kontrollforbindelsen kan se helt sunn ut mens ingenting krysser datastien. Autentiseringen er det eneste som beviselig fungerte.

En skrivefeil betyr vanligvis at sesjonen forhandlet frem noe kjernen eller klienten ikke kan bruke. Kontrollkanalen ble fullført, og alternativene som ble avtalt i den utvekslingen, passer ikke med det endepunktene faktisk kan gjøre. Det er en konfigurasjonsuenighet, ikke en autentiseringshendelse.

Les hvilken av de to som vises før du endrer noe. De sender deg til forskjellige lag, og å behandle dem som ett symptom er grunnen til at samme server patches to ganger av urelaterte årsaker. Logglinjen er den eneste gratis diagnosen du får.

Protokoll 47 er ikke port 47

PPTP bruker TCP 1723 for å sette opp anropet og GRE for å bære nyttelasten. GRE er IP-protokoll 47, ikke et portnummer, så en brannmurregel som åpner port 47 tillater ingenting nyttig.

En ruter på veien trenger en PPTP-passthrough-funksjon eller en eksplisitt GRE-tillatelse. Uten den fullføres TCP-håndtrykket, og tunnelen bærer aldri en pakke, noe som gir nøyaktig lesefeilen ovenfor. Port 47-regler i en brannmur er den mest bortkastede ettermiddagen i denne protokollen.

Overvåk begge retninger samtidig på serveren i stedet for å gjette hvilken side som forkaster trafikk: tcpdump -ni any port 1723 or proto gre.

Hvis 1723 viser anropsoppsett mens GRE forblir stille, er blokkeringen ovenfor verten. Hvis GRE ankommer og daemonen fortsatt feiler, er problemet lokalt, og alternativene er neste sted å se.

Tillat GRE der verten faktisk videresender

Å sette inn en forward-regel for GRE er en rimelig test på en vert som videresender tunneltrafikk, og det er ikke en policy. En testregel som godtar alt av én protokoll, er en diagnose, ikke et design. La den stå lenge nok til å lære noe, og erstatt den deretter med en avgrenset regel.

Legg til en input-regel for pakker som er adressert til serveren selv, fordi forward-kjeden ikke ser dem. Se deretter på regeltellerne før og etter et tilkoblingsforsøk, noe som forteller deg om pakkene i det hele tatt ankommer.

Gjør regelen varig gjennom distribusjonens brannmurtjeneste i stedet for å kjøre den på nytt etter hver omstart. På en nftables-vert bruker du ip protocol gre både i input- og forward-kjeden.

Bekreft at modulen ppp_generic også er lastet, og sjekk om tilkoblingssporing forkaster returretningen. Begge gir feil som ser ut som et brannmurproblem og ikke er det. En manglende kjernemodul ser nøyaktig ut som en blokkert protokoll til du sjekker.

Tilpass alternativene til klienten du faktisk har

Rettingen fra den andre rapporten ligger i /etc/ppp/pptpd-options, der oppskriften avviser PAP, CHAP og MSCHAP, kommenterer ut de tilsvarende require-linjene og beholder tilstandsbasert MPPE. Den oppskriften ble skrevet for én klientblanding, og blind kopiering ødelegger det vanlige tilfellet. Les avvisningslinjene som en uttalelse om hvilke klienter forfatteren hadde, ikke som en anbefaling.

En Windows-klient trenger vanligvis MS-CHAPv2 med MPPE-128. Behold disse kravene og fjern bare alternativene klienten virkelig ikke 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å en tilkobling til å lykkes er en nedgradering, ikke en reparasjon. Test en slik variant på en laboratorielinje, og gjenopprett deretter krypteringen før tjenesten møter ekte klienter. Tilkoblingen som fungerer usikkert, er verre enn den som feiler ærlig.

Les klientens feilnummer

Klientens numeriske kode snevrer inn trinnet raskere enn serverloggen. Les den før du leser noe annet. 691 betyr at legitimasjonen ble avvist, 721 betyr at serveren aldri svarte, og 619 betyr at tilkoblingen falt. To minutter med nummeret sparer en time med konfigurasjonen.

Sammenlign den koden med serverloggen før du redigerer noe, og test på nytt med samme klient etter hver endring. Ellers skjuler en annen feil seg bak den første, og rettingen ser ineffektiv ut.

Når påloggingen lykkes og ingen trafikk beveger seg, er GRE fortsatt den mistenkte. Det er øyeblikket for å gå tilbake til fangsten i stedet for legitimasjonslageret.