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 و فیلتر کردن را حذف می‌کند، که اغلب تصمیم ارزان‌تری است.