خطای PPTP 800 در برابر 812 و قطع اتصال پس از یک دقیقه
خطای 800، خطای 812 و تونل PPTP که پس از یک دقیقه میمیرد سه نقص جداگانه هستند. هر نشانه را به لایهای که واقعاً شکست خورده نسبت دهید.
سه پیام خطا از یک کلاینت PPTP معمولاً سه نقص متفاوت را توصیف میکنند. خطای 800 یعنی تونل هرگز تشکیل نشد، خطای 812 یعنی سرور روش احراز هویت را رد کرد، و قطع شدن پس از یک دقیقه یک تایمر keepalive است که تصمیم میگیرد همتای سالمی رفته است. هر مرحله به دلیل خودش شکست میخورد، پس هرکدام بررسی خودش را لازم دارد.
خطای 800 یعنی تونل هرگز تشکیل نشد
ویندوز خطای 800 را زمانی میدهد که اصلاً نمیتواند تونل را بسازد، و متن درباره سرور غیرقابلدسترس یا پارامترهای امنیتی نامناسب خلاصه است نه تشخیص. PPTP پیش از بررسی هرگونه اعتبارنامه دو چیز جداگانه از شبکه میخواهد. TCP 1723 کانال کنترل را حمل میکند و پروتکل IP شماره 47، یعنی GRE، بار کپسولهشده را حمل میکند.
این مسیر بیرونی را از بیرون LAN خودتان آزمایش کنید، چون اتصالی که داخل دفتر کار میکند درباره لبه چیزی اثبات نمیکند:
$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB
اگر 1723 پاسخ میدهد و در حالی که کلاینت تلاش میکند متصل شود ضبط خالی میماند، مسیر پروتکل 47 را میاندازد. روتری که 1723 در آن هدایت شده اما عبور PPTP خاموش است دقیقاً همان الگو را تولید میکند: دستدهی TCP کامل میشود، سپس بستههای GRE ناپدید میشوند، بنابراین شکست شبیه مشکل اعتبارنامه به نظر میرسد هرچند هیچ تلاش ورودی انجام نشده است.
هدایت را به نشانی LAN فعلی سرور نشانه بگیرید، عبور PPTP را هرجا روتر ارائه میدهد فعال کنید و از همان نقطه بیرونی دوباره امتحان کنید. وقتی GRE در بالادست فیلتر میشود و نمیتوانید آن را تغییر دهید، SSTP روی TCP 443 یا L2TP/IPsec روی UDP 500 و 4500 شانس بهتری از هر تغییری دارد که میتوانید در سمت ویندوز انجام دهید.
خطای 812 رد شدن روش احراز هویت شما توسط سرور است
خطای 812 پس از برپا شدن تونل برمیگردد، به همین دلیل مثل مشکل گذرواژه به نظر میرسد. سرور روش احراز هویت مذاکرهشده برای اتصال را رد میکند، نه لزوماً خود گذرواژه را. در کلاینت ورودی VPN را باز کنید، به زبانه امنیت بروید، نوع را روی Point-to-Point Tunneling Protocol بگذارید، فهرست صریح پروتکلها را انتخاب کنید و Microsoft CHAP نسخه 2 را تیک بزنید.
میتوانید تنظیم فعلی را بدون کلیک کردن در گفتگو بخوانید:
$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2
سروری که MS-CHAP v2 میخواهد کلاینتی را که روی PAP یا روی نوع خودکاری که چیزی ضعیفتر مذاکره میکند رها شده رد میکند، و خطا پیش از ارزیابی هر گذرواژه کاربر میرسد. قالب حساب نیمه دیگر همان رد شدن است. در یک مورد ویندوز هویت حساب مایکروسافت به شکل MicrosoftAccount\[email protected] فرستاد در حالی که سرور حساب محلی یا دامنه میخواست. نوشتن SERVERNAME\username به ویندوز گفت به کدام مخزن حساب مراجعه کند و خطا را پاک کرد. نام را دستی وارد کنید بهجای اینکه بگذارید اعتبارنامه ذخیرهشده قالب قبلی را دوباره اجرا کند.
قطع شدن پس از یک دقیقه یک تصمیم keepalive است
وقتی تونل متصل میشود، کمی ترافیک عبور میدهد و سپس قطع میشود، پیش از دست زدن به کلاینت رفتار پژواک LCP سرور را ببینید. دیمن بهطور دورهای از همتا میخواهد تأیید کند که هنوز آنجاست. اگر در بودجه تنظیمشده پاسخهای بسیار کمی برسد، نشست حتی با وجود اینکه کاربر هنوز پیوند کارآمدی دارد، برچیده میشود.
روی سرور Linux pptpd آن مقادیر در /etc/ppp/options.pptpd قرار دارند و تعمیر معمول گستردن بودجه است نه کوتاه کردن فاصله:
# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd
سی افت با فاصله پنج ثانیه یک توقف کوتاه را میبخشد بهجای اعلام رفتن همتا. کاهش تعداد به یکی یا دو تا، لرزش معمولی روی مسیر ترجمهشده را تقریباً هر دقیقه به قطع شدن تبدیل میکند. اگر سرور شما بهجای pptpd ویندوز RRAS است، بهجای آن مهلت نشست PPP و سیاست قطع اتصال در حالت بیکاری را ببینید. آنها جای دیگری هستند و ویرایش فایل pppd که وجود ندارد چیزی را تغییر نمیدهد.
زیرشبکههای همپوشان مسیر داده را میشکنند
تونل PPTP میتواند پاک احراز هویت شود و باز هم به جایی نرسد وقتی هر دو سایت از یک محدوده خصوصی استفاده میکنند، مثلاً 192.168.1.0/24 در دفتر و در خانه. کلاینت نمیتواند بگوید یک نشانی معین به کدام میزبان اشاره دارد، و برخی پشتهها از نصب مسیر بهکلی خودداری میکنند بهجای اینکه یکی را انتخاب کنند.
با آن مانند یک نقص طراحی برخورد کنید و یک طرف را دوباره شمارهگذاری کنید، یا به کلاینت محدوده دسترسی ترجمهشده عمدی بدهید. اشکالزدایی کلاینت PPTP نمیتواند فضای نشانیای را که دو بار وجود دارد درست کند، و نشانه همچنان شبیه قطع تصادفی خواهد بود.
از مرحلهای که شکست خورد شروع کنید: GRE برای 800، روش و رشته حساب برای 812، تنظیمات پژواک برای تونلی که طبق جدول میمیرد.