GRE-skryffoute by pptpd is nie 'n wagwoordprobleem nie

GRE-skryffout in die log, en die eerste instink is om die gebruiker se wagwoord te herstel. Daardie instink is byna altyd verkeerd. Hierdie boodskappe beskryf die datapad, nie die geloofwaardigheidskontrole nie: die kliënt het dalk suksesvol geverifieer en dan vasgehaak by die stadium waar dit op die netwerk registreer. Twee verskillende boodskappe wys op twee verskillende foute, en nie een word deur 'n nuwe wagwoord opgelos nie.

Twee boodskappe, twee verskillende foute

'n Leesfout beteken die GRE-pakette bereik nooit die daemon nie, of word op pad in laat val. Die beheerverbinding kan heeltemal gesond lyk terwyl niks oor die datapad beweeg nie. Verifikasie is die een ding wat bewysbaar gewerk het.

'n Skryffout beteken gewoonlik die sessie het iets beding wat die kern of die kliënt nie kan gebruik nie. Die beheerkanaal het voltooi, en die opsies wat tydens daardie uitruiling ooreengekom is, pas nie by wat die eindpunte werklik kan doen nie. Dit is 'n konfigurasieverskil, nie 'n verifikasiegebeurtenis nie.

Lees watter van die twee verskyn voordat jy enigiets verander. Hulle stuur jou na verskillende lae, en om hulle as een simptoom te behandel is waarom dieselfde bediener twee keer vir onverwante redes gepatch word. Die logreël is die enigste gratis diagnose wat jy kry.

Protokol 47 is nie poort 47 nie

PPTP gebruik TCP 1723 om die oproep op te stel en GRE om die vrag te dra. GRE is IP-protokol 47, nie 'n poortnommer nie, so 'n firewall-reël wat poort 47 oopmaak, laat niks nuttigs deur nie.

'n Roeteerder in die pad het 'n PPTP-passthrough-funksie of 'n eksplisiete GRE-toelating nodig. Sonder een voltooi die TCP-handdruk en dra die tonnel nooit 'n pakkie nie, wat presies die leesfout hierbo veroorsaak. Poort 47-reëls in 'n firewall is die mees algemene vermorste middag in hierdie protokol.

Dop beide rigtings gelyktydig op die bediener in plaas daarvan om te raai watter kant verkeer laat val: tcpdump -ni any port 1723 or proto gre.

As 1723 oproepopstelling wys terwyl GRE stil bly, is die blok bokant die gasheer. As GRE aankom en die daemon steeds faal, is die probleem plaaslik en die opsies is die volgende plek om te kyk.

Laat GRE toe waar die gasheer werklik aanstuur

Om 'n forward-reël vir GRE in te voeg is 'n redelike toets op 'n gasheer wat tonnelverkeer aanstuur, en dit is nie 'n beleid nie. 'n Toetsreël wat alles van een protokol aanvaar, is 'n diagnose, nie 'n ontwerp nie. Laat dit lank genoeg in plek om iets te leer, en vervang dit dan met 'n beperkte reël.

Voeg 'n input-reël by vir pakkette wat aan die bediener self gerig is, want die forward-ketting sien dit nie. Kyk dan na die reëltellers voor en na 'n verbindingspoging, wat jou vertel of die pakkette hoegenaamd aankom.

Bewaar die reël deur die verspreiding se firewall-diens eerder as om dit na elke herbegin weer te laat loop. Op 'n nftables-gasheer, pas ip protocol gre in beide die input- en forward-kettings.

Bevestig dat die ppp_generic-module ook gelaai is, en kyk of connection tracking die terugrigting laat val. Beide veroorsaak foute wat soos 'n firewall-probleem lyk en nie een is nie. 'n Ontbrekende kernmodule lyk presies soos 'n geblokkeerde protokol totdat jy dit nagaan.

Pas die opsies by die kliënt wat jy werklik het

Die ander verslag se oplossing lê in /etc/ppp/pptpd-options, waar die resep PAP, CHAP en MSCHAP weier, die ooreenstemmende require-lyne uitkommenteer en stateful MPPE behou. Daardie resep is vir een kliëntmengsel geskryf, en om dit blindelings te kopieer breek die algemene geval. Lees die weier-lyne as 'n stelling oor watter kliënte die skrywer gehad het, nie as 'n aanbeveling nie.

'n Windows-kliënt benodig normaalweg MS-CHAPv2 met MPPE-128. Behou daardie vereistes en verwyder net die opsies wat die kliënt werklik nie kan beding nie.

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

Om enkripsie te deaktiveer om 'n verbinding te laat slaag, is 'n afgradering, nie 'n herstel nie. Toets so 'n variant op 'n laboratoriumverbinding en herstel dan enkripsie voordat die diens regte kliënte in die gesig staar. Die verbinding wat onveilig werk, is erger as die een wat eerlik faal.

Lees die kliënt se foutnommer

Die kliënt se numeriese kode vernou die stadium vinniger as wat die bedienerlog doen. Lees dit voordat jy enigiets anders lees. 691 beteken die geloofsbriewe is verwerp, 721 beteken die bediener het nooit geantwoord nie, en 619 beteken die verbinding het geval. Twee minute met die nommer spaar 'n uur met die konfigurasie.

Vergelyk daardie kode met die bedienerlog voordat jy enigiets wysig, en toets weer met dieselfde kliënt na elke verandering. Andersins verberg 'n tweede fout agter die eerste en lyk die regstelling ondoeltreffend.

Wanneer die aanmelding slaag en geen verkeer beweeg nie, bly GRE die verdagte. Dit is die oomblik om terug te keer na die opname eerder as na die geloofwaardigheidsbron.