آموزش میکروتیک MTCNA؛ شب ۱۲: مسیریابی دو شعبه و مسیر برگشت
فهرست نوشته
وجود مسیر رفت کافی نیست. امشب دو LAN را بدون NAT به هم وصل می‌کنیم تا مسیر برگشت، فایروال و Gateway کلاینت‌ها را جداگانه بسنجیم.
این نوشته بخشی از دورهٔ MTCNA در ۳۰ شب است. مبنای مثال‌ها RouterOS 7 و آزمایشگاه ایزولهٔ دوره است؛ پیش از تغییر، Snapshot و دسترسی Console داشته باشید.
توپولوژی و شرط شروع#
R1 آدرس LAN برابر 192.168.50.1/24 و Transit برابر 10.10.12.1/30 دارد. R2 در Transit آدرس .2 دارد. Route به شعبه روی R1 از شب یازدهم موجود است. NAT اینترنت روی R1 فقط خروجی WAN را می‌گیرد و نباید این ارتباط داخلی را ترجمه کند.
روی R2 تمیز، ether2 را برای LAN شعبه آماده کنید:
/interface bridge add name=bridge-branch protocol-mode=rstp
/interface bridge port add bridge=bridge-branch interface=ether2
/ip address add address=192.168.60.1/24 interface=bridge-branch
/ip route add dst-address=192.168.50.0/24 gateway=10.10.12.1 comment="MTCNA headquarters"
کلاینت شعبه 192.168.60.20/24 و Gateway آن 192.168.60.1 است. روی R2، مدیریت از Console و دسترسی شبکهٔ آزمایشگاهی باشد؛ WAN عمومی به آن وصل نکنید.
اجازهٔ محدود در فایروال R1#
فایروال شب چهارم خروجی LAN به WAN را مجاز کرده ولی Transit عضو WAN نیست. پیش از Rule نهایی forward، دو اجازهٔ مشخص اضافه کنید:
/ip firewall filter add chain=forward src-address=192.168.50.0/24 dst-address=192.168.60.0/24 action=accept place-before=[find comment="MTCNA forward final"] comment="MTCNA HQ to branch"
/ip firewall filter add chain=forward src-address=192.168.60.0/24 dst-address=192.168.50.0/24 action=accept place-before=[find comment="MTCNA forward final"] comment="MTCNA branch to HQ"
در محیط واقعی علاوه بر Prefix، ورودی مورد انتظار را هم محدود کنید تا آدرس مبدأ جعل‌شده از Interface دیگر پذیرفته نشود. روی R2 اگر سیاست Drop دارید، همین زوج Prefix را با Interface واقعی مجاز کنید. فایروال کلاینت‌ها نیز باید ICMP آزمایشگاهی را بپذیرد.
آزمون مرحله‌ای#
از A، Gateway محلی را Ping کنید. از R1، Next Hop را Ping کنید. از R2، کلاینت شعبه را Ping کنید. سپس از A به 192.168.60.20 بروید. در Linux کلاینت:
ip address
ip route
ping -c 4 192.168.50.1
traceroute -n 192.168.60.20
اگر Ping تولیدشده از R1 با آدرس Transit موفق است ولی A شکست می‌خورد، مسیر برگشت به LAN مرکزی و Rule forward را بررسی کنید. Ping خود روتر همیشه همان Source و Chain ترافیک کلاینت را ندارد.
خرابی و بازگشت#
روی R2، Route با Comment MTCNA headquarters را Disable کنید. انتظار داریم ارتباط Transit پابرجا باشد ولی پاسخ به A برنگردد. Route را Enable و تست را تکرار کنید. برای «حل» مشکل Masquerade روی Transit اضافه نکنید؛ این کار نبود مسیر برگشت را پنهان می‌کند.
خروجی قابل قبول، نمودار با مسیر رفت و برگشت و شواهد اتصال بدون NAT است. خودآزمایی: چرا Ping از R1 و A نتیجهٔ متفاوت می‌دهد؟ آیا Route روی R1 باعث می‌شود R2 شبکهٔ مرکزی را خودکار بشناسد؟ چرا دو کلاینت باید Gateway درست داشته باشند؟