آیا یک رابط WAN می‌تواند هم VPN سایت‌به‌سایت و هم دسترسی از راه دور را سرویس دهد؟
یک نشانی بیرونی می‌تواند تونل شعبه و کاربران سیار را حمل کند، اما تنها اگر تطبیق همتا، احراز هویت، استخرها و مسیرهای بازگشت جدا بمانند.
یک نشانی عمومی می‌تواند هم‌زمان تونل شعبه و استخری از کاربران سیار را سرویس دهد. اما نمی‌تواند یک قاعده پذیرش مشترک را سرویس دهد. همتای شعبه و کاربر سیار متفاوت‌اند در اینکه خود را چه کسی معرفی می‌کنند، آن اثبات چگونه بررسی می‌شود، چه نشانی‌هایی می‌گیرند و کدام پیشوندها می‌توانند به آن‌ها پاسخ دهند. همین که نشانی بیرونی را جزئیات انتقال بدانید و نه هویت، طراحی بسیار ساده‌تر می‌شود.
یک آزمون سریع عقل سلیم: پیش از دست زدن به روتر، هر دو رکورد پذیرش را بنویسید. اگر یک شرط تطبیق باید هر دو را پوشش دهد، سیاست از پیش مبهم است و نخستین نشانه مانند نقص مسیریابی یا دیوار آتش دیده می‌شود، در حالی که در واقع نقص هویت است.
دو رکورد پیش از هر پیکربندی
رکورد شعبه کوتاه و پایدار است. نشانی همتا یا نام گواهی، کلید از پیش مشترک یا نقطه اعتماد گواهی، زیرشبکه‌های محافظت‌شده در دو طرف، رابط تونل و مسیر ایستایی را فهرست می‌کند که ترافیک رو به شعبه را به آن تونل می‌فرستد. هر فیلد درباره یک همتای شناخته‌شده و مجموعه‌ای ثابت از پیشوندهاست.
رکورد سیار گسترده‌تر و شخصی‌تر است. پروتکل و درگاه کلاینت، نحوه احراز هویت کاربر یا دستگاه، استخر نشانی‌هایی که هنگام اتصال داده می‌شود، منابعی که آن استخر می‌تواند به آن‌ها برسد، پیشوندهای تونل تقسیم‌شده، سرورهای DNS که به کلاینت فرستاده می‌شود و هر عامل دومی را فهرست می‌کند. هر فیلد به پرسشی درباره شمار نامعلومی از کاربران پاسخ می‌دهد، نه درباره یک درگاه.
همین تفاوت در ریزدانگی تمام دلیل واگرایی دو نقش است. نمایه شعبه می‌تواند با خیال راحت به یک کلید اعتماد کند، چون کلید از یک دستگاه در یک سایت است. نمایه سیار که به یک کلید گروهی برای همه اعتماد می‌کند، پاسخ‌گویی به‌ازای هر کاربر را از بین می‌برد، و این معمولاً بعدتر کشف می‌شود، در بازبینی حادثه و نه در استقرار.
کجا تطبیق همتا و احراز هویت واگرا می‌شوند
در IOS XE نمایه IKEv2 پارامترهایی را حمل می‌کند که قابل مذاکره نیستند و شرایطی را که برای انتخاب همتا به کار می‌رود. یعنی طرف شعبه و طرف سیار هر یک نمایه خود را لازم دارند، حتی وقتی روی همان رابط پایان می‌یابند و حتی وقتی یک PKI رمزنگاری مشترک دارند. سیسکو نقش‌های نمایه، احراز هویت و تطبیق را در راهنمای پیکربندی IKEv2 برای IOS XE 17.
نمایه شعبه معمولاً با هویتی باریک تطبیق می‌یابد: نشانی دور، یک FQDN یا موضوع گواهی. چیزی مانند match identity remote address 198.51.100.10 255.255.255.255 یک همتا را سنجاق می‌کند و authentication remote pre-share با کلیدی که برای هر سایت ذخیره می‌شود کافی است. تطبیق را تا جایی که فهرست همتاها اجازه می‌دهد دقیق نگه دارید، چون یک wildcard هم‌پوشان در جایگاه بالاتر ترتیب انتخاب می‌تواند ترافیک شعبه را به نمایه اشتباه بکشاند.
نمایه سیار نمی‌تواند نشانی را سنجاق کند، پس با یک گروه، یک key-id یا فیلدی از گواهی تطبیق می‌یابد و بعد بررسی واقعی کاربر را به AAA یا به سیاست مجوزدهی متصل به نمایه می‌سپارد. این جداسازی مهم است: احراز هویت همتا پاسخ می‌دهد که آیا کلاینت مجاز به ساختن تونل است، و مجوزدهی به‌ازای هر کاربر پاسخ می‌دهد که کدام استخر و کدام منابع را می‌گیرد. به کار بردن کلید شعبه به عنوان ورود جهانی پاسخ دوم را دور می‌ریزد.
ارسال و ترجمه هم به همان جداسازی نیاز دارند
پذیرش و دسترسی‌پذیری دو مسئله جدا هستند. تبادل موفق IKE و IPsec ثابت می‌کند دو طرف بر سر کلیدها توافق دارند؛ اما مسیری به استخری که کلاینت گرفت نمی‌سازد. پس استخرهای دسترسی از راه دور به مسیر بازگشت نیاز دارند، یا مسیری ایستا به سمت رابط تونل یا پروتکل مسیریابی که خلاصه استخر را تزریق کند. پیشوندهای شعبه معمولاً از همان فرایند مسیریابی می‌آیند که بقیه سایت را سرویس می‌دهد.
ترجمه جایی است که دو نقش بیشترین برخورد را دارند. ترافیک سایت‌به‌سایت که باید نشانی‌های خصوصی خود را نگه دارد، به معافیت NAT محدود به همان دو پیشوند نیاز دارد، در هر دو جهت. کاربران سیار هم معمولاً به معافیت برای ترافیک درون تونل خود نیاز دارند، اما ترافیک اینترنتی آن‌ها یا با تونل تقسیم‌شده از تونل عبور نمی‌کند یا پس از NAT در مرکز خارج می‌شود. معاف کردن هر چیزی که از تونل می‌آید خطای کلاسیک است، چون ترجمه را از ترافیکی هم می‌گیرد که واقعاً به آن نیاز دارد.
قواعد معافیت را به باریکی قواعد پذیرش نگه دارید. اگر خلاصه استخر و پیشوند شعبه هم‌پوشانی داشته باشند، مسیر بازگشت مدت‌ها پیش از افتادن هر بسته مبهم می‌شود و نشانه به صورت سایتی ظاهر می‌شود که گاه‌به‌گاه یک زیرشبکه را از دست می‌دهد، نه به صورت نقص تمیز تونل.
موارد پذیرش که سیاست متقاطع را آشکار می‌کنند
چهار مورد بسازید و آن‌ها را به ترتیب اجرا کنید. میزبان شعبه به منبعی می‌رسد که فقط در شعبه است. کلاینت سیار از طریق نشانی استخر خود به همان منبع می‌رسد. کلاینت سیار پیشوندی از شعبه را امتحان می‌کند که نباید به آن دست بزند. همتای شعبه تلاش می‌کند از استخر دسترسی از راه دور نشانی بگیرد. دو مورد آخر همان‌هایی هستند که نمایه مشترک را می‌گیرند، چون در پایش معمول بی‌صدا شکست می‌خورند.
سپس لایه داده را تأیید کنید، نه پیکربندی را. show crypto ikev2 sa و show crypto ipsec sa می‌گویند کدام نمایه و کدام انتخابگرها هر جریان را حمل کرده‌اند، و show ip nat translations و شمارنده‌های تونل نشان می‌دهند که آیا مسیر بازگشت و معافیت واقعاً منطبق شده‌اند. یک tracer یا ضبط بسته روی رابط تونل حلقه را می‌بندد.
هویت مشاهده‌شده، نشانی استخر و سیاست انتخاب‌شده را کنار هر نتیجه بنویسید. دور زمانی تمام است که هر مورد به دقیقاً یک رکورد نگاشت شود و هیچ موردی برای عبور به استثنای موقت نیاز نداشته باشد.