رفع مشکل پورت فوروارد در میکروتیک؛ چرا سرویس از اینترنت باز نمی‌شود؟

پرونده سوم مدیر شبکه | داخل شبکه باز می‌شود؛ از بیرون نه!

برای رفع مشکل پورت فوروارد در میکروتیک، اولین کار ساختن یک قانون NAT دیگر نیست. ابتدا باید مشخص کنید درخواست بیرونی تا کجای مسیر می‌رسد: مودم، رابط WAN میکروتیک، سرور داخلی یا مسیر برگشت پاسخ.

فرض کنید یک سرویس وب داخل شبکه دارید. همکاران با آدرس داخلی آن را باز می‌کنند، روی میکروتیک هم قانون Port Forwarding ساخته‌اید؛ اما وقتی از بیرون شبکه امتحان می‌کنید، مرورگر منتظر می‌ماند و در نهایت خطا می‌دهد. قانون ظاهراً درست است. پس مشکل کجاست؟

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

هدف این مقاله فقط باز کردن یک پورت نیست. می‌خواهیم روشی داشته باشیم که با آن بتوانیم بین خرابی سرویس، اشتباه NAT، مسدودشدن در فایروال، NAT دو‌لایه و محدودیت اپراتور تفاوت بگذاریم.

این پرونده، سناریوی آموزشی طراحی‌شده است؛ گزارش اجرای یک پروژه واقعی نیست. نتیجه‌هایی که در ادامه توصیف می‌شوند، معیار مورد انتظار برای آزمایش هستند و جای خروجی ثبت‌شده از تجهیزات شما را نمی‌گیرند.

مسئله پرونده: قانون درست، در مرز اشتباه

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

قانونی که فقط روی میکروتیک ساخته‌اید، نمی‌تواند به‌تنهایی به مودم بگوید با اتصال ورودی چه کند. باید در هر مرزی که ترجمه مقصد لازم است، نگاشت مشخص و مجاز وجود داشته باشد.

سؤال اصلی ما این است:

آیا اتصال آزمایشی واقعاً به رابط ورودی میکروتیک رسیده است؟

اگر هنوز پاسخ این سؤال را ندارید، تغییر تصادفی پورت، اضافه‌کردن Masquerade یا خاموش‌کردن فایروال، تشخیص را سخت‌تر می‌کند.

قبل از شروع، نقشه مسیر را بنویسید

برای توضیح دقیق، از این آدرس‌های نمونه استفاده می‌کنیم. R1 نقش مودم/روتر بالادست و R2 نقش میکروتیک اصلی شبکه را دارد.

آدرس‌های 203.0.113.0/24 برای مستندسازی رزرو شده‌اند. این بخش را فقط به‌عنوان سمت بیرونی شبیه‌سازی‌شده در یک محیط مجازی ایزوله در نظر بگیرید؛ این آدرس‌ها، IP عمومی قابل استفاده روی اینترنت واقعی نیستند. در شبکه واقعی، مقصد تست باید آدرس عمومی واقعی اتصال شما باشد. [۱]

فرض می‌کنیم آدرس‌دهی و لینک‌ها از قبل آماده‌اند، R2 مسیر پیش‌فرض فعال به 192.168.10.1 دارد و نام رابط‌ها دقیقاً مطابق جدول است. روی روتر واقعی شما ممکن است WAN، رابط pppoe-out1 باشد و LAN روی bridge قرار بگیرد؛ نام‌های مثال را بدون تطبیق کپی نکنید.

این پرونده درباره دسترسی ورودی IPv4 است. انتشار سرویس روی IPv6 و سیاست فایروال آن، مسئله جداگانه‌ای دارد.

مرحله اول: ثابت کنید سرویس از یک دستگاه دیگر در LAN پاسخ می‌دهد

وقتی می‌گوییم «داخل شبکه باز می‌شود»، منظور بازشدن سرویس از یک رایانه دیگر در همان LAN است؛ بازشدن روی خود سرور با localhost کافی نیست.

از یک دستگاه داخلی، این آدرس را باز کنید:

http://10.30.40.10:8080/

یا در لینوکس و macOS اجرا کنید:

curl --noproxy '*' --connect-timeout 5 --max-time 10 http://10.30.40.10:8080/

در PowerShell ویندوز از curl.exe استفاده کنید تا با نام مستعار احتمالی curl اشتباه نشود.

اگر پاسخ نمی‌گیرید، فعلاً سراغ NAT نروید. ابتدا روشن‌بودن سرویس، IP سرور، پورت واقعی، اتصال شبکه و فایروال میزبان را بررسی کنید. سرویسی که فقط روی 127.0.0.1 گوش می‌دهد، از دستگاه دیگر قابل دسترسی نیست.

برای یک لابراتوار ساده، می‌توانید روی سرور لینوکسی دارای Python 3، یک پوشه اختصاصی با محتوای بی‌اهمیت بسازید:

mkdir -p "$HOME/ms-pf-lab"
printf '%s\n' 'MS-PF-LAB-OK' > "$HOME/ms-pf-lab/index.html"
python3 -m http.server 8080 --bind 10.30.40.10 --directory "$HOME/ms-pf-lab"

این دستور را روی دستگاهی اجرا کنید که آدرس 10.30.40.10 واقعاً متعلق به آن است. فایروال همان میزبان نیز باید اتصال آزمایش را طبق سیاست لابراتوار بپذیرد. پوشه اختصاصی باعث می‌شود اشتباهاً فایل‌های شخصی یا پروژه‌های دیگر را ارائه نکنید.

سرور HTTP پایتون برای این آزمایش است؛ مستندات Python آن را برای استفاده عملیاتی توصیه نمی‌کند. [۲]

نشانه عبور از مرحله اول: از دستگاه دیگر در LAN، پاسخ مشخص MS-PF-LAB-OK یا محتوای مورد انتظار سرویس خودتان را دریافت کنید.

مرحله دوم: تست داخلی و تست بیرونی را با هم اشتباه نگیرید

در شبکه واقعی، گوشی متصل به وای‌فای شرکت هنوز یک کاربر داخلی است. برای تست بیرونی، وای‌فای را قطع کنید و از اینترنت همراه یا یک اتصال مستقل استفاده کنید.

در لابراتوار این مقاله، رایانه 203.0.113.50 نقش کاربر بیرونی را دارد. از همان رایانه اجرا کنید:

curl --noproxy '*' --connect-timeout 5 --max-time 10 http://203.0.113.10:18080/

پورت 18080 در سمت بیرونی و پورت 8080 روی سرور قرار دارد. متفاوت‌بودن این دو، اشکالی ندارد؛ کافی است نگاشت‌ها با همین تصمیم سازگار باشند.

این تست مشخصاً برای HTTP روی TCP است. نتیجه آن را به سرویس UDP یا برنامه‌ای با پروتکل دیگر تعمیم ندهید. همچنین بازبودن TCP به‌تنهایی، صحت کامل برنامه، احراز هویت یا تنظیمات HTTPS را ثابت نمی‌کند.

اگر از نام دامنه استفاده می‌کنید، یک بار با IP صحیح هم تست کنید تا خطای DNS یا رکورد قدیمی را از مسئله انتقال پورت جدا کنید. برای سرویس‌های واقعی وابسته به نام میزبان و TLS، تست نهایی باید با همان نام و پروتکل مورد استفاده کاربران انجام شود.

مرحله سوم: قانون پورت فوروارد روی میکروتیک را دقیق بخوانید

در این سناریو، میکروتیک R2 باید اتصال ورودی به آدرس WAN خودش و پورت 18080 را به سرور داخلی و پورت 8080 برساند.

قانون نمونه روی R2 چنین است:

/ip firewall nat add chain=dstnat action=dst-nat in-interface=ether1 dst-address=192.168.10.2 protocol=tcp dst-port=18080 src-address=203.0.113.50 to-addresses=10.30.40.10 to-ports=8080 comment="LAB-PF-R2"

محدودیت src-address برای این لابراتوار فقط رایانه آزمایش را مجاز می‌کند. در شبکه واقعی، آن را با مبدأ مجاز و قابل مشاهده در همان نقطه تطبیق دهید؛ IP خصوصی گوشی، لزوماً IP مبدأیی نیست که روتر از اینترنت می‌بیند.

این قانون را برای هر بار تست دوباره اضافه نکنید. اگر از قبل وجود دارد، همان قانون را بررسی کنید. در WinBox، مسیر IP > Firewall > NAT را باز کنید و این موارد را بخوانید:

• رابط ورودی واقعاً همان رابطی باشد که بسته از آن وارد R2 می‌شود.
• آدرس مقصد، آدرسی باشد که بسته هنگام رسیدن به R2 دارد.
• پروتکل tcp و پورت ورودی 18080 باشد.
• مقصد ترجمه‌شده 10.30.40.10 و پورت مقصد نهایی 8080 باشد.
• قانون غیرفعال نباشد و قانون دیگری پیش از آن، اتصال مورد نظر را با نتیجه متفاوت تطبیق ندهد.

در این توپولوژی، قرار دادن آدرس بیرونی R1 یعنی 203.0.113.10 در شرط dst-address قانون R2 اشتباه است. بعد از نگاشت درست روی R1، بسته باید با مقصد 192.168.10.2:18080 به R2 برسد.

برای دیدن جزئیات قانون:

/ip firewall nat print detail where comment="LAB-PF-R2"

مرحله چهارم: شمارنده قانون را قبل و بعد از تست مقایسه کنید

روی R2 اجرا کنید:

/ip firewall nat print stats where comment="LAB-PF-R2"

عددها را یادداشت کنید، از رایانه بیرونی یک اتصال جدید بسازید و دوباره شمارنده را ببینید.

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

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

در RouterOS تصمیم NAT برای اولین بسته اتصال گرفته می‌شود و Connection Tracking آن را برای ادامه همان اتصال نگه می‌دارد. بنابراین شمارنده NAT را مانند شمارنده تمام بسته‌های یک نشست تفسیر نکنید. بعد از تغییر قانون، با یک اتصال تازه تست کنید؛ اگر یک ورودی قدیمی هنوز مزاحم است، فقط همان اتصال شناسایی‌شده لابراتوار را حذف کنید یا منتظر انقضای آن بمانید. پاک‌کردن کل جدول اتصال روی روتر عملیاتی می‌تواند ارتباط کاربران را قطع کند. [۳]

مرحله پنجم: آیا درخواست روی WAN میکروتیک دیده می‌شود؟

برای دیدن ترافیک ورودی مرتبط، روی R2 اجرا کنید:

/tool sniffer quick interface=ether1 ip-protocol=tcp port=18080

هم‌زمان از رایانه بیرونی تست را تکرار کنید. رابط و پورت این دستور مختص مثال هستند. برای پایان نمایش زنده از Q استفاده کنید. مستندات ابزار، فیلترهای حالت quick و نحوه توقف آن را توضیح داده است. [۴]

اگر بسته روی WAN دیده می‌شود اما شمارنده قانون NAT تغییر نمی‌کند، دوباره شروط قانون، ترتیب قوانین و وضعیت اتصال را بررسی کنید. اگر بسته روی WAN دیده نمی‌شود، مسیر قبل از R2 را بررسی کنید: آدرس مقصد تست، رابط انتخاب‌شده، مودم بالادست و در شبکه واقعی، سرویس ورودی اپراتور.

ندیدن بسته نیز فقط وقتی سرنخ معتبری است که محل مشاهده و فیلتر درست باشند. Sniffer همیشه همه ترافیک سخت‌افزاری را نمایش نمی‌دهد؛ در لابراتوار ساده با مسیریابی نرم‌افزاری، بررسی شفاف‌تر است. همچنین اجرای ابزارهای مشاهده می‌تواند رفتار FastTrack را تغییر دهد؛ موفقیت را یک بار پس از بستن ابزار هم دوباره بررسی کنید. [۵، ۶]

در سناریوی طراحی‌شده این پرونده، انتظار داریم درخواست روی سمت بیرونی R1 دیده شود، اما تا پیش از اصلاح نگاشت بالادست به WAN روتر R2 نرسد. این انتظار را باید با مشاهده در هر دو نقطه تأیید کنید.

مرحله ششم: آدرس خصوصی WAN چه چیزی را نشان می‌دهد؟

در مثال، WAN میکروتیک 192.168.10.2 است. این آدرس خصوصی است و نشان می‌دهد میکروتیک مستقیماً دارنده آدرس عمومی اتصال نیست.

اکنون باید یک دستگاه عقب‌تر برویم: روی رابط WAN مودم چه آدرسی قرار دارد؟ آیا مودم خودش پشت NAT دستگاه دیگری است؟ آدرس عمومی خروجی اتصال با آدرس WAN کدام دستگاه منطبق است؟

این سه وضعیت را از هم جدا کنید:

سه محدوده رایج خصوصی IPv4 عبارت‌اند از 10.0.0.0/8، 172.16.0.0/12 و 192.168.0.0/16. همه آدرس‌هایی که با 172 شروع می‌شوند خصوصی نیستند؛ محدوده دقیق مهم است. [۷]

فضای 100.64.0.0/10 نیز برای آدرس‌دهی اشتراکی در شبکه ارائه‌دهنده تعریف شده است. دیدن آن روی WAN مودم، سرنخ مهمی برای بررسی CGNAT است. بااین‌حال، خصوصی‌بودن WAN خود میکروتیک به‌تنهایی برای نتیجه‌گیری درباره CGNAT کافی نیست؛ شاید فقط مودم خودتان جلوی آن قرار دارد. [۸]

مرحله هفتم: اصلاح علت اصلی؛ نگاشت ورودی روی روتر بالادست

در این پرونده، R1 تحت مدیریت ماست و نگاشت ورودی سرویس روی آن جا افتاده است. اگر R1 یک مودم معمولی باشد، در بخش Port Forwarding، Virtual Server یا نام مشابه، این مقادیر را ثبت می‌کنیم:

اگر R1 هم RouterOS باشد، قانون نمونه روی R1 به شکل زیر است:

/ip firewall nat add chain=dstnat action=dst-nat in-interface=ether1 dst-address=203.0.113.10 protocol=tcp dst-port=18080 src-address=203.0.113.50 to-addresses=192.168.10.2 to-ports=18080 comment="LAB-PF-R1"

حالا دو نگاشت مجزا داریم: R1 اتصال را به WAN میکروتیک می‌دهد و R2 آن را به سرور منتقل می‌کند. در R1 نباید بدون طراحی مسیر، آدرس سرور 10.30.40.10 را جای مقصد داخلی بگذارید؛ شبکه متصل به سمت داخلی R1 در این مثال 192.168.10.0/24 است.

WAN میکروتیک نیز باید آدرس پایداری در شبکه مودم داشته باشد؛ با آدرس‌دهی ثابت صحیح یا رزرو DHCP. اگر این آدرس عوض شود، نگاشت مودم به مقصد قبلی اشاره خواهد کرد.

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

مرحله هشتم: NAT مسیر می‌دهد؛ Filter اجازه عبور می‌دهد

اگر درخواست از مرزهای NAT عبور کند، هنوز باید فایروال اجازه انتقال آن را بدهد. ترافیکی که به سرور پشت روتر می‌رود در زنجیره forward بررسی می‌شود؛ زنجیره input مربوط به ترافیک مقصد خود روتر است. [۹]

نکته تعیین‌کننده دیگر، زمان ترجمه مقصد است: در مسیر معمول این مثال، dstnat پیش از بررسی forward انجام شده است. در نتیجه قانون Filter باید مقصد ترجمه‌شده را ببیند. [۱۰]

اگر سیاست فعلی فایروال این اتصال را نمی‌پذیرد، نمونه قانون محدود برای R2 چنین است:

/ip firewall filter add chain=forward action=accept in-interface=ether1 out-interface=ether2 src-address=203.0.113.50 dst-address=10.30.40.10 protocol=tcp dst-port=8080 connection-nat-state=dstnat comment="LAB-PF-R2-ALLOW"

و روی R1، در صورت نیاز:

/ip firewall filter add chain=forward action=accept in-interface=ether1 out-interface=ether2 src-address=203.0.113.50 dst-address=192.168.10.2 protocol=tcp dst-port=18080 connection-nat-state=dstnat comment="LAB-PF-R1-ALLOW"

این دستورها قانون را به انتهای فهرست اضافه می‌کنند؛ اگر پیش از آن یک Drop منطبق وجود داشته باشد، صرف افزودن قانون کافی نیست. در WinBox، قانون آزمایش را با بررسی سیاست موجود، پیش از Drop مسدودکننده قرار دهید. آن را بی‌دلیل به ابتدای کل فایروال منتقل نکنید.

فرض این نمونه وجود سیاست صحیح برای عبور ترافیک برگشتی established,related روی هر دو روتر است. قوانین بالا جایگزین پیکربندی کامل فایروال نیستند. اگر سیاست موجود همین جریان را از قبل مجاز می‌کند، قانون تکراری نسازید.

در R2، پورت Filter برابر 8080 است؛ چون پورت ورودی 18080 پیش‌تر ترجمه شده است. در R1 پورت مقصد بعد از ترجمه همچنان 18080 است. همین تفاوت کوچک می‌تواند علت کارنکردن یک قانون ظاهراً درست باشد.

مرحله نهم: مسیر برگشت پاسخ را فراموش نکنید

دسترسی از یک رایانه هم‌شبکه به سرور، درست‌بودن Default Gateway سرور را ثابت نمی‌کند. دو دستگاه هم‌شبکه ممکن است بدون استفاده از دروازه پیش‌فرض با هم ارتباط داشته باشند؛ اما پاسخ به کاربر بیرونی به مسیر برگشت نیاز دارد.

در این مثال، Gateway سرور باید 10.30.40.1 باشد و R2 برای رسیدن به شبکه بیرونی از R1 استفاده کند. اگر سرور چند کارت شبکه یا چند مسیر پیش‌فرض دارد، ممکن است پاسخ از مسیری متفاوت خارج شود.

برای مشاهده آدرس‌ها و مسیر پیش‌فرض R2:

/ip address print
/ip route print where dst-address=0.0.0.0/0

صرف وجود یک ردیف مسیر کافی نیست؛ فعال‌بودن آن، دسترس‌پذیری Gateway و جدول مسیریابی مؤثر را بررسی کنید. در شبکه‌های چند WAN یا دارای Policy Routing، مسیر پاسخ باید متناسب با همان اتصال طراحی شده باشد.

اگر بسته به سرور می‌رسد اما پاسخی برنمی‌گردد، فایروال میزبان، سرویس و مسیر برگشت را بررسی کنید. اگر پاسخ از سرور خارج می‌شود، نقطه بعدی را مشاهده کنید. افزودن یک Masquerade گسترده برای پنهان‌کردن مشکل Gateway، تشخیص و ثبت مبدأ واقعی اتصال را مخدوش می‌کند.

مرحله دهم: موفقیت را با پاسخ همان سرویس تأیید کنید

بعد از اصلاح R1 و بررسی سیاست فایروال، تست را از همان رایانه بیرونی تکرار کنید:

curl --noproxy '*' --connect-timeout 5 --max-time 10 http://203.0.113.10:18080/

برای این لابراتوار، موفقیت یعنی دریافت پاسخ MS-PF-LAB-OK از سرور تعیین‌شده. هم‌زمان باید بتوانید افزایش شمارنده نگاشت‌ها و درخواست متناظر در گزارش HTTP سرور را مشاهده کنید.

اگر یک صفحه ورود مودم، خطای سرویس دیگری یا پاسخ ناخواسته می‌بینید، هنوز نتیجه مطلوب نگرفته‌اید؛ بازشدن «یک صفحه» کافی نیست. مقصد، پورت و احتمال تداخل با سرویس مدیریتی روتر بالادست را بررسی کنید.

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

اگر CGNAT باشد، چه چیزی فرق می‌کند؟

در پرونده ما، هر دو روتر در اختیار مدیر شبکه هستند. اما اگر یک NAT دیگر در شبکه اپراتور قرار داشته باشد، شما معمولاً نمی‌توانید نگاشت ورودی آن را از پنل مودم تنظیم کنید.

در این وضعیت، ساختن قانون بیشتر روی میکروتیک، کنترل آن مرز بالادست را ایجاد نمی‌کند. باید از ارائه‌دهنده درباره داشتن IPv4 عمومی، پشتیبانی اتصال ورودی و محدودیت‌های سرویس سؤال کنید. بسته به نیاز، راه‌حل ممکن است IPv4 عمومی قابل دسترسی، سرویس نگاشت ارائه‌شده توسط اپراتور، یا یک معماری دسترسی مبتنی بر VPN و نقطه واسط باشد.

IP عمومی و IP ثابت یک مفهوم نیستند. یک IP عمومی پویا نیز می‌تواند برای اتصال ورودی مناسب باشد، به شرط پشتیبانی سرویس و به‌روز بودن آدرس مقصد. DDNS تغییر نام به آدرس را مدیریت می‌کند؛ NAT اپراتور را حذف نمی‌کند.

اگر از بیرون باز می‌شود اما از داخل با IP عمومی باز نمی‌شود

این وضعیت با مسئله اصلی پرونده متفاوت است. اکنون دسترسی بیرونی برقرار است، اما کاربر داخلی با نشانی عمومی مشکل دارد.

در چنین حالتی، شرایط Hairpin NAT یا NAT Loopback، تطبیق قانون برای ورودی LAN و مسیر برگشت را بررسی کنید. قانونی که فقط ورودی WAN را می‌پذیرد، لزوماً با درخواست کاربر داخلی تطبیق پیدا نمی‌کند. [۳]

برای سرویس‌های دارای نام، Split DNS نیز می‌تواند بخشی از طراحی باشد: نام داخلی به مقصد داخلی مناسب اشاره کند. اگر پورت بیرونی و داخلی متفاوت‌اند، DNS به‌تنهایی پورت URL را عوض نمی‌کند؛ در این مثال، اشاره نام به سرور داخلی باعث نمی‌شود درخواست پورت 18080 خودکار به 8080 تبدیل شود.

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

جدول تصمیم برای رفع مشکل پورت فوروارد در میکروتیک

این جدول، محل شروع بررسی را پیشنهاد می‌کند؛ از روی یک شمارنده یا یک Timeout به‌تنهایی حکم قطعی صادر نمی‌کند.

اشتباه‌هایی که این پرونده را طولانی‌تر می‌کنند

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

یکی‌گرفتن Timeout با علت خرابی: Timeout می‌گوید در زمان انتظار پاسخ کافی دریافت نشده است؛ نمی‌گوید کدام دستگاه بسته را متوقف کرده است. Connection Refused نیز سرنخ متفاوتی دارد، اما به‌تنهایی هویت دستگاه تولیدکننده پاسخ را ثابت نمی‌کند.

قرار دادن همه ترافیک در DMZ یا خاموش‌کردن فایروال: در این آزمایش فقط یک سرویس و یک مبدأ لازم داریم. گسترش ناگهانی دسترسی، هم دامنه تغییر را زیاد می‌کند و هم علت واقعی را پنهان می‌سازد.

تست پورت اشتباه: مقصد بیرونی 18080 است، سرویس داخلی 8080. این دو را در نشانی تست، NAT و Filter متناسب با محل بررسی انتخاب کنید.

اعتماد به تست Ping: پاسخ ICMP درباره همان آزمون اطلاعات می‌دهد؛ بازبودن HTTP روی TCP را ثابت نمی‌کند. نرسیدن پاسخ Ping هم به‌تنهایی نشانه بسته‌بودن پورت سرویس نیست.

پایان لابراتوار: فقط تغییرات همین آزمایش را جمع کنید

پس از ثبت نتیجه، سرور HTTP آزمایشی را با Ctrl+C متوقف کنید. نگاشت‌های موقت R1 و R2 و قوانین Filter مرتبط را با نام‌های LAB-PF-R1، LAB-PF-R2، LAB-PF-R1-ALLOW و LAB-PF-R2-ALLOW پیدا کنید و فقط مواردی را که برای همین آزمایش ساخته‌اید غیرفعال یا حذف کنید.

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

در این پرونده، علت طراحی‌شده، نبود نگاشت ورودی روی روتر بالادست بود. ملاک تشخیص، شکل ظاهری قانون میکروتیک نبود؛ مشاهده درخواست در R1، نرسیدن آن به R2 و برقراری زنجیره درست پس از اصلاح نگاشت بود.

پرسش‌های متداول

آیا برای پورت فوروارد در میکروتیک حتماً IP ثابت لازم است؟

خیر. برای الگوی معمول اتصال ورودی IPv4، باید آدرس عمومی قابل دسترسی و امکان دریافت اتصال ورودی داشته باشید. ثابت یا پویا بودن آن موضوع دیگری است. در حالت پویا، آدرس فعلی یا نام DDNS باید درست باشد.

چرا شمارنده NAT بالا می‌رود ولی سایت باز نمی‌شود؟

افزایش شمارنده نشان می‌دهد اتصال با قانون تطبیق داشته است؛ نه اینکه سرور جواب داده است. مقصد و پورت ترجمه‌شده، Filter، فایروال میزبان، وضعیت سرویس و مسیر پاسخ را بررسی کنید.

اگر WAN میکروتیک خصوصی باشد، حتماً CGNAT داریم؟

خیر. ممکن است فقط مودم شما در حالت Router باشد. ابتدا WAN مودم و ساختار بالادست را بررسی کنید؛ سپس در صورت نیاز وضعیت را از ISP تأیید بگیرید.

آیا تغییر پورت بیرونی مشکل را حل می‌کند؟

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

آیا همین قوانین برای همه شبکه‌ها مناسب‌اند؟

خیر. آدرس‌ها، نام رابط‌ها، مبدأ مجاز، سیاست Filter، مسیر برگشت و حتی نوع پروتکل باید با شبکه شما تطبیق داشته باشند. نمونه‌های این مقاله برای توپولوژی مشخص همین لابراتوار نوشته شده‌اند.

پرونده مرتبط برای تمرین عیب‌یابی

اگر می‌خواهید همین شیوه بررسی مرحله‌ای را در یک مسئله زیرساختی دیگر دنبال کنید، پرونده رفع مشکل Join نشدن به دامین؛ بررسی DNS و پیدا نشدن Domain Controller را هم بخوانید. در آن مسئله نیز، پیش از تغییر تنظیمات باید روشن شود کدام بخش از فرایند واقعاً شکست خورده است.

پرونده‌های بعدی در بخش پرونده‌های عیب‌یابی مدیر شبکه قرار می‌گیرند.

منابع فنی