GRE-skribaj fiaskoj ĉe pptpd ne estas pasvorta problemo

GRE-skriba fiasko en la protokolo, kaj la unua instinkto estas restarigi la pasvorton de la uzanto. Tiu instinkto preskaŭ ĉiam malĝustas. Ĉi tiuj mesaĝoj priskribas la datuman vojon, ne la kontrolon de akreditaĵoj: la kliento eble sukcese aŭtentikiĝis kaj poste haltis en la stadio, kie ĝi registriĝas en la reto. Du malsamaj mesaĝoj indikas du malsamajn paneojn, kaj neniun solvas nova pasvorto.

Du mesaĝoj, du malsamaj paneoj

Legada fiasko signifas, ke la GRE-paketoj neniam atingas la demonon, aŭ estas forĵetataj survoje enen. La kontrola konekto povas aspekti tute sana dum nenio trapasas la datuman vojon. Aŭtentikigo estas la sola afero, kiu pruveble funkciis.

Skriba fiasko kutime signifas, ke la seanco interkonsentis ion, kion la kerno aŭ la kliento ne povas uzi. La kontrola kanalo finiĝis, kaj la opcioj interkonsentitaj dum tiu interŝanĝo ne kongruas kun tio, kion la finpunktoj povas fakte fari. Tio estas malkongruo de agordo, ne aŭtentikiga okazaĵo.

Legu, kiu el la du aperas, antaŭ ol ŝanĝi ion ajn. Ili sendas vin al malsamaj tavoloj, kaj trakti ilin kiel unu simptomon estas la kialo, ke la sama servilo estas flikata dufoje pro ne rilataj kaŭzoj. La protokola linio estas la sola senpaga diagnozo, kiun vi ricevas.

Protokolo 47 ne estas haveno 47

PPTP uzas TCP 1723 por starigi la vokon kaj GRE por porti la utilan ŝarĝon. GRE estas IP-protokolo 47, ne havena numero, do fajroŝirma regulo, kiu malfermas havenon 47, permesas nenion utilan.

Enkursigilo survoje bezonas PPTP-passthrough-funkcion aŭ eksplicitan permeson por GRE. Sen tio la TCP-manpremo finiĝas kaj la tunelo neniam portas paketon, kio produktas ĝuste la supran legadan fiaskon. Reguloj pri haveno 47 en fajroŝirmo estas la plej ofte malŝparita posttagmezo en tiu ĉi protokolo.

Observu ambaŭ direktojn samtempe sur la servilo anstataŭ diveni, kiu flanko forĵetas trafikon: tcpdump -ni any port 1723 or proto gre.

Se 1723 montras vokostarigon dum GRE restas silenta, la blokado estas super la gastiganto. Se GRE alvenas kaj la demono ankoraŭ fiaskas, la problemo estas loka kaj la opcioj estas la sekva loko por rigardi.

Permesu GRE kie la gastiganto fakte plusendas

Enmeti forward-regulon por GRE estas racia provo sur gastiganto, kiu plusendas tunelan trafikon, kaj ĝi ne estas politiko. Provregulo, kiu akceptas ĉion de unu protokolo, estas diagnozo, ne dezajno. Lasu ĝin sufiĉe longe por lerni ion, poste anstataŭigu ĝin per limigita regulo.

Aldonu input-regulon por paketoj adresitaj al la servilo mem, ĉar la forward-ĉeno ne vidas ilin. Poste rigardu la kalkulilojn de la regulo antaŭ kaj post konekta provo, kio diras al vi, ĉu la paketoj entute alvenas.

Konservu la regulon per la fajroŝirma servo de la distribuo anstataŭ ruli ĝin denove post ĉiu restartigo. Sur nftables-gastiganto, kongruigu ip protocol gre en kaj la input-ĉeno kaj la forward-ĉeno.

Konfirmu, ke la modulo ppp_generic ankaŭ estas ŝarĝita, kaj kontrolu, ĉu konekta spurumo forĵetas la revenan direkton. Ambaŭ produktas fiaskojn, kiuj aspektas kiel fajroŝirma problemo kaj ne estas. Mankanta kernomodulo aspektas ĝuste kiel blokita protokolo ĝis vi kontrolas.

Adaptu la opciojn al la kliento, kiun vi fakte havas

La korekto el la alia raporto troviĝas en /etc/ppp/pptpd-options, kie la recepto rifuzas PAP, CHAP kaj MSCHAP, komentas la respondajn require-liniojn kaj konservas MPPE kun stato. Tiu recepto estis verkita por unu klienta miksaĵo, kaj blinda kopiado rompas la ordinaran kazon. Legu la rifuzajn liniojn kiel aserton pri tio, kiujn klientojn la aŭtoro havis, ne kiel rekomendon.

Windows-kliento kutime bezonas MS-CHAPv2 kun MPPE-128. Konservu tiujn postulojn kaj forigu nur la opciojn, kiujn la kliento vere ne povas interkonsenti.

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

Malŝalti ĉifradon por ke konekto sukcesu estas malaltigo, ne riparo. Testu tian varianton sur laboratoria ligilo, poste restarigu la ĉifradon antaŭ ol la servo alfrontos verajn klientojn. La konekto, kiu funkcias nesekure, estas pli malbona ol tiu, kiu fiaskas honeste.

Legu la eraran numeron de la kliento

La nombra kodo de la kliento mallarĝigas la stadion pli rapide ol la servila protokolo. Legu ĝin antaŭ ol legi ion alian. 691 signifas, ke la akreditaĵoj estis rifuzitaj, 721 signifas, ke la servilo neniam respondis, kaj 619 signifas, ke la konekto falis. Du minutoj kun la numero ŝparas horon kun la agordo.

Komparu tiun kodon kun la servila protokolo antaŭ ol redakti ion ajn, kaj retestu per la sama kliento post ĉiu ŝanĝo. Alie dua paneo kaŝiĝas malantaŭ la unua kaj la korekto aspektas senefika.

Kiam la ensaluto sukcesas kaj neniu trafiko moviĝas, GRE restas la suspektato. Tio estas la momento reveni al la kapto anstataŭ al la akreditaĵa konservejo.