PPTP وصل می‌شود و سپس پشت Linux NAT معلق می‌ماند: کمک‌کننده GRE

کسی 1723 را فوروارد می‌کند، کلاینت به سرور می‌رسد، احراز هویت آغاز می‌شود و سپس همه چیز بدون خطا متوقف می‌شود. نتیجه طبیعی رمز عبور اشتباه است، پس رمز سه بار دوباره تایپ می‌شود. فوروارد درست بود و اعتبارنامه‌ها درست بودند. چیزی که شکست پروتکل دومی بود که فوروارد هرگز پوشش نمی‌داد، و یک مقدار پیش‌فرض هسته که بی‌صدا کمک به آن را متوقف کرد.

فوروارد هرگز مشکل نبود

قاعده فوروارد پورت، ترافیک TCP یا UDP را توصیف می‌کند. نمی‌تواند بار مفیدی را توصیف کند که در میانه نشست به پروتکل IP دیگری سوییچ می‌کند، و PPTP دقیقاً همین کار را می‌کند.

به همین دلیل اتصال تا لحظه‌ای که معلق می‌شود سالم به نظر می‌رسد. بخشی که قاعده پورت می‌تواند مدیریت کند موفق شد، و بخشی که نمی‌تواند مدیریت کند همان بخشی است که شکست خورد.

TCP برای کنترل، GRE برای داده

تماس روی TCP 1723 مذاکره می‌شود. وقتی برپا شد، بار به GRE می‌رود، پروتکل IP 47، که اصلاً شماره پورت حمل نمی‌کند. قاعده‌ای که بر پورت تکیه دارد چیزی برای تطبیق ندارد.

آنچه GRE حمل می‌کند یک شناسه تماس در هدر آن است، و مترجم NAT باید آن فیلد را در هر دو جهت به‌طور یکسان بازنویسی کند وگرنه دو نیمه نشست از توافق با یکدیگر بازمی‌مانند. بازنویسی یک جهت و نه جهت دیگر نشستی می‌سازد که احراز هویت می‌کند و سپس هر بسته داده را دور می‌ریزد. شکل نشانه دقیقاً همین است: موفقیت، سپس سکوت.

GRE خالی بدون PPTP به چنین بازنویسی نیاز ندارد، به همین دلیل یک تونل GRE ساده می‌تواند از روتری عبور کند که برای کلاینت PPTP در همان مسیر شکست می‌خورد.

چهار ماژول و یک sysctl که آن‌ها را خاموش کرد

دو ماژول قاب‌بندی را مدیریت می‌کنند، nf_conntrack_proto_gre و nf_nat_proto_gre. دو ماژول دیگر شناسه تماس را مدیریت می‌کنند، nf_conntrack_pptp و nf_nat_pptp. بارگذاری آخری بقیه را از طریق وابستگی‌ها می‌کشد، پس فهرست ماژول‌ها باید هر چهار را نشان دهد.

دستورالعمل‌های قدیمی از پیشوند ip_ از دوره 2.6 استفاده می‌کنند. ممکن است آن دستورها در حالی که چیزی بارگذاری نمی‌کنند اجرا شوند، پس فهرست بارگذاری‌شده را بررسی کنید نه وضعیت خروج.

بارگذاری آن‌ها دیگر کافی نیست. از Linux 4.7 مقدار sysctl net.netfilter.nf_conntrack_helper به‌طور پیش‌فرض 0 است، که تخصیص خودکار کمک‌کننده را برای جریان‌های جدید غیرفعال می‌کند. یک روتر می‌تواند همه ماژول‌ها را داشته باشد و باز هم چیزی ترجمه نکند. قبل از اینکه دوباره فهرست ماژول‌ها را ببینید، مقدار مؤثر را بررسی کنید.

یا تخصیص خودکار را به‌طور کلی دوباره روشن کنید، یا کمک‌کننده را به جریان‌هایی که به آن نیاز دارند وصل کنید و بقیه را رها کنید:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

گزینه دوم ترجیح داده می‌شود. رفتار را به ترافیک PPTP محدود می‌کند به‌جای اینکه تخصیص خودکار را در سراسر روتر دوباره فعال کند.

باز کردن پروتکلی که پورت ندارد

قاعده فایروالی که 1723 را مجاز می‌کند چیزی درباره پروتکل 47 نمی‌گوید. در firewalld پروتکل را در ناحیه‌ای که رو به کلاینت است مجاز کنید. در iptables ساده پروتکل gre را در زنجیره ورودی بپذیرید.

سپس در هر دو طرف ضبط کنید. بسته‌هایی که کلاینت را ترک می‌کنند بدون اینکه پاسخ‌هایی برسد یعنی مسیر بازگشت فیلتر شده است، و این خرابی متفاوتی از اعتبارنامه ردشده است.

پس از اتصال، محدودیت اندازه

GRE یک هدر وارد می‌کند و PPP در داخل آن بیشتر اضافه می‌کند، پس یک لینک عامل MTU بسیار کمتر از 1500 گزارش می‌دهد. پاسخ‌های کوچک بارگذاری می‌شوند و بزرگ‌ها گیر می‌کنند، که مانند یک مشکل دوم و نامرتبط به نظر می‌رسد که همان لحظه حل شدن اولی ظاهر می‌شود.

MTU را روی آداپتور PPP کلاینت بخوانید و آن را با محاسبه خود روتر هماهنگ کنید به‌جای پایین آوردن اعداد تا وقتی چیزی کار کند. بسته‌های با اندازه کامل که خارج می‌شوند و چیزی برنمی‌گردد به همان محدودیت اشاره دارند نه به ترجمه.

ترمیم مسیر کاربر را به کار می‌اندازد و PPTP را انتخاب خوبی نمی‌کند. MS-CHAPv2 و RC4 مدت‌هاست منسوخ شده‌اند، پس بارگذاری ماژول را اصلاح موقتی بدانید و برای رفتن به پروتکل نگهداری‌شده برنامه‌ریزی کنید.