A pptpd GRE-írási hibái nem jelszóproblémák

GRE-írási hiba a naplóban, és az első ösztön a felhasználó jelszavának visszaállítása. Ez az ösztön szinte mindig hibás. Ezek az üzenetek az adatútvonalat írják le, nem a hitelesítő adatok ellenőrzését: a kliens sikeresen authentikálódhatott, majd elakadt abban a szakaszban, ahol regisztrál a hálózaton. Két különböző üzenet két különböző hibára mutat, és egyiket sem oldja meg egy új jelszó.

Két üzenet, két különböző hiba

Az olvasási hiba azt jelenti, hogy a GRE-csomagok soha nem érik el a démont, vagy befelé menet eldobják őket. A vezérlőkapcsolat teljesen egészségesnek tűnhet, miközben semmi nem halad át az adatútvonalon. A hitelesítés az egyetlen dolog, ami bizonyíthatóan működött.

Az írási hiba általában azt jelenti, hogy a munkamenet olyasmit tárgyalt, amit a kernel vagy a kliens nem tud használni. A vezérlőcsatorna lezárult, és az ott megbeszélt beállítások nem felelnek meg annak, amit a végpontok valóban meg tudnak tenni. Ez konfigurációs nézeteltérés, nem hitelesítési esemény.

Olvassa el, melyik jelenik meg a kettő közül, mielőtt bármit változtat. Különböző rétegekbe küldik, és egyetlen tünetként kezelésük az oka, hogy ugyanazt a kiszolgálót kétszer javítják egymástól független okokból. A naplósor az egyetlen ingyenes diagnosztika, amit kap.

A 47-es protokoll nem a 47-es port

A PPTP a TCP 1723-at használja a hívás felépítéséhez és a GRE-t a hasznos teher szállításához. A GRE 47-es IP-protokoll, nem portszám, ezért a 47-es portot megnyitó tűzfal-szabály semmi hasznosat nem engedélyez.

Az útvonalon lévő útválasztónak PPTP-passthrough funkcióra vagy kifejezett GRE-engedélyre van szüksége. Enélkül a TCP-kézfogás lezárul, és az alagút soha nem szállít csomagot, ami pontosan a fenti olvasási hibát eredményezi. A 47-es portra vonatkozó tűzfalszabályok e protokoll leggyakrabban elvesztegetett délutánjai.

Figyelje mindkét irányt egyszerre a kiszolgálón, ahelyett hogy kitalálná, melyik oldal dobja el a forgalmat: tcpdump -ni any port 1723 or proto gre.

Ha az 1723 hívásfelépítést mutat, miközben a GRE néma marad, a blokkolás a gazdagép felett van. Ha a GRE megérkezik és a démon még mindig hibázik, a probléma helyi, és a beállítások a következő vizsgálandó hely.

Engedélyezze a GRE-t ott, ahol a gazdagép valóban továbbít

A GRE-hez való forward-szabály beszúrása ésszerű teszt az alagútforgalmat továbbító gazdagépen, és nem szabályzat. Az a tesztszabály, amely egy protokoll mindent elfogad, diagnosztika, nem tervezés. Hagyja elég sokáig ahhoz, hogy tanuljon valamit, majd cserélje le egy szűkebb szabályra.

Adjon hozzá input-szabályt a magának a kiszolgálónak címzett csomagokhoz, mert a forward-lánc nem látja őket. Utána nézze meg a szabály számlálóit a kapcsolódási kísérlet előtt és után, ami megmondja, egyáltalán megérkeznek-e a csomagok.

Tegye tartóssá a szabályt a disztribúció tűzfalszolgáltatásán keresztül, ahelyett hogy minden újraindítás után újra futtatná. nftables-gazdagépen a ip protocol gre-et az input és a forward láncban is egyeztesse.

Győződjön meg arról, hogy a ppp_generic modul is betöltődött, és ellenőrizze, hogy a kapcsolatkövetés eldobja-e a visszirányt. Mindkettő olyan hibákat okoz, amelyek tűzfalproblémának látszanak és nem azok. A hiányzó kernelmodul pontosan blokkolt protokollnak látszik, amíg nem ellenőrzi.

Igazítsa a beállításokat ahhoz a klienshez, amely valóban van

A másik jelentés javítása a /etc/ppp/pptpd-options fájlban van, ahol a recept elutasítja a PAP-ot, a CHAP-ot és az MSCHAP-ot, kikommenteli a megfelelő require-sorokat és megtartja az állapottartó MPPE-t. Ezt a receptet egyetlen kliensvegyülethez írták, és a vak másolás elrontja a szokásos esetet. Az elutasítási sorokat a szerző klienseiről szóló állításként olvassa, nem ajánlásként.

A Windows-kliensnek általában MS-CHAPv2-re van szüksége MPPE-128-cal. Tartsa meg ezeket a követelményeket, és csak azokat a beállításokat távolítsa el, amelyeket a kliens valóban nem tud kialkudni.

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

A titkosítás kikapcsolása azért, hogy a kapcsolat létrejöjjön, lefokozás, nem javítás. Teszteljen ilyen változatot laboratóriumi kapcsolaton, majd állítsa vissza a titkosítást, mielőtt a szolgáltatás valódi kliensekkel találkozik. A nem biztonságosan működő kapcsolat rosszabb, mint az, amely őszintén elbukik.

Olvassa el a kliens hibaszámát

A kliens numerikus kódja gyorsabban szűkíti a szakaszt, mint a kiszolgálónapló. Olvassa el, mielőtt bármi mást olvasna. A 691 azt jelenti, hogy a hitelesítő adatokat elutasították, a 721 azt, hogy a kiszolgáló soha nem válaszolt, a 619 pedig azt, hogy a kapcsolat megszakadt. Két perc a számmal egy órát spórol a konfigurációval.

Hasonlítsa össze ezt a kódot a kiszolgálónaplóval, mielőtt bármit szerkesztene, és minden változtatás után tesztelje újra ugyanazzal a klienssel. Különben egy második hiba elrejtőzik az első mögött, és a javítás hatástalannak tűnik.

Amikor a bejelentkezés sikerül és semmilyen forgalom nem mozog, a GRE marad a gyanúsított. Ez az a pillanat, amikor vissza kell térni a rögzítéshez, nem a hitelesítőadat-tárhoz.