با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
srcnat برای Traffic خروجی است
Chain یا Actionهای مربوط به srcnat زمانی استفاده میشوند که بخواهیم Source Address ترافیک خروجی را هنگام عبور از روتر تغییر دهیم؛ رایجترین سناریو این است که Clientهای شبکه خصوصی با Addressهای RFC۱۹۱۸ از طریق یک IP عمومی به اینترنت دسترسی پیدا کنند. NAT در RouterOS بر پایه Connection Tracking کار میکند، بنابراین Packetهای متعلق به یک Connection به صورت هماهنگ ترجمه میشوند؛ هنگام عیبیابی اینترنت فقط وجود یک Rule srcnat کافی نیست؛ باید بررسی کنی Traffic واقعاً از Interface خروجی مورد انتظار عبور میکند و Rule با Source Network و Out Interface درست Match میشود؛ اگر Rule بیش از حد عمومی باشد ممکن است Traffic بین شبکههای داخلی یا VPN را هم ترجمه کند و مسیر برگشت را پیچیده کند؛ اگر بیش از حد محدود باشد، بعضی Subnetها اینترنت نمیگیرند؛ ترتیب Ruleها نیز اهمیت دارد چون پردازش بر اساس Match انجام میشود؛ قبل از ساخت NAT، اول Routing را درست کن؛ NAT مسیر ایجاد نمیکند، فقط Address را در مسیر موجود تغییر میدهد؛ این تفکیک در عیبیابی بسیار مهم است
masquerade برای WAN متغیر رایج است
Masquerade نوعی Source NAT است که برای مسیرهایی با IP خروجی متغیر، مانند بسیاری از اتصالهای DHCP یا PPPoE، بسیار رایج است؛ تفاوت عملی آن با src-nat ثابت این است که Masquerade Address خروجی را متناسب با Interface تشخیص میدهد و برای WANهایی که IP تغییر میکند مدیریت سادهتری دارد؛ این سادگی نباید باعث شود Rule را بدون شرط مناسب روی همه Traffic اعمال کنی؛ بهتر است مشخص باشد کدام Source Networkها و کدام Out Interface یا Interface List مربوط به WAN هستند؛ اگر Masquerade روی مسیرهای داخلی یا VPN Match شود، Source واقعی Client پنهان میشود و کنترل دسترسی یا Logها میتوانند گمراهکننده شوند؛ در شبکهای با IP عمومی ثابت، src-nat مشخص ممکن است رفتار قابل پیشبینیتری داشته باشد؛ هنگام تغییر WAN یا Interface List، Ruleهای Masquerade را هم بررسی کن تا مسیر جدید واقعاً Match شود؛ اگر Client Gateway و Route دارد ولی اینترنت ندارد، Counter Rule NAT میتواند نشان دهد آیا Traffic به Rule میرسد یا نه. Masquerade ابزار مناسبی است، اما طراحی دقیق شرط Match از خود Action مهمتر است
dstnat برای Port Forward است
dstnat برای تغییر Destination Address یا Port ترافیکی استفاده میشود که به روتر میرسد و باید به Server یا سرویس دیگری در داخل شبکه هدایت شود. Port Forward نمونه رایج dstnat است؛ برای کارکرد درست، فقط NAT Rule کافی نیست؛ Server داخلی باید IP صحیح، Gateway برگشت و Firewall مناسب داشته باشد و Traffic ورودی نیز از WAN مورد انتظار وارد شود؛ اگر سرویس از بیرون باز نمیشود، ابتدا بررسی کن IP عمومی واقعاً روی روتر است یا پشت CGNAT قرار داری، سپس Counter Rule، Firewall Forward و دسترسی خود روتر به Server داخلی را ببین؛ باز کردن Port بدون نیاز واقعی سطح حمله را افزایش میدهد، بنابراین سرویس باید حداقل و محدود باشد و اگر امکان دارد از VPN برای دسترسی مدیریتی استفاده شود. Rule را با Destination Port، Protocol و در صورت نیاز Destination Address یا In Interface مشخص کن تا بیش از حد عمومی نشود؛ همچنین Hairpin NAT یا دسترسی داخلی به نام عمومی سناریوی جداگانهای است و نباید با مشکل Port Forward خارجی اشتباه گرفته شود؛ هر Port Forward باید مالک سرویس و دلیل کسبوکاری مشخص داشته باشد
ترتیب Ruleها مهم است
ترتیب Ruleهای NAT اهمیت دارد، چون Packet یا Connection بر اساس اولین Rule مناسب میتواند Action خاصی دریافت کند و Ruleهای عمومی اگر زودتر قرار بگیرند ممکن است Rule دقیقتر بعدی را بیاثر کنند؛ در RouterOS وقتی NAT یک Connection را پردازش میکند، Connection Tracking اطلاعات ترجمه را نگه میدارد؛ به همین دلیل بعد از تغییر Rule ممکن است Connection موجود هنوز رفتار قبلی را نشان دهد تا Connection دوباره ساخته شود؛ هنگام عیبیابی Counter هر Rule را ببین تا بفهمی Traffic واقعاً به کدام Rule میرسد. Ruleهایی با Comment واضح و شرطهای دقیق نگهداری را بسیار آسانتر میکنند؛ از انباشته شدن Ruleهای Disable یا آزمایشی بدون توضیح جلوگیری کن، چون بعداً ترتیب واقعی را مبهم میکنند؛ اگر Rule جدیدی باید قبل از Rule عمومی قرار گیرد، دلیل آن را مستند کن؛ تغییر ترتیب NAT در ساعات کاری میتواند روی Connectionهای فعال اثر بگذارد، بنابراین قبل از جابهجایی Plan و Backup داشته باش؛ خواندن Rule از بالا به پایین باید برای نفر بعدی داستان منطقی ترافیک را روشن کند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در RouterOS هر تغییر باید با درک Packet Flow و جای Rule در مسیر انجام شود؛ Bridge، VLAN، IP، Routing، NAT و Firewall به هم مرتبطاند و تغییر در یکی میتواند اثر بخش دیگری را تغییر دهد؛ قبل از ویرایش، Export یا Backup متناسب، ثبت نسخه RouterOS و شناخت Interface مدیریتی کمک میکند خطر قطع دسترسی کمتر شود
FastTrack روی بعضی صفها و Policyها اثر دارد
FastTrack در RouterOS برای سریعتر پردازش کردن برخی Connectionهای واجد شرایط استفاده میشود و میتواند بار CPU را کاهش دهد، اما چون بخشی از مسیر پردازش را میانبُر میزند، روی بعضی قابلیتها مانند Queue، Mangle، Accounting یا Policyهای خاص اثر میگذارد؛ بنابراین وقتی Traffic از نظر Routing و NAT درست است ولی Queue یا Mark مورد انتظار عمل نمیکند، وجود FastTrack باید بررسی شود؛ این ویژگی معمولاً با Ruleهای Firewall Filter و Connection State ارتباط دارد و نباید بدون فهم Packet Flow تغییر داده شود؛ در عیبیابی میتوان به Counter Rule FastTrack و رفتار Connectionهای جدید توجه کرد؛ خاموش کردن موقت FastTrack ممکن است برای تست مفید باشد، ولی باید اثر آن روی CPU و Throughput را هم در نظر گرفت؛ اگر طراحی شبکه به Policy Routing یا Queueهای دقیق وابسته است، سازگاری FastTrack با آن طراحی باید از مستندات بررسی شود؛ هدف این نیست که FastTrack همیشه روشن یا همیشه خاموش باشد؛ هدف این است که بدانی چرا فعال است و کدام Traffic را تحت تأثیر قرار میدهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: WinBox و CLI دو نمای متفاوت از همان Configuration هستند؛ مهمتر از ابزار، این است که بتوانی وضعیت Interface، Address، Route، Connection و Log را قبل و بعد از تغییر مقایسه کنی؛ اگر نتیجه با انتظار هماهنگ نیست، به جای اضافه کردن Ruleهای بیشتر، مسیر Packet و Ruleهای Matchشده را دوباره بررسی کن
فرض کن در Router MikroTik مشکلی گزارش شده و احتمال میدهی به NAT و Masquerade مربوط باشد. قبل از تغییر، وضعیت فعلی را با WinBox، Ping، Traceroute، Torch و Log بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- در بسیاری از Firewallها و NATها Ruleها از بالا به پایین ارزیابی میشوند و اولین Match میتواند نتیجه را تعیین کند؛ Rule درست در جای اشتباه ممکن است هرگز اجرا نشود
- تغییر دادن تنظیمات مرتبط با NAT و Masquerade قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره NAT و Masquerade فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با NAT و Masquerade، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با WinBox، Ping، Traceroute، Torch و Log وضعیت مرتبط با NAT و Masquerade را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با NAT و Masquerade بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- srcnat برای Traffic خروجی است
- masquerade برای WAN متغیر رایج است
- dstnat برای Port Forward است
- ترتیب Ruleها مهم است
- FastTrack روی بعضی صفها و Policyها اثر دارد
- قبل از تغییر گسترده در MikroTik، Export و Backup بگیر و برای کار Remote از Safe Mode استفاده کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: srcnat برای Traffic خروجی است. بعد بگو در عمل چطور آن را بررسی میکنی.
Chain یا Ruleهای srcnat برای تغییر Source Address در مسیر خروجی استفاده میشوند؛ Masquerade یک Action رایج برای WAN با IP متغیر است
این نکته را با یک مثال توضیح بده: masquerade برای WAN متغیر رایج است. بعد بگو در عمل چطور آن را بررسی میکنی.
Masquerade نوعی Source NAT مناسب IPهای WAN پویاست که Source را به IP Interface خروجی تغییر میدهد؛ Rule باید طوری محدود شود که فقط Traffic و Interface مورد نظر را شامل شود
این نکته را با یک مثال توضیح بده: dstnat برای Port Forward است. بعد بگو در عمل چطور آن را بررسی میکنی.
Port Forward یک اتصال ورودی روی IP/Port مشخص را به Host داخلی هدایت میکند؛ Public IP، CGNAT، NAT Rule، Firewall و سرویس داخلی را جدا بررسی کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
