GRE-schrijffouten op pptpd zijn geen wachtwoordprobleem

GRE-schrijffout in het log, en de eerste reflex is het wachtwoord van de gebruiker resetten. Die reflex is bijna altijd fout. Deze meldingen beschrijven het datapad, niet de controle van inloggegevens: de client kan zich succesvol hebben aangemeld en daarna zijn blijven steken in de fase waarin hij zich op het netwerk registreert. Twee verschillende meldingen wijzen op twee verschillende storingen, en geen van beide wordt opgelost met een nieuw wachtwoord.

Twee meldingen, twee verschillende storingen

Een leesfout betekent dat de GRE-pakketten de daemon nooit bereiken, of onderweg naar binnen worden weggegooid. De controleverbinding kan er volkomen gezond uitzien terwijl er niets over het datapad gaat. De authenticatie is het enige dat aantoonbaar werkte.

Een schrijffout betekent meestal dat de sessie iets is overeengekomen dat de kernel of de client niet kan gebruiken. Het controlekanaal is voltooid, en de opties die tijdens die uitwisseling zijn afgesproken passen niet bij wat de eindpunten echt kunnen. Dat is een configuratieverschil, geen authenticatiegebeurtenis.

Lees welke van de twee verschijnt voordat je iets verandert. Ze sturen je naar verschillende lagen, en ze als één symptoom behandelen is de reden dat dezelfde server twee keer wordt gepatcht om ongerelateerde redenen. De logregel is de enige gratis diagnose die je krijgt.

Protocol 47 is niet poort 47

PPTP gebruikt TCP 1723 om de oproep op te zetten en GRE om de lading te dragen. GRE is IP-protocol 47, geen poortnummer, dus een firewallregel die poort 47 opent staat niets nuttigs toe.

Een router in het pad heeft een PPTP-passthroughfunctie of een expliciete GRE-toestemming nodig. Zonder dat voltooit de TCP-handshake en draagt de tunnel nooit een pakket, wat precies de leesfout hierboven oplevert. Poort 47-regels in een firewall zijn de meest verspilde middag in dit protocol.

Bekijk beide richtingen tegelijk op de server in plaats van te gokken welke kant het verkeer weggooit: tcpdump -ni any port 1723 or proto gre.

Als 1723 het opzetten van de oproep laat zien terwijl GRE stil blijft, zit de blokkade boven de host. Als GRE aankomt en de daemon faalt nog steeds, is het probleem lokaal en zijn de opties de volgende plek om te kijken.

Sta GRE toe waar de host echt doorstuurt

Een forward-regel voor GRE invoegen is een redelijke test op een host die tunnelverkeer doorstuurt, en het is geen beleid. Een testregel die alles van één protocol accepteert is een diagnose, geen ontwerp. Laat hem lang genoeg staan om iets te leren en vervang hem daarna door een beperkte regel.

Voeg een input-regel toe voor pakketten die aan de server zelf zijn gericht, omdat de forward-keten ze niet ziet. Kijk daarna naar de tellers van de regel voor en na een verbindingspoging, wat je vertelt of de pakketten überhaupt aankomen.

Maak de regel permanent via de firewalldienst van de distributie in plaats van hem na elke herstart opnieuw uit te voeren. Op een nftables-host laat je ip protocol gre zowel in de input- als in de forward-keten overeenkomen.

Controleer dat de module ppp_generic ook geladen is, en kijk of verbindingsregistratie de retourrichting weggooit. Beide veroorzaken fouten die op een firewallprobleem lijken en dat niet zijn. Een ontbrekende kernelmodule ziet er precies uit als een geblokkeerd protocol tot je het controleert.

Pas de opties aan op de client die je echt hebt

De oplossing uit het andere rapport staat in /etc/ppp/pptpd-options, waar het recept PAP, CHAP en MSCHAP weigert, de bijbehorende require-regels uitcommentarieert en stateful MPPE behoudt. Dat recept is geschreven voor één clientmix, en blind kopiëren breekt het gewone geval. Lees de weigerregels als een uitspraak over welke clients de auteur had, niet als een aanbeveling.

Een Windows-client heeft meestal MS-CHAPv2 met MPPE-128 nodig. Houd die eisen aan en verwijder alleen de opties die de client echt niet kan onderhandelen.

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

Versleuteling uitschakelen om een verbinding te laten slagen is een verlaging, geen reparatie. Test zo'n variant op een laboratoriumlijn en herstel daarna de versleuteling voordat de dienst echte clients tegenkomt. De verbinding die onveilig werkt is erger dan die eerlijk faalt.

Lees het foutnummer van de client

De numerieke code van de client vernauwt de fase sneller dan het serverlog. Lees hem voordat je iets anders leest. 691 betekent dat de inloggegevens zijn geweigerd, 721 betekent dat de server nooit antwoordde, en 619 betekent dat de verbinding wegviel. Twee minuten met het nummer besparen een uur met de configuratie.

Vergelijk die code met het serverlog voordat je iets bewerkt, en test opnieuw met dezelfde client na elke wijziging. Anders verbergt een tweede fout zich achter de eerste en lijkt de oplossing niet te werken.

Wanneer de login slaagt en er geen verkeer beweegt, blijft GRE de verdachte. Dat is het moment om terug te gaan naar de opname in plaats van naar het opslagpunt van inloggegevens.