عیب‌یابی اینترنت، DNS و پورت‌های سرور لینوکس

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

۱. دامنهٔ مشکل را محدود کنید

مشخص کنید مشکل برای همهٔ کاربران است یا یک شبکه؛ فقط دامنه باز نمی‌شود یا IP هم در دسترس نیست؛ و از چه زمانی شروع شده است. تغییر اخیر در DNS، فایروال، برنامه یا گواهی را یادداشت کنید. یک خطای HTTPS با قطع کامل اینترنت یکسان نیست.

۲. آدرس و مسیر شبکه را بخوانید

ip -br address
ip route
ip -6 route

رابط مورد انتظار، آدرس اختصاص‌یافته و مسیر پیش‌فرض را با اطلاعات سرویس مقایسه کنید. وجود آدرس خصوصی در بعضی طراحی‌ها طبیعی است؛ آن را بدون دانستن معماری حذف نکنید. در شبکه‌های /32 یا Gateway خارج از subnet، تنظیم راهنمای همان سرویس ملاک است.

برای آزمایش ICMP از ping -c 4 همراه IP مجاز استفاده کنید. پاسخ‌ندادن Ping به‌تنهایی قطع شبکه را ثابت نمی‌کند؛ ICMP ممکن است مسدود باشد. بهتر است اتصال TCP به پورت مورد انتظار را هم بررسی کنید.

۳. DNS را جداگانه بررسی کنید

getent ahosts example.com
resolvectl status
resolvectl query example.com

example.com را با دامنهٔ خود جایگزین کنید. getent مسیر معمول حل نام سیستم را بررسی می‌کند؛ resolvectl در سیستم‌های دارای systemd-resolved کاربرد دارد. نبودن این ابزار الزاماً خطای DNS نیست. آدرس برگشتی را با IP مورد انتظار مقایسه کنید و رکوردهای A و AAAA را جدا در نظر بگیرید.

اگر IP کار می‌کند و فقط نام حل نمی‌شود، تنظیم resolver یا رکورد دامنه را بررسی کنید. فایل resolv.conf ممکن است توسط سرویس شبکه مدیریت شود؛ بازنویسی دستی آن می‌تواند موقت یا اشتباه باشد.

۴. آیا برنامه روی پورت گوش می‌دهد؟

sudo ss -lntp
sudo ss -lnup

خروجی اول سوکت‌های TCP در حال گوش‌دادن و پردازش مربوط را نشان می‌دهد؛ دومی UDP را بررسی می‌کند. آدرس 127.0.0.1 یعنی سرویس فقط از خود ماشین قابل دسترسی است. 0.0.0.0 معمولاً همهٔ رابط‌های IPv4 را شامل می‌شود؛ این به‌تنهایی بازبودن فایروال بیرونی را ثابت نمی‌کند.

۵. برنامه را از داخل سرور آزمایش کنید

برای یک وب‌سرور HTTP محلی روی پورت 80:

curl -I --connect-timeout 5 http://127.0.0.1/
systemctl status nginx --no-pager
sudo journalctl -u nginx --since "15 minutes ago" --no-pager

نام nginx صرفاً مثال است؛ سرویس واقعی خود را بررسی کنید. خطای 404 نشان می‌دهد یک پاسخ HTTP رسیده ولی مسیر پیدا نشده؛ 502 یا 504 می‌تواند به ارتباط با برنامهٔ پشت وب‌سرور مربوط باشد. قبل از Restart، لاگ مرتبط را بخوانید.

۶. تست بیرونی و فایروال

از رایانهٔ ویندوزی با PowerShell پورت واقعی را بررسی کنید:

Test-NetConnection SERVER_IP -Port 22

اگر برنامه محلی پاسخ می‌دهد ولی از بیرون Timeout دارید، UFW، فایروال پنل، قواعد شبکه و مسیر بین دو طرف را بررسی کنید. دستورهای زیر فقط وضعیت را می‌خوانند:

sudo ufw status verbose
sudo ufw status numbered

در IPv6 هم مسیر و قواعد را بررسی کنید. برای تشخیص اختلاف IPv4/IPv6 در یک سایت از curl -4 و curl -6 استفاده کنید. شکست IPv6 در سیستمی که IPv6 ندارد طبیعی است. برای تغییر قواعد، آموزش UFW را ببینید.

۷. تست HTTPS بدون دست‌کاری DNS

اگر IP جدید وب‌سرور را دارید، با دامنهٔ واقعی و IP واقعی می‌توان DNS را فقط برای همان درخواست کنار گذاشت و نام TLS را حفظ کرد:

curl -I --connect-timeout 5 --resolve example.com:443:SERVER_IP https://example.com/

SERVER_IP را جایگزین کنید. برای نادیده‌گرفتن خطای گواهی از -k به‌عنوان راه‌حل استفاده نکنید؛ نام دامنه، اعتبار گواهی و ساعت سیستم را بررسی کنید. راهنمای Nginx و HTTPS این بخش را تکمیل می‌کند.

چه اطلاعاتی برای پشتیبانی آماده کنیم؟

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

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: ابزار ss، فایروال اوبونتو

برای انتخاب زیرساخت، سرورهای لینوکس و چک‌لیست خرید VPS را ببینید. آموزش‌های مکمل در مرکز آموزش پرشین کلود در دسترس‌اند.