Server PPTP za domácím routerem: nejdřív opravte 1723 a GRE

PPTP za domácím routerem selhává dvěma nesouvisejícími způsoby a jejich záměna stojí celý večer. Jedna porucha je mezera v předávání: router propustí TCP 1723 a zahodí IP protokol 47, takže klient zůstane viset na chybě 619. Druhá je problém velikosti: tunel se zvedne, ověří a pak zamrzne, když musí projít paket plné velikosti. Zjistit, kterou z nich máte, je první skutečný krok; zbytek porovnává, co váš router umí vyjádřit, ne která značka je lepší.

Dva transporty a jen jeden z nich má port

PPTP se dělí na dva transporty: řídicí spojení na TCP 1723 a rámce PPP zabalené do rozšířeného GRE, což je IP protokol 47. GRE nemá číslo portu, takže pravidlo napsané jako přesměrování portu 1723 ho nemůže pokrýt, ať webové rozhraní pole nazve jakkoli. Spotřebitelský router obvykle nabízí zaškrtávací pole s názvem průchod PPTP místo pravidla protokolu a toto pole dělá dvě věci: propouští protokol 47 přes firewall a učí NAT sledovat tok GRE. Na linuxovém routeru jsou to oddělené moduly a oddělená pravidla, a proto polovičatě nastavený průchod stále dává fungující řídicí kanál. Zjistěte, která polovina existuje, než cokoli změníte.

Vlastní firewall serveru musí také povolit protokol 47 z adresy routeru. Firewall hostitele, který přijímá jen 1723/tcp, reprodukuje chybu 619 zevnitř LAN, takže rozbité předávání a rozbité pravidlo hostitele vypadají stejně.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Pokud moduly chybí, načtěte je pomocí sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre a načtení udělejte trvalým, protože restart, který pomocníka zapomene, vrátí fungující tunel zpět do chyby 619. Pravidlo předávání musí přijímat protokol 47 jen směrem k adrese serveru, ne celé LAN. Definice RFC 2637 odděluje řídicí a datovou cestu, a proto žádná obrazovka přesměrování portu nepopisuje PPTP úplně.

Zaškrtávací pole průchodu, nebo výslovné pravidlo protokolu

Zaškrtávací pole průchodu, které jen otevře firewall, je blíž správnému než ALG, který přepisuje identifikátory volání. Polovina s firewallem je předvídatelná, protože protokol 47 se buď přijme, nebo zahodí, a čítače řeknou který. Polovina s přepisem je místo, kde se výrobci liší, protože identifikátory volání PPTP jsou pro každý tunel a NAT, který je upravuje, musí sledovat každé volání, kterého se dotkne. Když se připojí jeden klient a dva ne, ALG je první podezřelý.

Pravidlo cílového NAT pro 1723 má také problém vlastnictví. Pokud staré pravidlo stále posílá 1723 na hostitele, který přestal provozovat server, pakety dopadnou na zavřený port a vlastní služba PPTP routeru přestane odpovídat, což vypadá jako porucha firewallu, ale ve skutečnosti je to zastaralý cíl. Přečtěte si pravidlo a jeho cíl, než přidáte druhé. Na routerech, které PPTP ukončují samy, soutěží pravidlo WAN s vestavěnou službou, takže zvolte jednoho vlastníka pro 1723 a protokol 47.

Dva klienti za stejným NAT jsou případ, který odděluje prosté předávání od chytrého. Předávání protokolu 47 bez přepisu identifikátorů volání se obvykle chová lépe než pomocník, který se je snaží opravit.

Změřte tunel, než obviníte router

PPTP zmenšuje užitečný náklad a toto zmenšení je aritmetika, ne záhada. Každý paket tunelu nese vnější IP hlavičku, rozšířenou GRE hlavičku, PPP hlavičku a při šifrování i MPPE hlavičku. Když cesta nemůže přenést výsledný rámec, malé pakety projdou, přihlášení se dokončí a relace se zastaví poprvé, když přenos souboru nebo TLS handshake pošle paket plné velikosti.

Spočítejte číslo místo hádání. Rozšířené GRE stojí 8 bajtů, PPP stojí 4, MPPE stojí 4 a vnější IP hlavička stojí 20, takže tunel sní 36 bajtů před jakýmkoli nákladem. Na PPPoE WAN, který končí na 1492, je největší PPP MTU, které se vejde, 1492 minus 36, tedy 1456. Nastavte mtu a mru na tuto hodnotu v možnostech PPP a otestujte znovu pingem bez fragmentace.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Ping měří cestu, ne tunel: 1464 bajtů nákladu plus 28 bajtů IP a ICMP hlaviček přesně vyplní rámec o 1492 bajtech. Pokud tento ping selže, snižujte číslo, dokud neprojde, a od výsledku odečtěte 36. MTU tunelu nastavené nad limit cesty způsobí zamrznutí bez jediného řádku v logu, který by zmiňoval velikost.

PPTP, L2TP/IPsec nebo OpenVPN na stejném routeru

Stejný router unese kterýkoli ze tří běžných tunelů a rozdíl je v tom, co musí vyjádřit. PPTP potřebuje dvě pravidla ve dvou různých vrstvách. L2TP přes IPsec potřebuje UDP 500 a 4500 pro výměnu klíčů a, pokud ho nenese NAT-T, protokol 50 pro náklad. OpenVPN potřebuje jeden port UDP a vůbec žádného pomocníka.

Sloupec L2TP není automaticky přátelštější než GRE. ESP je IP protokol 50 a také nemá port, takže router, kterému dělá potíže protokol 47, může mít stejný problém s protokolem 50. NAT-T existuje proto, aby zabalil ESP do UDP 4500, a když ho oba konce podporují, pravidlo pro protokol 50 přestane být potřeba. To je vlastnost koncových bodů, ne zaškrtávacího pole PPTP na routeru. Potvrďte, jakou enkapsulaci klient skutečně vyjednal, než napíšete pravidla pro obojí.

OpenVPN je varianta s nejméně pohyblivými částmi na straně routeru. Jeden port UDP, jedno předávání, žádný pomocník pro sledování spojení a žádný přepis identifikátorů volání. Cenou je klient, který se musí nainstalovat místo vestavěného vytáčení, a to je často jediný důvod, proč PPTP zůstává v rozhovoru.

Co opravit a co nahradit

Oprava předávání a MTU vám dá tunel, který funguje, ne ten, který byste měli držet. Ověřování MSCHAPv2 u PPTP je napadnutelné už roky a fungující tunel přenáší přihlašovací údaje, které lze obnovit offline. Pokud vzdálené zařízení umí provozovat L2TP/IPsec nebo OpenVPN, berte opravu jako dočasné opatření s datem.

Rozhodnutí se scvrkává na to, co podporuje vzdálený konec a jak dlouho má uspořádání vydržet. Zastaralé zařízení, které mluví jen PPTP, dostane opravu; vše, co umí nainstalovat klienta, se migruje.

Než tiket zavřete, ověřte, že klient přežije velký přenos, ne jen přihlášení, a že router po restartu stále drží pravidlo pro protokol 47. Tunel, který projde jedním kopírováním souboru a zemře po další aktualizaci firmwaru, nebyl nikdy dokončen.