آموزش میکروتیک MTCNA؛ شب ۱۶: مسیر بسته، Chainها و Connection tracking
فهرست نوشته
فایروال را از روی مقصد بسته می‌خوانیم: آیا مقصد خود روتر است، آیا از روتر عبور می‌کند، یا خود روتر آن را ساخته است؟ این تصمیم تعیین می‌کند کدام Chain را بررسی کنیم.
این نوشته بخشی از دورهٔ MTCNA در ۳۰ شب است. مبنای مثال‌ها RouterOS 7 و آزمایشگاه ایزولهٔ دوره است؛ پیش از تغییر، Snapshot و دسترسی Console داشته باشید.
سه مسیر و چهار حالت#
input برای بستهٔ مقصد روتر، forward برای عبور بین شبکه‌ها و output برای بستهٔ تولیدشده از روتر است. Ping خود R1 به اینترنت، آزمون Ruleهای forward کلاینت A نیست. ترافیک Bridge ممکن است مسیر متفاوتی داشته باشد.
در Connection tracking، new آغاز اتصالِ هنوز تثبیت‌نشده، established ارتباط شناخته‌شده، related ارتباط مرتبط و invalid بسته‌ای است که با وضعیت معتبر تطبیق ندارد. UDP هم رکورد Connection tracking دارد، با اینکه Handshake TCP ندارد. حالت untracked نیز در طراحی‌های دارای RAW و notrack مطرح است؛ آزمایشگاه ما notrack ندارد.
/ip firewall connection tracking print
/ip firewall connection print detail
/ip firewall filter print stats
/ip firewall nat print stats
آزمایشگاه مشاهدهٔ سه جریان#
از A به 192.168.50.1 Ping بگیرید: input. از A به میزبان شعبه وصل شوید: forward. از ترمینال R1 به Next Hop Ping بگیرید: output. Counterهای Ruleها را قبل و بعد ثبت کنید؛ لازم نیست Counterهای همهٔ شبکه را Reset کنید.
در کلاینت، یک اتصال HTTP یا SSH مجاز و تازه بسازید. Tuple آدرس و Port مبدأ/مقصد، Reply direction و Timeout رکورد مربوط را پیدا کنید. در ترافیک NATشده، مقصد و مبدأ دو جهت لزوماً مثل هم دیده نمی‌شوند؛ نگاشت را روی نمودار رسم کنید.
Action و ترتیب#
accept و drop تصمیم نهایی می‌دهند؛ reject همراه پاسخ رد مناسب است. log برای مشاهده است و به‌تنهایی سیاست عبور را تعیین نمی‌کند. jump به Chain سفارشی می‌رود و return از آن برمی‌گردد. بسته‌ای که یک Accept زودتر می‌گیرد، به Drop بعدی نمی‌رسد.
روی Clone، پیش از Rule نهایی، یک Rule Log محدود به Source کلاینت B، مقصد شعبه و ICMP بسازید؛ بعد از چند Ping غیرفعالش کنید. Log نامحدود ترافیک عمومی، CPU و حافظه را مصرف می‌کند و خروجی مفید را دفن می‌کند.
خرابی و بازگشت#
روی Clone، یک Drop مربوط به ارتباط جدید A به مقصد مشخص را قبل از Accept عمومی بگذارید. اتصال قبلی ممکن است با Rule established هنوز کار کند؛ یک نشست تازه بسازید تا نتیجه قابل تفسیر باشد. Rule آزمایشی را با Comment مشخص حذف کنید، نه با شماره‌ای که از خروجی قدیمی مانده است.
خروجی قابل قبول، سه جریان با Chain صحیح و یک رکورد Connection tracking توضیح‌داده‌شده است. خودآزمایی: چرا UDP در جدول دیده می‌شود؟ آیا related هر ترافیکی از IP مشابه است؟ چرا قرار دادن Drop زیر Accept همه‌گیر بی‌اثر است؟ آیا نبود رکورد الزاماً نبود ترافیک را ثابت می‌کند؟