چرا IKEv2 در اندروید روی پورت UDP غیراستاندارد شکست می‌خورد

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

گوشی در واقع چه فرستاد

رشته host:port در فیلدی که برای نام در نظر گرفته شده به‌عنوان نام تجزیه می‌شود. تجزیه‌کننده برای vpn.example.net:4443 چیزی برنمی‌گرداند، و خطایی که می‌بینید شکست تجزیه نام یا دسترسی‌ناپذیری است، نه پایان مهلت روی یک پورت. این تفاوت مهم است، زیرا تلاش دوباره با نامی کوتاه‌تر یا شبکه‌ای دیگر هرگز رشته‌ای را که فرم نمی‌تواند تجزیه کند درست نمی‌کند.

پروفایل بومی IKEv2 در اندروید، مانند کلاینت VPN داخلی ویندوز، به پورت‌های استاندارد IKE قفل شده است. هیچ‌یک فیلد پورت نشان نمی‌دهد، و هیچ ویرایش پروفایلی آن را اضافه نمی‌کند. اگر شنونده اپراتور واقعاً روی 4443 باشد، کلاینت داخلی ابزار اشتباه است، نه ابزاری با پیکربندی غلط.

از کلاینتی استفاده کنید که پورت را نشان می‌دهد

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

کل مجموعه را یک‌جا از اپراتور بخواهید: نام دروازه، پورت UDP، روش احراز هویت، و هویت سروری که کلاینت باید انتظار داشته باشد. پورت سفارشی دلیلی برای خاموش کردن بررسی گواهی‌نامه‌ها یا تغییر پروتکل نیست. پورت را همان‌جایی وارد کنید که کلاینت نصب‌شده انتظار دارد، و اگر آن کلاینت چنین فیلدی ندارد، پاسخ کلاینت تأییدشده دیگری است، نه یک راه‌حل حدسی.

سرور دو پورت دارد، و هر دو باید یکسان باشند

IKE روی UDP 500 آغاز می‌شود، و عبور NAT معمولاً IKE و ESP کپسوله‌شده را به UDP 4500 می‌برد. این‌ها تنظیمات جداگانه‌ای در strongSwan هستند، پس سروری که به یک پورت سفارشی منتقل شده باید هر دو را به یک مقدار تغییر دهد:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

با یک پورت برای هر دو نقش، دیمن باید IKE را از ESP-در-UDP روی همان سوکت تشخیص دهد، که این کار را با نشانگر چهار بایتی غیر ESP که پیش از پیام IKE می‌آید انجام می‌دهد. به همین دلیل کلاینت نمی‌تواند روی پورت سفارشی مذاکره کند و سپس بی‌صدا روی 4500 ادامه دهد، و به همین دلیل عبارت «فقط پورت را عوض کنید» یک شرط قالب‌بندی را پنهان می‌کند.

ارسال به جلو شنونده نیست

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

مسیر باید UDP را هم سرتاسر مجاز کند. عبور TCP 443 از شبکه یک هتل یا اپراتور چیزی درباره IKEv2 روی پورت UDP نمی‌گوید، حتی با همان شماره. جایی که تنها TCP 443 مجاز است، پورت UDP سفارشی IKEv2 را به HTTPS تبدیل نمی‌کند، و پاسخ درست ممکن است مسیر دسترسی دیگری باشد نه آزمایش دیگری با پورت.

هنگام آزمایش سه مرحله را جدا کنید

روی سرور ضبط کنید در حالی که کلاینت یک بار تلاش می‌کند. درخواستی که هرگز نمی‌رسد پرسش نقطه پایانی یا فایروال است؛ درخواستی که بدون پاسخ می‌رسد پرسش شنونده یا سیاست است؛ پاسخی که پس از آن سکوت است پرسش قالب‌بندی یا هویت است.

tcpdump -ni eth0 -vv udp port 4443

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