Někdo přesměruje 1723, klient se dostane na server, začne ověřování a pak se všechno bez chyby zastaví. Přirozený závěr je špatné heslo, takže se heslo třikrát znovu napíše. Přesměrování bylo v pořádku a přihlašovací údaje byly v pořádku. Rozbil se druhý protokol, který přesměrování nikdy nepokrývalo, a výchozí nastavení jádra, které s ním tiše přestalo pomáhat.

Přesměrování nikdy nebylo problém

Pravidlo přesměrování portu popisuje provoz TCP nebo UDP. Nedokáže popsat obsah, který v polovině relace přejde na jiný protokol IP, a PPTP dělá přesně to.

Proto spojení vypadá zdravě až do okamžiku, kdy zamrzne. Část, kterou pravidlo portu může řídit, uspěla, a část, kterou řídit nemůže, je ta část, která selhala.

TCP pro řízení, GRE pro data

Volání se vyjednává přes TCP 1723. Jakmile je navázáno, obsah přejde do GRE, protokolu IP 47, který nenese vůbec žádná čísla portů. Pravidlo, které se opírá o porty, nemá co porovnávat.

Co GRE nese, je identifikátor volání v záhlaví, a NAT překladatel musí toto pole přepisovat konzistentně v obou směrech, jinak se obě poloviny relace přestanou shodovat. Přepsaný jeden směr a nepřepsaný druhý vytvoří relaci, která se ověří a pak zahodí každý datový paket. Přesně tak vypadá podoba symptomu: úspěch, pak ticho.

Holé GRE bez PPTP takový přepis nepotřebuje, proto obyčejný tunel GRE může fungovat přes router, který pro klienta PPTP na stejné cestě selže.

Čtyři moduly a sysctl, který je vypnul

Dva moduly se starají o rámování, nf_conntrack_proto_gre a nf_nat_proto_gre. Další dva se starají o identifikátor volání, nf_conntrack_pptp a nf_nat_pptp. Načtení posledního z nich stáhne ostatní přes závislosti, takže výpis modulů by měl ukázat všechny čtyři.

Starší návody používají předponu ip_ z éry 2.6. Tyto příkazy se mohou tvářit, že běží, zatímco nic nenačítají, proto kontrolujte načtený seznam, ne návratový kód.

Mít je načtené už nestačí. Od Linuxu 4.7 má sysctl net.netfilter.nf_conntrack_helper výchozí hodnotu 0, což vypíná automatické přiřazení pomocníka pro nové toky. Router může mít všechny moduly a přesto nic nepřekládat. Zkontrolujte efektivní hodnotu, než se znovu podíváte na seznam modulů.

Buď znovu zapněte automatické přiřazení globálně, nebo připojte pomocníka k tokům, které ho potřebují, a vše ostatní nechte být:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Druhá možnost je lepší. Omezuje chování na provoz PPTP, místo aby znovu zapínala automatické přiřazení na celém routeru.

Otevření protokolu, který nemá porty

Pravidlo firewallu, které povoluje 1723, neříká nic o protokolu 47. Ve firewalld povolte protokol v zóně obrácené ke klientovi. V běžném iptables přijměte protokol gre ve vstupním řetězci.

Pak zachytávejte na obou stranách. Pakety opouštějící klienta bez přicházejících odpovědí znamenají, že návratová cesta je filtrovaná, a to je jiná závada než odmítnuté přihlašovací údaje.

Po připojení limit velikosti

GRE vkládá záhlaví a PPP uvnitř přidává další, takže funkční spojení hlásí MTU výrazně pod 1500. Malé odpovědi se načtou a velké se zaseknou, což vypadá jako druhý, nesouvisející problém, který se objeví ve chvíli, kdy je první vyřešen.

Přečtěte MTU na klientském PPP adaptéru a slaďte ji s vlastním výpočtem routeru místo snižování čísel, dokud něco nezačne fungovat. Pakety plné velikosti odcházející bez čehokoli, co se vrací, ukazují na tento limit, ne na překlad.

Oprava cesty vrátí uživatele do práce a nedělá z PPTP dobrou volbu. MS-CHAPv2 a RC4 jsou dávno zastaralé, takže načtení modulů berte jako dočasnou opravu a plánujte přechod na udržovaný protokol.

Související články