PPTP از طریق هات‌اسپات: TCP 1723 فقط نیمی از ماجراست

بررسی‌ها را به ترتیب انجام دهید: اینکه اتصال کنترل باز می‌شود یا نه، اینکه GRE از مسیر جان سالم به در می‌برد یا نه، اینکه سرور تماس را می‌پذیرد یا نه، و اینکه احراز هویت کامل می‌شود یا نه. یک کلاینت PPTP هم به نشست TCP روی 1723 و هم به مسیر GRE نیاز دارد که داده‌ها را حمل کند، و یک هات‌اسپات می‌تواند یکی را عبور دهد و دیگری را بیندازد. انجام دادنشان به ترتیب به شما می‌گوید کدام مرز را بررسی کنید، نه اینکه حدس بزنید. شماره‌های خطای Windows این کار را برایتان نمی‌کنند.

GRE پروتکل 47 در IP است. این پورت 47 در TCP یا UDP نیست، و همین تفاوت بیشتر سردرگمی درباره فایروال‌ها را توضیح می‌دهد.

دو مسیر، یک اتصال

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

ترجمه نیاز خودش را اضافه می‌کند. دروازه‌هایی که پورت را به اشتراک می‌گذارند اغلب به ALG آگاه از PPTP نیاز دارند تا شناسه‌های تماس را همراه با آدرس‌ها بازنویسی کند، و یکی بدون آن می‌تواند نشست را طوری خراب کند که شبیه افت بسته باشد. این رفتار رایج اما وابسته به پیاده‌سازی است، پس هر محدودیت فروشنده را نمونه بگیرید، نه ویژگی هر هات‌اسپات.

هات‌اسپات دو مرز دیگر اضافه می‌کند

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

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

807 را به‌عنوان وقفه بخوانید، نه حکم

Windows خطای 807 را به‌عنوان اتصال قطع‌شده گزارش می‌کند، که نتیجه را توصیف می‌کند نه علت را. جدول خطاهایش 806 را جداگانه به‌عنوان دسته مرتبط با GRE در نظر می‌گیرد، و دانستن این تفاوت پیش از ساختن یک نظریه ارزش دارد. هیچ‌یک از این دو شماره فاش نمی‌کند که آیا اپراتور پروتکل 47 را فیلتر کرده، آیا ظرفیت سرور تمام شده، یا آیا اعتبارنامه‌ها درست بوده‌اند. خطا می‌گوید نشست پایان یافت؛ مسیر می‌گوید کجا.

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

مرحله‌ای را که شکست خورد جدا کنید

لپ‌تاپ، سرور و پروفایل را ثابت نگه دارید، سپس فقط شبکه دسترسی را به یک شبکه تأییدشده دیگر تغییر دهید. اگر نتیجه تغییر کرد، تبادلات TCP و GRE را در مرزهایی که کنترل می‌کنید ثبت کنید و زودترین مرحله‌ای را بیابید که هرگز رخ نمی‌دهد: برقراری کنترل، آماده‌سازی تماس، تحویل داده، یا احراز هویت PPP. هر کدام امضای متفاوتی در یک ثبت باقی می‌گذارند. مقایسه یک شبکه سالم با یک شبکه ناموفق بسیار آموزنده‌تر از دوباره خواندن متن خطاست.

همه اینها یک استقرار از پیش موجود را تشخیص می‌دهد. این استدلالی برای راه‌اندازی سرویس PPTP جدید نیست، و نمی‌توان با مذاکره از پروتکل دور زد: نصب کلاینت متفاوت باعث نمی‌شود سرور بدون تغییر چیز دیگری صحبت کند.

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