آیا روتر میان دو همتای IPsec به IPsec نیاز دارد؟
روتر گذر، سرآیند بیرونی را ارسال می‌کند و هرگز رمزگشایی نمی‌کند. پیاده‌سازی IPsec متعلق به نقاط پایانی است و ممکن است شبیه‌ساز هیچ‌کدام را آن‌گونه که انتظار دارید مدل نکند.
تمرین آزمایشگاهی که می‌گوید «IPsec را میان دو سایت پیکربندی کنید» دو کار متفاوت را پنهان می‌کند. دو نقطهٔ پایانی تونل را پایان می‌دهند: مذاکره می‌کنند، احراز هویت می‌کنند، رمزنگاری و رمزگشایی می‌کنند. هر روتری در میانه، بسته‌هایی را ارسال می‌کند که سرآیند بیرونی‌شان از آنِ نقاط پایانی است، و این کار را بدون آگاهی از وجود تونل انجام می‌دهد.
تصمیم‌گیری اینکه از یک دستگاه چه کاری خواسته می‌شود، نخستین گام تمرین است. بیشتر سردرگمی در گزارش‌های آزمایشگاهی و بخش بزرگی از سردرگمی در نمودارهای تولید از آنجاست که «از IPsec پشتیبانی می‌کند» یک ویژگی به‌جای دو ویژگی گرفته می‌شود.
ارسال، پایان‌دادن نیست
در حالت تونل، سرآیند IP بیرونی به دستگاه‌هایی نشانه‌رفته است که تونل را پایان می‌دهند. روتر میانی مقصد را جست‌وجو و ارسال می‌کند، درست مانند هر بستهٔ دیگر، و بار مفیدی که حمل می‌کند برایش مات است.
این مات‌بودن عمدی است. روتر راز همتا را نگه نمی‌دارد، مذاکره‌ای انجام نمی‌دهد و به پایگاه سیاست نیازی ندارد. به مسیری به سمت نقطهٔ پایانی دور و اجازهٔ ارسال بسته نیاز دارد.
اشتباه گرفتن این دو به خطاهای واقعی می‌انجامد: درخواست از دیوار آتش گذر برای «اجازهٔ IPsec» در حالی که نیاز واقعی اجازه دادن به پروتکل 50 میان نشانی‌های مشخص است، یا انتظار اینکه دستگاه میانی برای بازرسی رمزگشایی کند در حالی که کلیدی ندارد.
دستگاه میانی باز هم چه کاری را باید درست انجام دهد
ارسال نیازهای خودش را دارد. مسیرها باید به هر دو نقطهٔ پایانی بیرونی برسند، و هر سیاستی در طول مسیر باید ترافیک بیرونی واقعی را مجاز کند نه شمارهٔ پورت حدس‌زده. قاعده‌ای که بر ضد TCP 443 نوشته شده چون کسی TLS را فرض کرده با پروتکل 50 جور درنمی‌آید.
ESP بومی پروتکل IP 50 است. نه TCP 50 است و نه UDP 50، و قاعده‌ای که ترافیک غیر TCP را مسدود کند آن را دور می‌ریزد. اگر طراحی از کپسوله‌سازی UDP استفاده کند، انتقال دیدنی به پورت کپسوله‌سازی تغییر می‌کند و سیاست باید با طراحی برگزیده بخواند.
اندازهٔ بسته هم مهم است. مسیری که یک کاوشگر کوچک را حمل می‌کند ثابت نمی‌کند که تبادل کپسوله‌شدهٔ کامل در آن جا می‌شود. مسیری که بسته‌های بزرگ را دور می‌ریزد می‌تواند مذاکره را موفق و بار کاری را ناموفق بگذارد، که مثل مشکل برنامه به نظر می‌رسد. پیش از سرزنش تونل، با ترافیکی به اندازهٔ بار کاری واقعی آزمایش کنید.
چرا شبیه‌ساز پرسش را تغییر می‌دهد
شبیه‌ساز روتری با فهرست کوتاه‌تر ویژگی‌ها نیست؛ مدلی با زیرمجموعه‌ای مستند و قواعد خودش دربارهٔ آنچه می‌توان دستگاه معینی را برای انجامش پیکربندی کرد است. پرسش‌های متداول Packet Tracer شرکت Cisco صریحاً می‌گوید دستگاه‌ها و پروتکل‌ها مدل‌های ساده‌شده‌اند.
پس پرسش به سه پرسش تبدیل می‌شود. آیا دستگاه شبیه‌سازی‌شده بسته‌هایی را که سناریو نیاز دارد ارسال می‌کند؟ آیا همان دستگاه سطح پیکربندی‌ای را که درس فرض می‌کند عرضه می‌کند؟ و آیا فرمان پذیرفته‌شده یعنی رفتار واقعاً شبیه‌سازی می‌شود یا فقط تجزیه می‌شود؟
فرمان غایب می‌تواند محدودیت مدل باشد نه خطا در پیکربندی شما. فرمان موجود می‌تواند نحو را بپذیرد بدون بازتولید همهٔ رفتار تولیدی. پیش از نتیجه‌گیری در هر جهت، راهنمای دستگاه در نسخهٔ نصب‌شده را بررسی کنید.
نوشتن شرط قبولی برای آزمایشگاه
برای درس underlay، شرط قبولی دسترسی به نقاط پایانی به‌همراه بسته‌های بیرونی است که از دستگاه میانی می‌گذرند. آن را با شمارنده‌های خود شبیه‌ساز یا نمای بسته‌ها اثبات کنید و پروتکلی را که انتظار دیدنش را دارید نام ببرید.
برای درس IPsec، وضعیت مذاکره و یک جریان محافظت‌شده از LAN به LAN را اضافه کنید. اگر شبیه‌ساز انجمن‌های امنیتی را نشان می‌دهد ثبتشان کنید. اگر نشان نمی‌دهد، این را در گزارش بگویید به‌جای آنکه القا کنید تونل بررسی شده است.
نسخهٔ شبیه‌ساز، دستگاه‌های برگزیده و هدف یادگیری را همراه پروندهٔ توپولوژی نگه دارید. همان سابقه است که به دیگری امکان می‌دهد تمرین را بازتولید کند و بفهمد کدام بخش‌ها مدل شده‌اند.
پیکربندی تولید به شواهد پلتفرم خودش نیاز دارد. بستهٔ شبیه‌سازی‌شدهٔ سبز نتیجهٔ آموزشی است، نه بیانیهٔ سازگاری دربارهٔ سخت‌افزاری که مستقر خواهید کرد.