عبور PPTP وجود ندارد: رفع خطای 807 در Windows VPN

عبور دادن TCP 1723 اغلب بخش اول PPTP را باز می‌کند و بقیه را خراب می‌گذارد، بنابراین ویندوز هنگام تلاش همچنان خطای 807 را برمی‌گرداند. غریزه بعدی افزودن یک قاعده برای پورت 47 است، و همین گام است که یک بعدازظهر را تلف می‌کند: GRE یک شماره پروتکل در سرآیند IP است، نه پورتی که جدول عبور بتواند با آن تطبیق دهد. تا زمانی که روتر پروتکل 47 را عبور ندهد و آن را به همان تماس گره نزند، تونل نمی‌تواند شروع شود. بخش‌های زیر دو کانال را از هم جدا می‌کنند و سپس یکی‌یکی آن‌ها را می‌آزمایند.

جدول پورت‌ها هیچ ردیفی برای شماره پروتکل ندارد

PPTP از دو گفتگو استفاده می‌کند که به دو شکل متفاوت شکست می‌خورند. گفتگوی روی TCP 1723 تماس را آغاز می‌کند، اطلاعات پیوند را می‌فرستد و وقتی کاربر قطع می‌کند آن را می‌بندد. سمت بار داده درون GRE اجرا می‌شود که سرآیند IP آن را با شماره پروتکل 47 برچسب می‌زند، و درون آن تونل PPP درباره پیوند مذاکره می‌کند در حالی که MS-CHAPv2 اعتبارنامه‌ها را بررسی می‌کند.

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

ویندوز وقتی مسیر داده می‌میرد چه گزارش می‌دهد

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

پیش از دست زدن به گذرواژه روی انتقال کار کنید. تغییر اعتبارنامه‌ها برای شکار 807 عیب واقعی را سر جایش می‌گذارد و تلاش بعدی را سخت‌تر خواندنی می‌کند.

چرا کلاینت دوم تونلی را که کار می‌کند خراب می‌کند

چون پورتی برای تمایز دادن آن‌ها وجود ندارد، دستگاه NAT نمی‌تواند دو کلاینت PPTP را جدا کند آن‌گونه که دو نشست HTTPS را جدا می‌کند. به همین دلیل بسیاری از دستگاه‌های مصرفی یک تماس PPTP را مجاز می‌دانند و آن را بر اساس نشانی مبدأ پیگیری می‌کنند. لپ‌تاپی که تنها کار می‌کرد، به محض اینکه ماشین دومی شماره‌گیری کند از کامل شدن بازمی‌ماند، و از سمت کلاینت این شکست تصادفی به نظر می‌رسد. این الگو متعلق به فرم‌ور است و هیچ تغییر پروفایلی آن را دگرگون نمی‌کند.

هنگامی که هر دو کلاینت شماره‌گیری می‌کنند جدول اتصال‌ها را ببینید. اگر همیشه فقط میزبان اول نگاشتی نگه دارد، روتر به مرز آنچه پشتیبانی می‌کند رسیده است و هیچ تنظیمی در سمت کلاینت آن را تکان نمی‌دهد.

ثابت کنید کدام نیمه شکست می‌خورد

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

نتیجه درست در آزمون پورت یعنی کانال کنترل باز است و GRE مشکوک باقی‌مانده است. نتیجه نادرست یعنی مسیریابی، یک فیلتر یا عبور شکسته است، و هیچ تغییر GRE آن را نجات نمی‌دهد. سمت داده را باید همان‌جا که دیده می‌شود پایش کرد، در سرور یا در روتر.

tcpdump -ni any proto 47

معادل آن در Wireshark فیلتر نمایش ip proto 47 است، که سپردنش به کسی که در خط فرمان راحت نیست آسان‌تر است. GRE که می‌رسد و هیچ چیزی در پاسخ بیرون نمی‌رود یعنی مسیر بازگشت نیاز به تعمیر دارد.

چه چیزی واقعاً خطا را برطرف می‌کند

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

جایگزینی PPTP گزینه دیگر و غالباً ارزان‌تر است. روتری که خودش VPN را پایان می‌دهد از NAT دوگانه برای کلاینت‌های ورودی پرهیز می‌کند، و پروتکلی که NAT مبتنی بر پورت از قبل آن را مدیریت می‌کند هیچ نیازی به عبور ندارد: OpenVPN روی UDP، SSTP روی TCP 443 یا L2TP/IPsec با NAT-T که ESP را در UDP 4500 می‌پیچد. PPTP همچنین به MS-CHAPv2 وابسته است که ضعف‌های مستندش آن را حتی پس از برطرف شدن خطا انتخاب بدی برای استقرار تازه می‌کند.

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