دو VPN آیفون همزمان: کدام یک ترافیک شما را حمل می‌کند؟

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

افسانه: دو VPN متصل یک زنجیره‌اند

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

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

مدل مستند پشت آن افسانه

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

Personal VPN در اینجا اصطلاح API برای پیاده‌سازی توکار IPsec یا IKEv2 است که از طریق NEVPNManager مدیریت می‌شود. NETunnelProviderManager مدل ارائه‌دهنده تونل است. یک برنامه مصرفی می‌تواند از مدل ارائه‌دهنده استفاده کند، بنابراین نام محصولی که personal دارد آن را طبقه‌بندی نمی‌کند.

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

افسانه: VPN شخصی ترافیک مرور را می‌گیرد

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

پیکربندی‌های مدیریت‌شده هر برنامه محدوده خودشان را دارند. یک قاعده سطح دستگاه را به هر استقرار مدیریت‌شده تعمیم ندهید.

دو جریان را پیش از آزمایش بنویسید: نام و محدوده خصوصی سرویس کار، و یک درخواست مرور عمومی تازه. هر دو مشروع‌اند و به بررسی‌های متفاوتی نیاز دارند.

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

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

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

دو جریان را بنویسید و هر کدام را آزمایش کنید

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

یک پیکربندی را متوقف کنید و هر دو جریان را تکرار کنید. رفتار شکست بخشی از طراحی است و همان بخشی است که کاربران متوجه می‌شوند. وقتی دو ارائه‌دهنده نمی‌توانند ترکیب را پشتیبانی کنند، روی یک پیکربندی تأییدشده توافق کنید و مستند کنید کدام جریان را حمل می‌کند، یا به طراحی مدیریت‌شده تک‌تونلی بروید. مستندات NETunnelProviderManager منبع قاعده همزیستی است.