GRE-skrivefejl på pptpd er ikke et adgangskodeproblem

GRE-skrivefejl i loggen, og den første indskydelse er at nulstille brugerens adgangskode. Den indskydelse er næsten altid forkert. Disse beskeder beskriver datastien, ikke legitimationskontrollen: klienten kan være blevet godkendt og derefter være stoppet på det trin, hvor den registrerer sig på netværket. To forskellige beskeder peger på to forskellige fejl, og ingen af dem løses af en ny adgangskode.

To beskeder, to forskellige fejl

En læsefejl betyder, at GRE-pakkerne aldrig når daemonen, eller at de kasseres på vej ind. Kontrolforbindelsen kan se helt sund ud, mens intet krydser datastien. Godkendelsen er det eneste, der beviseligt virkede.

En skrivefejl betyder normalt, at sessionen har forhandlet noget, som kernen eller klienten ikke kan bruge. Kontrolkanalen blev gennemført, og de valgmuligheder, der blev aftalt under den udveksling, passer ikke til, hvad endepunkterne faktisk kan. Det er en konfigurationsuenighed, ikke en godkendelseshændelse.

Læs, hvilken af de to der optræder, før du ændrer noget. De sender dig til forskellige lag, og at behandle dem som ét symptom er grunden til, at den samme server bliver patchet to gange af ubeslægtede årsager. Loglinjen er den eneste gratis diagnosticering, du får.

Protokol 47 er ikke port 47

PPTP bruger TCP 1723 til at oprette opkaldet og GRE til at bære nyttelasten. GRE er IP-protokol 47, ikke et portnummer, så en firewallregel, der åbner port 47, tillader intet nyttigt.

En router på vejen har brug for en PPTP-passthrough-funktion eller en eksplicit GRE-tilladelse. Uden den fuldføres TCP-håndtrykket, og tunnelen bærer aldrig en pakke, hvilket giver præcis læsefejlen ovenfor. Port 47-regler i en firewall er den mest almindeligt spildte eftermiddag i denne protokol.

Overvåg begge retninger samtidig på serveren i stedet for at gætte, hvilken side der kasserer trafik: tcpdump -ni any port 1723 or proto gre.

Hvis 1723 viser opkaldsoprettelse, mens GRE forbliver tavs, er blokeringen oven for værten. Hvis GRE ankommer, og daemonen stadig fejler, er problemet lokalt, og valgmulighederne er det næste sted at se.

Tillad GRE, hvor værten faktisk videresender

Indsættelse af en forward-regel for GRE er en rimelig test på en vært, der videresender tunneltrafik, og det er ikke en politik. En testregel, der accepterer alt af én protokol, er en diagnosticering, ikke et design. Lad den ligge længe nok til at lære noget, og erstat den derefter med en afgrænset regel.

Tilføj en input-regel for pakker, der er adresseret til serveren selv, fordi forward-kæden ikke ser dem. Se derefter på regelens tællere før og efter et forbindelsesforsøg, hvilket fortæller dig, om pakkerne overhovedet ankommer.

Bevar reglen gennem distributionens firewalltjeneste i stedet for at køre den igen efter hver genstart. På en nftables-vært skal ip protocol gre matche i både input- og forward-kæden.

Bekræft, at modulet ppp_generic også er indlæst, og kontroller, om forbindelsessporing kasserer returretningen. Begge dele giver fejl, der ligner et firewallproblem og ikke er det. Et manglende kernemodul ser præcis ud som en blokeret protokol, indtil du tjekker.

Tilpas valgmulighederne til den klient, du faktisk har

Rettelsen fra den anden rapport findes i /etc/ppp/pptpd-options, hvor opskriften afviser PAP, CHAP og MSCHAP, kommenterer de tilsvarende require-linjer ud og beholder stateful MPPE. Den opskrift blev skrevet til én klientblanding, og blind kopiering ødelægger det almindelige tilfælde. Læs afvisningslinjerne som en udtalelse om, hvilke klienter forfatteren havde, ikke som en anbefaling.

En Windows-klient har normalt brug for MS-CHAPv2 med MPPE-128. Behold disse krav, og fjern kun de valgmuligheder, som 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

At slå kryptering fra for at få en forbindelse til at lykkes er en degradering, ikke en reparation. Test en sådan variant på et laboratorielink, og gendan derefter krypteringen, før tjenesten møder rigtige klienter. Den forbindelse, der virker usikkert, er værre end den, der fejler ærligt.

Læs klientens fejlnummer

Klientens numeriske kode indsnævrer trinnet hurtigere, end serverloggen gør. Læs den, før du læser noget andet. 691 betyder, at legitimationsoplysningerne blev afvist, 721 betyder, at serveren aldrig svarede, og 619 betyder, at forbindelsen faldt. To minutter med nummeret sparer en time med konfigurationen.

Sammenlign den kode med serverloggen, før du redigerer noget, og test igen med den samme klient efter hver ændring. Ellers skjuler en anden fejl sig bag den første, og rettelsen ser ineffektiv ud.

Når login lykkes, og ingen trafik bevæger sig, er GRE stadig den mistænkte. Det er øjeblikket til at vende tilbage til optagelsen i stedet for legitimationslageret.