کدام VRF به همتای VPN می‌رسد و کدام بسته را حمل می‌کند؟

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

دو جست‌وجو، یک تونل

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

مستندات Cisco برای IPsec آگاه از VRF آن‌ها را VRF درگاه جلو و VRF درونی می‌نامد. درگاه جلو انتقال رمزنگاری‌شده را حمل می‌کند، و بافت درونی ترافیک محافظت‌شده را حمل می‌کند. هیچ‌چیز در نام‌گذاری تونل به نام یک مشتری باعث ظهور هیچ‌یک از دو مسیر نمی‌شود.

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

جست‌وجوی انتقال برای همتا را تأیید کنید

از درگاه جلو شروع کنید، زیرا تونلی که نمی‌تواند به همتای خود برسد هرگز یک بسته محافظت‌شده را عبور نمی‌دهد. در IOS مسیر به همتا را درون VRF انتقال بخواهید، نه در جدول سراسری.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

فرمان نخست پاسخ می‌دهد که آیا نشانی همتا در آن بافت قابل دسترسی است، دومی VRFهایی را که واقعاً وجود دارند فهرست می‌کند، و سومی نشان می‌دهد آیا پیوند امنیتی برقرار شده است. نشانی همتایی که فقط در جدول سراسری تفکیک می‌شود اشتباه کلاسیک درگاه جلو است و به شکل مذاکره IKEای ظاهر می‌شود که هرگز آغاز نمی‌شود.

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

جست‌وجوی درونی برای سرور را تأیید کنید

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

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

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

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

تنظیم را جایی بگذارید که مدل انتظار دارد

همین مستندات میان مدل‌های پیکربندی تمایز می‌گذارد، و تنظیمی که به یکی تعلق دارد لزوماً به دیگری تعلق ندارد. برای رابط‌های تونل که از حفاظت تونل استفاده می‌کنند، VRF درونی روی رابط تونل تعریف می‌شود. برای طرح‌های مبتنی بر crypto map، VRF درونی بخشی از ورودی crypto map است. جابه‌جا کردن فرمانی با نام مشابه میان مدل‌ها بدون بررسی نقش آن، همان راهی است که یک طرح کارآمد به طرحی متناوب تبدیل می‌شود.

مسیریابی و هویت دو موضوع جداگانه‌اند. دسترسی‌پذیری هرگز جایگزین نمایه همتایی که دستگاه می‌پذیرد نمی‌شود، و تغییر نام VRF نباید اعتبارنامه‌های ارائه‌شده را تغییر دهد. پس از هر تغییر هر دو را بررسی کنید، زیرا تونلی که با نمایه اشتباه مذاکره می‌کند می‌تواند همچنان پیوند تشکیل دهد و چیزی ارسال نکند.

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