iPhone Always On VPN: دو تونل می‌توانند یک IP مجازی مشترک داشته باشند

روی یک iPhone زیر نظارت با پروفایل Always On مدیریت‌شده، گوشی برای هر رابط IP فعال یک تونل نگه می‌دارد، بنابراین شبکه سلولی و Wi-Fi هر کدام تونل خود را دارند. سپس سرور دو انجمن امنیتی IKE برای یک دستگاه فهرست می‌کند، که اغلب یک نشانی مجازی را به اشتراک می‌گذارند، و نخستین واکنش این است که آن را حلقه rekey بنامیم و شروع به تغییر تایمرها کنیم. این واکنش معمولاً نادرست است. مراحل زیر را به همان ترتیبی که شواهد روی سرور ظاهر می‌شوند طی کنید و تنظیمات گوشی را دست نزنید تا سرور بگوید کدام حالت را دارید.

با همان دو ردیفی شروع کنید که سرور از قبل دارد

انجمن‌ها را با swanctl --list-sas فهرست کنید و چهار فیلد را در هر دو ورودی بخوانید: نشانی راه دور، هویت احراز‌شده، IP مجازی تخصیص‌یافته و زمان ایجاد. دو نشانی بیرونی متفاوت با یک هویت و یک IP مجازی همان شکلی است که این پرسش را آغاز کرد، و ارزش دارد پیش از هر تغییری نوشته شود. سپس انجمن‌های فرزند متصل به هر کدام را بررسی کنید، چون انتخابگرهای ترافیک تعیین می‌کنند که آیا جست‌وجوی مقصد هرگز می‌تواند آن دو تونل را از هم تشخیص دهد. جفتی که در چند ثانیه ظاهر و ناپدید می‌شود جانوری دیگر است از جفتی که هر دو ساعت‌ها زنده می‌مانند.

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

تصمیم بگیرید کدام هم‌پوشانی را می‌بینید

rekey در IKEv2 و احراز هویت مجدد make-before-break عمداً یک هم‌پوشانی کوتاه می‌سازند و انجمن جدید را پیش از حذف قدیمی برقرار می‌کنند. برچسب‌های زمانی ماجرا را روشن می‌کنند، چون SA قدیمی که یک یا دو ثانیه پس از ظاهر شدن جدید ناپدید می‌شود همان تمدید است که کارش را انجام می‌دهد. تونل‌های مستقل هر رابط هرگز چنین نیستند، چون هر یک تا زمانی که رابطش بالا باشد باقی می‌ماند و حذف یکی از ایجاد دیگری نتیجه نمی‌شود.

رفتار Always On مدیریت‌شده اپل به‌ازای هر رابط است، به همین دلیل یک دستگاه زیر نظارت می‌تواند به‌طور موجه مشغول‌تر از پروفایلی به نظر برسد که دستی تنظیم شده است. کلید اتصال خودکار یک برنامه ارائه‌دهنده معنای یکسانی ندارد، و یک قاعده on-demand معمولی هم ندارد. مرور کلی استقرار اپل مدل به‌ازای هر رابط را توصیف می‌کند؛ پیش از فرض کردن یک حلقه، دو ردیف خود را با آن مقایسه کنید. هر دو شکل نیز از همان استخر سمت سرور برداشت می‌کنند، پس هم‌پوشانی تنها نشانه زودهنگام شماست.

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

پاسخ به گوشی به نشانی داخلی نشانه‌گذاری می‌شود، و هسته تونل خروجی را بر اساس مقصد و سیاست انتخاب می‌کند، نه بر اساس رابطی که گوشی استفاده کرده است. دو انجمن هم‌زمان که IP مجازی یکسان با سیاست‌های منطبق را نگه می‌دارند، تصمیم مسیریابی را بدون راهی برای گفتن اینکه پاسخ به کدام نشست تعلق دارد رها می‌کنند. برخی پاسخ‌ها تونل اشتباه را می‌گیرند، و گوشی اتصالی را نشان می‌دهد که یک‌طرفه کار می‌کند یا وقتی Wi-Fi بالا می‌آید می‌میرد. دو خروجی فرمان وضعیت را اثبات می‌کنند: swanctl --list-sas که همان IP مجازی را روی هر دو SA نشان می‌دهد، و ip xfrm policy که دو انتخابگر یکسان را نشان می‌دهد.

همین جفت خروجی چیزی است که در سابقه تغییر می‌چسبانید. هیچ‌کدام به‌تنهایی قانع‌کننده نیست، چون هر یک به‌تنهایی می‌تواند باورپذیر به نظر برسد.

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

استخر یا مدل هم‌زمانی را تغییر دهید، نه تایمر rekey را

در پیکربندی swanctl، یگانگی یک سیاست صریح روی اتصال است: unique = replace هنگام برقراری اتصال جدید، اتصال قدیمی‌تر را حذف می‌کند و unique = keep تازه‌وارد را رد می‌کند. هر دو مقدار هنگام برپا شدن اتصال عمل می‌کنند، نه روی SAهای فرزند درون آن.

connections {
  ios-alwayson {
    unique = replace
  }
}

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

گذارهایی را آزمایش کنید که واقعاً عرضه می‌کنید

با یک نشست فعال از محدوده Wi-Fi بیرون بروید، سپس برگردید و بررسی کنید که پاسخ‌ها در هر دو جهت می‌رسند. دو بار این کار را بکنید، چون گذار دوم جایی است که سیاست کهنه معمولاً ظاهر می‌شود. با سرویسی آزمایش کنید که روی همان اتصالی که باز کرده‌اید پاسخ می‌دهد، و خروج را زمانی تکرار کنید که تونل ترافیک حمل می‌کند نه اینکه بیکار بماند. گوشی‌ای که می‌تواند بفرستد اما دریافت نکند در گزارش دست‌دادن سالم و در مرورگر خراب به نظر می‌رسد.

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