تونل VPN هرگز متصل نمی‌شود: بسته‌ها واقعاً کجا متوقف می‌شوند

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

ثابت کنید ترافیک کجا متوقف می‌شود

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

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

PPTP بدون پروتکل 47 می‌میرد

PPTP کنترل را روی TCP 1723 و داده‌هایش را درون GRE حمل می‌کند، که پروتکل 47 در IP است و نه شماره پورت. هدایت تنها 1723 نتیجه کلاسیک را می‌دهد: اتصال احراز هویت می‌شود و سپس ساکت می‌ماند، زیرا برای پروتکلی که بار مفید را حمل می‌کند قاعده‌ای وجود ندارد. کلاینت نمی‌تواند این را از رمز عبور ردشده تشخیص دهد، بنابراین ضبط باید پیش از تغییرات پیکربندی انجام شود.

عبور در جهت مخالف هدایت ورودی کار می‌کند و میان‌افزار اغلب برای هر دو یک برچسب به کار می‌برد، به اندازه‌ای که همه را گیج کند. روی کلاینت لینوکس دیوار آتش محلی می‌تواند GRE را خیلی پیش از دخالت مسیریاب دور بریزد، پس پروتکل 47 قاعده خودش را لازم دارد و دستیار conntrack باید بارگذاری شود. ufw در اوبونتو این قواعد را در فایل before نگه می‌دارد، چون قواعد allow معمولی نمی‌توانند شماره پروتکل را بیان کنند. سپس دیوار آتش را دوباره بارگذاری کنید، نه اینکه ماشین را راه‌اندازی مجدد کنید.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP و IPsec پشت دو NAT

L2TP درون IPsec به UDP 500 برای تبادل کلید، UDP 4500 هنگام شناسایی NAT و ESP به عنوان پروتکل 50 نیاز دارد. هر یک مستقل فیلتر می‌شود، پس قاعده‌ای که یکی را مجاز می‌کند درباره دو تای دیگر چیزی ثابت نمی‌کند. دو مسیریاب پشت سر هم هر بسته را دو بار ترجمه می‌کنند و دو سر دیگر بر سر آنچه مذاکره شد هم‌نظر نیستند.

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

شبکه‌های اپراتور و اشتراک نشانی

نشانی WAN در محدوده 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16 یا 100.64.0.0/10 یعنی مسیریاب نشانی عمومی ندارد و هیچ هدایت ورودی از اینترنت به آن نمی‌رسد. NAT سطح اپراتور نیز پروتکل‌هایی را که انتظار ندارد فیلتر می‌کند و GRE در پیوندهای موبایل قربانی مکرر است. نشانی WAN را روی خود مسیریاب مقایسه کنید، نه نشانی‌ای را که یک سایت جستجو برای کلاینت پشت آن گزارش می‌کند.

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

پیش از بستن پورت‌ها فهرست شنونده‌ها را بخوانید

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

پیش‌فرض‌های SoftEther مثال خوبی است: TCP 443، 992 و 5555، با قابلیت‌های L2TP/IPsec و تونل DNS که سوکت‌های خودشان را اضافه می‌کنند. خاموش کردن آن قابلیت‌ها شنونده‌ها را حذف می‌کند نه پنهان، و آزمون از یک میزبان بیرونی می‌گوید آیا اپراتور اصلاً اجازه عبور پورت را می‌دهد. شنونده‌ای که به‌صورت محلی پاسخ می‌دهد ممکن است همچنان در بالادست بسته باشد، پس نشانی WAN خود مسیریاب را با آنچه یک سرویس بیرونی گزارش می‌کند مقایسه کنید.