Chyby zápisu GRE na pptpd nejsou problém s heslem

Chyba zápisu GRE v logu a první instinkt je resetovat uživatelské heslo. Ten instinkt je téměř vždy špatný. Tyto zprávy popisují datovou cestu, ne kontrolu přihlašovacích údajů: klient se mohl úspěšně autentizovat a pak uvíznout ve fázi, kdy se registruje v síti. Dvě různé zprávy ukazují na dva různé problémy a ani jeden se nevyřeší novým heslem.

Dvě zprávy, dva různé problémy

Chyba čtení znamená, že pakety GRE nikdy nedorazí k démonu nebo jsou na vstupu zahozeny. Kontrolní spojení může vypadat naprosto zdravě, zatímco datovou cestou nic neprochází. Autentizace je jediná věc, která prokazatelně fungovala.

Chyba zápisu obvykle znamená, že si relace vyjednala něco, co jádro nebo klient nemohou použít. Kontrolní kanál se dokončil a volby dohodnuté při této výměně neodpovídají tomu, co koncové body skutečně umí. To je nesoulad konfigurace, ne událost autentizace.

Přečtěte si, která z těch dvou se objevuje, než cokoli změníte. Vedou vás do různých vrstev a jejich léčba jako jednoho symptomu je důvod, proč se stejný server záplatuje dvakrát z nesouvisejících příčin. Řádek v logu je jediná bezplatná diagnostika, kterou dostanete.

Protokol 47 není port 47

PPTP používá TCP 1723 k navázání hovoru a GRE k přenosu užitečného zatížení. GRE je IP protokol 47, ne číslo portu, takže pravidlo firewallu, které otevře port 47, nic užitečného nepovolí.

Router na cestě potřebuje funkci PPTP passthrough nebo výslovné povolení GRE. Bez toho se TCP handshake dokončí a tunel nikdy nepřenese paket, což vytváří přesně výše uvedenou chybu čtení. Pravidla pro port 47 ve firewallu jsou nejčastěji promarněné odpoledne v tomto protokolu.

Sledujte oba směry současně na serveru, místo abyste hádali, která strana provoz zahazuje: tcpdump -ni any port 1723 or proto gre.

Pokud 1723 ukazuje navázání hovoru a GRE zůstává tichý, blokace je nad hostitelem. Pokud GRE dorazí a démon stále selhává, problém je lokální a volby jsou dalším místem, kam se podívat.

Povolte GRE tam, kde hostitel skutečně přeposílá

Vložení forward pravidla pro GRE je rozumný test na hostiteli, který přeposílá tunelový provoz, a není to politika. Testovací pravidlo, které přijímá vše jednoho protokolu, je diagnostika, ne návrh. Ponechte ho dost dlouho, abyste se něco dozvěděli, a pak ho nahraďte omezeným pravidlem.

Přidejte input pravidlo pro pakety adresované samotnému serveru, protože forward řetězec je nevidí. Potom sledujte počítadla pravidel před pokusem o spojení a po něm, což vám řekne, zda pakety vůbec dorazí.

Uložte pravidlo trvale přes firewallovou službu distribuce, místo abyste ho znovu spouštěli po každém restartu. Na hostiteli s nftables porovnejte ip protocol gre v input i forward řetězci.

Ověřte, že je načtený také modul ppp_generic, a zkontrolujte, zda sledování spojení nezahazuje zpětný směr. Obojí vytváří selhání, která vypadají jako problém firewallu a nejsou. Chybějící modul jádra vypadá přesně jako blokovaný protokol, dokud to neprověříte.

Přizpůsobte volby klientovi, kterého skutečně máte

Oprava z druhé zprávy je v /etc/ppp/pptpd-options, kde recept odmítá PAP, CHAP a MSCHAP, zakomentovává odpovídající řádky require a zachovává stavové MPPE. Ten recept byl napsán pro jednu směs klientů a slepé kopírování rozbíjí obvyklý případ. Čtěte řádky odmítnutí jako tvrzení o tom, jaké klienty autor měl, ne jako doporučení.

Klient Windows obvykle potřebuje MS-CHAPv2 s MPPE-128. Tyto požadavky zachovejte a odstraňte jen volby, které klient skutečně nemůže vyjednat.

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

Vypnutí šifrování, aby spojení uspělo, je degradace, ne oprava. Vyzkoušejte takovou variantu na laboratorním spoji a potom obnovte šifrování, než se služba setká se skutečnými klienty. Spojení, které funguje nezabezpečeně, je horší než to, které selže poctivě.

Přečtěte si číslo chyby klienta

Číselný kód klienta zúží fázi rychleji než log serveru. Přečtěte si ho dřív než cokoli jiného. 691 znamená, že byly přihlašovací údaje odmítnuty, 721 znamená, že server nikdy neodpověděl, a 619 znamená, že se spojení přerušilo. Dvě minuty s číslem ušetří hodinu s konfigurací.

Porovnejte tento kód s logem serveru, než cokoli upravíte, a po každé změně znovu otestujte se stejným klientem. Jinak se druhá chyba skryje za první a oprava vypadá neúčinně.

Když se přihlášení podaří a provoz se nehýbe, GRE zůstává podezřelý. To je okamžik vrátit se k zachycení, ne k úložišti přihlašovacích údajů.