چگونه یک جریان VPN را با ASA packet-tracer مدل کنیم

packet-tracer روی ASA به یک پرسش باریک پاسخ می‌دهد: آیا این بسته، که با این تاپل از اینجا وارد می‌شود، مجاز است و به کجا می‌رود۔ به این پرسش پاسخ نمی‌دهد که آیا سر دور چیزی دریافت می‌کند۔ اشتباه رایج این است که تاپل بیرونی IKE را وارد کنید، در حالی که چیزی که می‌خواهید بیازمایید برنامه‌ای است که درون تونل حرکت می‌کند۔ نخست تاپل را اصلاح کنید، فازها را بخوانید، و سپس برای هر چیزی که شبیه‌ساز نمی‌بیند شواهد واقعی به دست آورید۔

گردش کار زیر فرض می‌کند که ACL، قاعده NAT و بافت tunnel-group پیش روی شماست۔ بدون آن‌ها خروجی سیاستی را توصیف می‌کند که نمی‌توانید بررسی کنید۔

گام 1: جریان درونی را با واژه‌های ساده بنویسید

پیش از تایپ هر چیزی برنامه را توصیف کنید۔ میزبان درون که SSH را به سروری پشت دروازه دور باز می‌کند، یک جریان TCP درونی با درگاه مبدأ مشخص است۔ همان جریانی است که ACL و فیلتر VPN ارزیابی می‌کنند، پس همان جریانی است که تایپ می‌کنید۔

آن را به صورت یک جمله بنویسید و سپس فیلد به فیلد ترجمه کنید:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

گام 2: ورودی و جهت را انتخاب کنید

ورودی همان رابطی است که بسته روی آن می‌رسد، نه رابطی که از آن خارج می‌شود۔ برای میزبان LAN که آغاز می‌کند، رابط inside است۔ برای بسته بازگشتی همان نشست، رابط outside است و تاپل برعکس می‌شود۔ نوشتن مقصد به جای مبدأ دومین راه رایج برای گرفتن ALLOW قانع‌کننده اما بی‌ربط است۔

درگاه‌ها هم جهت‌دارند۔ درگاه سرویس در درخواست آغازشده در فیلد مقصد قرار می‌گیرد و درگاه موقت کارخواه در فیلد مبدأ۔ مدلی با مقصد TCP برابر 500 برنامه TCP را توصیف می‌کند که روی 500 گوش می‌دهد؛ فقط به خاطر ظاهر شدن عدد در فرمان به آزمون IKE تبدیل نمی‌شود۔

گام 3: فازها را به ترتیب بخوانید

هر فاز در خروجی تصمیمی با یک مالک است: جستجوی مسیر، ACL، NAT و سپس انتخاب VPN یا تونل۔ آن‌ها را به ترتیب چاپ بخوانید و در نخستین فازی که با طراحی نمی‌خواند بایستید۔

NAT مردم را به دام می‌اندازد۔ اگر مبدأ ترجمه‌شده بیرون از crypto ACL که ترافیک تونل را انتخاب می‌کند بیفتد، جریان ممکن است مجاز شود و هرگز کپسوله نشود۔ ردگیری نشانی ترجمه‌شده را چاپ می‌کند، پس آن را با ترافیک موردنظر تونل مقایسه کنید نه با نشانی اصلی۔

گام 4: بررسی کنید کدام عبورها را انتخاب کرده‌اید

شکل detailed گزینه‌هایی می‌گیرد که بررسی‌ها را رد می‌کنند و Cisco گزینه bypass-checks را مستند می‌کند که ACL، فیلتر VPN، uRPF و بررسی‌های جعل IPsec را پوشش می‌دهد۔ ALLOWی که با این عبورها گرفته شود می‌گوید مسیر و NAT کار می‌کردند، نه اینکه سیاست بسته واقعی را می‌پذیرفت۔ گزینه‌ها را کنار نتیجه ثبت کنید۔

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

گام 5: شکاف را با تبادل واقعی ببندید

اجازه شبیه‌سازی‌شده در ASA می‌ایستد۔ اینکه دروازه دور بسته را رمزگشایی کرده باشد، سرور اتصال را پذیرفته باشد و پاسخی بازگشته باشد، مشاهده‌های جداگانه‌ای هستند۔ از شمارنده‌های نقطه پایانی استفاده کنید یا یک ضبط باریک در مسیر تأییدشده۔

برخی گزینه‌های trace و replay بسته می‌فرستند یا وضعیت را نگه می‌دارند۔ رفتار مستند برای نسخه خود و رویه تشخیصی تأییدشده‌تان را دنبال کنید، نه اینکه هر گونه را جستجوی فقط‌خواندنی بدانید۔

آنچه ردگیری هنوز نمی‌تواند به شما بگوید

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

با تاپل درونی آغاز کنید، در نخستین فازی که با طراحی تناقض دارد بایستید، و تنها آنگاه سراغ شواهد نقطه پایانی بروید۔ ردگیری یک اوراکل سیاست است، نه رسید تحویل۔