خطاهای نوشتن GRE در pptpd مشکل گذرواژه نیست

خطای نوشتن GRE در گزارش، و اولین واکنش بازنشانی گذرواژه کاربر است. این واکنش تقریباً همیشه اشتباه است. این پیام ها مسیر داده را توصیف می کنند، نه بررسی اعتبارنامه را: ممکن است کلاینت با موفقیت احراز هویت کرده و سپس در مرحله ای که در شبکه ثبت می شود متوقف شده باشد. دو پیام متفاوت به دو خطای متفاوت اشاره می کنند و هیچ یک با گذرواژه تازه حل نمی شود.

دو پیام، دو خطای متفاوت

خطای خواندن یعنی بسته های GRE هرگز به دیمن نمی رسند یا در مسیر ورود دور ریخته می شوند. ممکن است اتصال کنترلی کاملاً سالم به نظر برسد در حالی که هیچ چیز از مسیر داده عبور نمی کند. احراز هویت تنها چیزی است که به طور اثبات پذیر کار کرده است.

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

پیش از تغییر هر چیزی بخوانید کدام یک از این دو ظاهر شده است. آن ها شما را به لایه های متفاوت می فرستند و برخورد با آن ها به عنوان یک نشانه همان دلیلی است که یک سرور دو بار به دلایل نامرتبط وصله می شود. خط گزارش تنها تشخیص رایگان شماست.

پروتکل 47 همان درگاه 47 نیست

PPTP از TCP 1723 برای برقراری تماس و از GRE برای حمل بار استفاده می کند. GRE پروتکل IP شماره 47 است، نه شماره درگاه، بنابراین قاعده ای در دیوار آتش که درگاه 47 را باز می کند چیز مفیدی را مجاز نمی کند.

مسیریاب در مسیر به قابلیت عبور PPTP یا اجازه صریح GRE نیاز دارد. بدون آن دست دهی TCP کامل می شود و تونل هرگز بسته ای حمل نمی کند، که دقیقاً همان خطای خواندن بالا را پدید می آورد. قواعد درگاه 47 در دیوار آتش شایع ترین بعدازظهر تلف شده در این پروتکل است.

هر دو جهت را هم زمان روی سرور ببینید به جای حدس زدن این که کدام سمت ترافیک را دور می ریزد: tcpdump -ni any port 1723 or proto gre.

اگر 1723 برقراری تماس را نشان می دهد و GRE ساکت می ماند، مسدودسازی بالاتر از میزبان است. اگر GRE می رسد و دیمن هنوز شکست می خورد، مشکل محلی است و گزینه ها جای بعدی برای بررسی اند.

GRE را جایی مجاز کنید که میزبان واقعاً ارسال می کند

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

قاعده input را برای بسته هایی که به خود سرور فرستاده می شوند اضافه کنید، چون زنجیره forward آن ها را نمی بیند. سپس شمارنده های قاعده را پیش و پس از تلاش اتصال ببینید، که به شما می گوید بسته ها اصلاً می رسند یا نه.

قاعده را از طریق سرویس دیوار آتش توزیع ماندگار کنید به جای اجرای دوباره آن پس از هر راه اندازی مجدد. روی میزبان nftables، ip protocol gre را هم در زنجیره input و هم در زنجیره forward مطابقت دهید.

تأیید کنید که ماژول ppp_generic هم بارگذاری شده است و بررسی کنید آیا ردیابی اتصال جهت بازگشت را دور می ریزد. هر دو شکست هایی پدید می آورند که شبیه مشکل دیوار آتش است و نیست. ماژول هسته غایب تا زمانی که بررسی نکنید دقیقاً مانند پروتکل مسدود دیده می شود.

گزینه ها را با کلاینتی که واقعاً دارید تطبیق دهید

اصلاح گزارش دیگر در /etc/ppp/pptpd-options است، جایی که دستور العمل PAP، CHAP و MSCHAP را رد می کند، خطوط require مربوط را توضیح می کند و MPPE با حالت را نگه می دارد. آن دستور العمل برای یک ترکیب کلاینت نوشته شده بود و کپی کورکورانه آن مورد رایج را می شکند. خطوط رد را به عنوان بیانیه ای درباره کلاینت هایی که نویسنده داشته است بخوانید، نه توصیه.

کلاینت Windows معمولاً به MS-CHAPv2 همراه با MPPE-128 نیاز دارد. آن الزام ها را نگه دارید و فقط گزینه هایی را حذف کنید که کلاینت واقعاً نمی تواند مذاکره کند.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

شماره خطای کلاینت را بخوانید

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

پیش از ویرایش هر چیزی آن کد را با گزارش سرور مقایسه کنید و پس از هر تغییر با همان کلاینت دوباره آزمایش کنید. وگرنه خطای دوم پشت اولی پنهان می شود و اصلاح بی اثر به نظر می رسد.

وقتی ورود موفق است و ترافیکی حرکت نمی کند، GRE هنوز مشکوک است. آن لحظه بازگشت به ضبط است نه انبار اعتبارنامه.