GRE-skriuflatings by pptpd binne gjin wachtwurdprobleem

GRE-skriuflating yn it log, en it earste ynsin is om it wachtwurd fan de brûker te resetten. Dat ynsin is hast altyd ferkeard. Dizze berjochten beskriuwe it datapaad, net de kontrôle fan oanmeldgegevens: de klant hat miskien suksesfol autentisearre en is doe fêst kommen te sitten yn de faze wêryn't er him op it netwurk registrearret. Twa ferskillende berjochten wize op twa ferskillende flatings, en gjinien wurdt oplost troch in nij wachtwurd.

Twa berjochten, twa ferskillende flatings

In lêsflating betsjut dat de GRE-pakketten nea by de daemon komme, of ûnderweis nei binnen fuortsmitten wurde. De kontrôlezetting kin der folslein sûn útsjen wylst der neat oer it datapaad giet. Autentikaasje is it iennige dat oantoanber wurke hat.

In skriuflating betsjut meast dat de sesje wat ûnderhannelle hat dat de kernel of de klant net brûke kin. It kontrôlekanaal is foltôge, en de opsjes dy't yn dy útwikseling ôfpraat binne, komme net oerien mei wat de einpunten echt dwaan kinne. Dat is in konfiguraasje-ûnienigens, gjin autentikaasje-evenemint.

Lês hokker fan de twa ferskynt foardat jo wat feroarje. Se stjoere jo nei ferskillende lagen, en se as ien symptoom behannelje is de reden dat deselde server twa kear patcht wurdt om ûnbesibbe redenen. De logrigel is de iennige fergees diagnoaze dy't jo krije.

Protokol 47 is gjin poarte 47

PPTP brûkt TCP 1723 om de oprop op te setten en GRE om de lading te dragen. GRE is IP-protokol 47, gjin poartenûmer, dus in firewallregel dy't poarte 47 iepenet, tastiet neat nuttich.

In router yn it paad hat in PPTP-passthroughfunksje of in eksplisite GRE-tastimming nedich. Sûnder dy foltôget de TCP-hânskikking en draacht de tunnel nea in pakket, wat krekt de lêsflating hjirboppe jout. Regels foar poarte 47 yn in firewall binne de meast fergriemde middei yn dit protokol.

Besjoch beide rjochtingen tagelyk op de server yn stee fan te rieden hokker kant ferkear fuortsmyt: tcpdump -ni any port 1723 or proto gre.

As 1723 opropopsetsjen sjen lit wylst GRE stil bliuwt, is de blokkade boppe de host. As GRE oankomt en de daemon falt noch altyd, is it probleem lokaal en binne de opsjes it folgjende plak om te sjen.

Tastie GRE wêr't de host echt trochstjoert

In forward-regel foar GRE ynfoegje is in ridlike test op in host dy't tunnelferkear trochstjoert, en it is gjin belied. In testregel dy't alles fan ien protokol akseptearret is in diagnoaze, gjin ûntwerp. Lit him lang genôch stean om wat te learen, ferfange him dan troch in beheinde regel.

Foegje in input-regel ta foar pakketten dy't oan de server sels rjochte binne, want de forward-ketting sjocht se net. Sjoch dan nei de tellers fan de regel foar en nei in ferbiningstaspraak, wat jo fertelt oft de pakketten oerhaads oankomme.

Meitsje de regel permanint fia de firewallsjinst fan de distribúsje yn stee fan him nei elke werstart opnij út te fieren. Op in nftables-host, lit ip protocol gre oerienkomme yn sawol de input- as de forward-ketting.

Befêstigje dat de module ppp_generic ek laden is, en kontrolearje oft ferbiningsfolging de weromrjochting fuortsmyt. Beide jouwe flatings dy't op in firewallprobleem lykje en it net binne. In ûntbrekkende kernelmodule liket krekt op in blokkearre protokol oant jo it neisje.

Pas de opsjes oan op de klant dy't jo echt hawwe

De oplossing fan it oare rapport sit yn /etc/ppp/pptpd-options, wêr't it resept PAP, CHAP en MSCHAP wegeret, de oerienkommende require-rigels útkommentearret en stateful MPPE hâldt. Dat resept is skreaun foar ien klantmingsel, en it blyn kopiearjen brekt it gewoane gefal. Lês de wegeringsrigels as in útspraak oer hokker klanten de auteur hie, net as in oanbefelling.

In Windows-klant hat normaal MS-CHAPv2 mei MPPE-128 nedich. Hâld dy easken en fuortsmyt allinnich de opsjes dy't de klant echt net ûnderhannelje kin.

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

Fersifering útsette om in ferbining slagje te litten is in ferlechting, gjin reparaasje. Test sa'n fariant op in laboratoariumferbining, en set de fersifering dan wer oan foardat de tsjinst echte klanten moetet. De ferbining dy't ûnfeilich wurket is slimmer as dy't earlik falt.

Lês it flaternûmer fan de klant

De numerike koade fan de klant ferget it stadium flugger as it serverlog. Lês him foardat jo wat oars lêze. 691 betsjut dat de oanmeldgegevens wegere waarden, 721 betsjut dat de server nea antwurde, en 619 betsjut dat de ferbining foel. Twa minuten mei it nûmer sparje in oere mei de konfiguraasje.

Fergelykje dy koade mei it serverlog foardat jo wat bewurkje, en test opnij mei deselde klant nei elke feroaring. Oars ferberget in twadde flater him achter de earste en liket de oplossing net effektyf.

As de oanmelding slagget en der gjin ferkear beweecht, bliuwt GRE de fertochte. Dat is it momint om werom te gean nei de opname yn stee fan nei it oanmeldgegevensargyf.