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 жана чыпкалоонун бир катмарын жоёт, бул көбүнчө арзаныраак чечим.