GRE-skrivfel på pptpd är inte ett lösenordsproblem

GRE-skrivfel i loggen, och den första impulsen är att återställa användarens lösenord. Den impulsen är nästan alltid fel. Dessa meddelanden beskriver datavägen, inte kontrollen av inloggningsuppgifter: klienten kan ha autentiserat sig framgångsrikt och sedan fastnat i steget där den registrerar sig på nätverket. Två olika meddelanden pekar på två olika fel, och inget av dem löses med ett nytt lösenord.

Två meddelanden, två olika fel

Ett läsfel betyder att GRE-paketen aldrig når daemonen eller kastas på vägen in. Kontrollanslutningen kan se helt frisk ut medan ingenting korsar datavägen. Autentiseringen är det enda som bevisligen fungerade.

Ett skrivfel betyder vanligtvis att sessionen förhandlade fram något som kärnan eller klienten inte kan använda. Kontrollkanalen slutfördes, och de alternativ som kom överens i den utväxlingen matchar inte vad ändpunkterna faktiskt kan göra. Det är en konfigurationsoenighet, inte en autentiseringshändelse.

Läs vilket av de två som dyker upp innan du ändrar något. De leder dig till olika lager, och att behandla dem som ett enda symptom är anledningen till att samma server patchas två gånger av orelaterade skäl. Loggraden är den enda gratis diagnosen du får.

Protokoll 47 är inte port 47

PPTP använder TCP 1723 för att ställa upp samtalet och GRE för att bära nyttolasten. GRE är IP-protokoll 47, inte ett portnummer, så en brandväggsregel som öppnar port 47 tillåter ingenting användbart.

En router på vägen behöver en PPTP-passthrough-funktion eller ett uttryckligt GRE-tillstånd. Utan det slutförs TCP-handskakningen och tunneln bär aldrig ett paket, vilket ger precis läsfelsfelet ovan. Regler för port 47 i en brandvägg är den mest bortkastade eftermiddagen i detta protokoll.

Observera båda riktningarna samtidigt på servern i stället för att gissa vilken sida som kastar trafiken: tcpdump -ni any port 1723 or proto gre.

Om 1723 visar samtalsuppkoppling medan GRE förblir tyst, ligger blockeringen ovanför värden. Om GRE anländer och daemonen fortfarande misslyckas är problemet lokalt och alternativen är nästa plats att titta på.

Tillåt GRE där värden faktiskt vidarebefordrar

Att infoga en forward-regel för GRE är ett rimligt test på en värd som vidarebefordrar tunneltrafik, och det är ingen policy. En testregel som accepterar allt av ett protokoll är en diagnos, inte en design. Låt den stå tillräckligt länge för att lära sig något och ersätt den sedan med en avgränsad regel.

Lägg till en input-regel för paket som är adresserade till servern själv, eftersom forward-kedjan inte ser dem. Titta sedan på regelns räknare före och efter ett anslutningsförsök, vilket berättar om paketen ens anländer.

Gör regeln beständig via distributionens brandväggstjänst i stället för att köra den igen efter varje omstart. På en nftables-värd matchar du ip protocol gre både i input- och forward-kedjan.

Bekräfta att modulen ppp_generic också är laddad, och kontrollera om anslutningsspårningen kastar returriktningen. Båda ger fel som ser ut som ett brandväggsproblem och inte är det. En saknad kärnmodul ser exakt ut som ett blockerat protokoll tills du kontrollerar.

Anpassa alternativen till den klient du faktiskt har

Rättelsen från den andra rapporten finns i /etc/ppp/pptpd-options, där receptet avvisar PAP, CHAP och MSCHAP, kommenterar ut motsvarande require-rader och behåller tillståndsbaserad MPPE. Det receptet skrevs för en klientblandning, och blind kopiering förstör det vanliga fallet. Läs avvisningsraderna som ett uttalande om vilka klienter författaren hade, inte som en rekommendation.

En Windows-klient behöver vanligtvis MS-CHAPv2 med MPPE-128. Behåll dessa krav och ta bort bara de alternativ som klienten verkligen inte kan förhandla.

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

Att stänga av kryptering för att en anslutning ska lyckas är en nedgradering, inte en reparation. Testa en sådan variant på en laboratorielänk och återställ sedan krypteringen innan tjänsten möter riktiga klienter. Anslutningen som fungerar osäkert är sämre än den som misslyckas ärligt.

Läs klientens felnummer

Klientens numeriska kod snävar in steget snabbare än serverloggen. Läs den innan du läser något annat. 691 betyder att inloggningsuppgifterna avvisades, 721 betyder att servern aldrig svarade, och 619 betyder att anslutningen föll. Två minuter med numret sparar en timme med konfigurationen.

Jämför den koden med serverloggen innan du redigerar något, och testa igen med samma klient efter varje ändring. Annars gömmer sig ett andra fel bakom det första och rättelsen verkar ineffektiv.

När inloggningen lyckas och ingen trafik rör sig är GRE fortfarande den misstänkta. Det är ögonblicket att gå tillbaka till fångsten i stället för inloggningsuppgiftslagret.