PPTP у Docker праходзіць аўтэнтыфікацыю, але не перадае трафік

Кліент праходзіць аўтэнтыфікацыю, PPP узгадняе адрас, і пасля нічога не рухаецца. Ping не праходзіць, браўзер не працуе, а кантэйнер увесь час выглядае падключаным. Гэтая карціна не праблема табліцы маршрутызацыі, бо праблемы маршрутызацыі звычайна ламаюць і кіраўнічае злучэнне. Гэта шлях даных, і ў PPTP даныя — гэта іншы пратакол, чым той, што толькі што спрацаваў.

Пяць праверак, у парадку, які зэканоміць найбольш часу.

Праверка 1: аддзяліце кіраўнічы канал ад даных

PPTP аўтэнтыфікуецца праз TCP 1723 і затым нясе даныя PPP унутры GRE, пратакол IP 47. GRE — гэта ні TCP, ні UDP, таму кожнае правіла, якое прапускае кіраўнічы порт, нічога пра яго не кажа. NAT або міжсеткавы экран, які прапускае 1723, можа маўкліва адкінуць пратакол 47, і сеанс застаецца пабудаваным напалову так, што выглядае як поспех.

Калі ўваход працуе і ніводны пакет не вяртаецца, спачатку меркавайце GRE, а потым дакажыце гэта.

Праверка 2: пацвердзіце памочнік у ядры хоста

Адсочванне злучэнняў не можа звязаць кіраўнічае злучэнне TCP з патокам GRE без памочніка. Модуль — nf_conntrack_pptp, ён жыве ў ядры хоста, і загрузка яго ў вобраз кантэйнера нічога не дае, бо модулі дзейнічаюць на ўвесь хост. lsmod | grep nf_conntrack_pptp на хосце Docker — гэта і ёсць праверка. Калі яго няма, modprobe nf_conntrack_pptp загружае яго для бягучага ядра і нічога не кажа пра наступную загрузку, таму дадайце яго і ў канфігурацыю хоста.

Модуль, які знікае пры перазагрузцы, праз месяц стане той самай заяўкай.

Праверка 3: прачытайце палітыку ядра, якая яго адключае

Нават калі модуль прысутнічае, ядры пачынаючы з 4.7 ставяць net.netfilter.nf_conntrack_helper па змаўчанні ў 0, што адключае аўтаматычнае прызначэнне памочніка для кожнага пратакола. Менавіта праз гэтае значэнне па змаўчанні правільна ўсталяваны модуль усё роўна нічога не робіць: код ёсць, а палітыка кажа яго не выкарыстоўваць. sysctl net.netfilter.nf_conntrack_helper паказвае бягучае значэнне, і ўсталяванне яго ў 1 падчас працы зноў робіць памочнік даступным. Захавайце значэнне праз канфігурацыю sysctl хоста, калі гэта дазваляе архітэктура.

Аўтаматычнае прызначэнне дазваляе трафіку ствараць чаканні няяўна, і менавіта таму значэнне па змаўчанні змянілі. Абмяжуйце яго давераным хостам або выкарыстайце відавочнае правіла, накіраванае на памочнік.

Праверка 4: паглядзіце на шлях кантэйнера асобна

Загружаны памочнік не стварае маршрут. Кантэйнеру патрэбны шлях да сервера PPTP, і перасылка на хосце павінна дазваляць GRE у абодвух кірунках: iptables -L FORWARD -v -n паказвае, ці прымаецца пратакол 47 і ці рухаюцца лічыльнікі. Правілы masquerade у Docker пераўтвараюць TCP і UDP, а не пратакол 47, таму кантэйнеру з мостам можа спатрэбіцца відавочны дазвол forward і, на некаторых хостах, уласнае правіла пераўтварэння. Пераканайцеся таксама, што кантэйнер мае падтрымку прылад PPP, якую чакае яго вобраз.

Чытайце лічыльнікі, а не тэкст правіла. Правіла, якое існуе і ні з чым не супадае, — гэта упрыгожанне.

Праверка 5: дакажыце, што GRE адсочваецца, затым вырашыце пра PPTP

Калі кліент запушчаны, прачытайце табліцу адсочвання. Усталяваны запіс кіравання PPTP плюс звязаны запіс GRE азначае, што памочнік звязвае патокі, а астатняя няспраўнасць у іншым месцы. Запіс кіравання без запісу GRE азначае, што даныя адкідаюцца або не адсочваюцца, і гэта вяртае вас да праверак 2 і 3.

Сам PPTP састарэў, а MS-CHAPv2 слабы. Калі сервер таксама прапануе L2TP/IPsec, IKEv2 або WireGuard, пераход на адзін з іх прыбірае ўвесь гэты клас праблем.

Там, дзе PPTP трэба пакінуць, запуск кліента на хосце замест кантэйнера прыбірае адзін пласт NAT і фільтрацыі, і гэта часта больш таннае рашэнне.