Docker ішіндегі PPTP аутентификациядан өтеді, бірақ трафикті тасымалдамайды

Клиент аутентификациядан өтеді, PPP мекенжайды келіседі, содан кейін ештеңе қозғалмайды. Ping сәтсіз аяқталады, браузер сәтсіз аяқталады, ал контейнер барлық уақытта қосылған болып көрінеді. Бұл үлгі маршруттау кестесінің мәселесі емес, өйткені маршруттау мәселелері әдетте басқару қосылымын да бұзады. Бұл деректер жолы, ал PPTP-де деректер жаңа ғана сәтті болған протоколдан өзге протокол.

Ең көп уақытты үнемдейтін ретпен бес тексеру.

Тексеру 1: басқару арнасын деректерден бөліңіз

PPTP TCP 1723 арқылы аутентификациядан өтеді, содан кейін PPP деректерін GRE, IP протоколы 47 ішінде тасымалдайды. GRE не TCP, не UDP емес, сондықтан басқару портын өткізетін әрбір ереже ол туралы ештеңе айтпайды. 1723-ті өткізетін NAT немесе брандмауэр 47 протоколын шағымсыз тастай алады, ал сеанс табысқа ұқсайтын түрде жартылай құрылған күйде қалады.

Егер кіру жұмыс істеп, бірде-бір пакет қайтпаса, алдымен GRE деп есептеңіз, кейін оны дәлелдеңіз.

Тексеру 2: хост ядросындағы көмекшіні растаңыз

Қосылымды бақылау көмекшісіз TCP басқару қосылымын GRE ағынына байланыстыра алмайды. Модуль — nf_conntrack_pptp, ол хост ядросында тұрады, және оны контейнер бейнесінің ішіне жүктеу ештеңе бермейді, өйткені модульдер бүкіл хостқа қолданылады. Docker хостындағы lsmod | grep nf_conntrack_pptp — бұл тексеру. Егер ол жоқ болса, 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 протоколының қабылданып жатқанын және санауыштардың қозғалатынын көрсетеді. Docker-дің masquerade ережелері TCP мен UDP-ні түрлендіреді, 47 протоколын емес, сондықтан көпірлі контейнерге айқын forward рұқсаты және кейбір хосттарда өзінің түрлендіру ережесі қажет болуы мүмкін. Контейнерде өз бейнесі күтетін PPP құрылғы қолдауы бар екенін де растаңыз.

Ереже мәтінін емес, санауыштарды оқыңыз. Бар ереже ештеңеге сәйкес келмесе, ол — безендіру.

Тексеру 5: GRE бақыланып жатқанын дәлелдеңіз, содан кейін PPTP туралы шешім қабылдаңыз

Клиент жұмыс істеп тұрғанда бақылау кестесін оқыңыз. Орнатылған PPTP басқару жазбасы мен оған қатысты GRE жазбасы көмекшінің ағындарды байланыстырып жатқанын және қалған ақаудың басқа жерде екенін білдіреді. GRE жазбасы жоқ басқару жазбасы деректердің тасталып жатқанын немесе бақыланбайтынын білдіреді, бұл сізді 2 және 3 тексерулерге қайтарады.

PPTP өзі ескірген, ал MS-CHAPv2 әлсіз. Егер сервер L2TP/IPsec, IKEv2 немесе WireGuard-ты да ұсынса, солардың біреуіне көшу осы мәселелердің бүкіл класын жояды.

PPTP қалуға тиіс жерде, клиентті контейнердің ішінде емес, хостта іске қосу NAT пен сүзгілеудің бір қабатын жояды, бұл көбіне арзанырақ шешім.