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 болон шүүлтийн нэг давхаргыг арилгах бөгөөд энэ нь ихэвчлэн илүү хямд шийдвэр юм.