چطور IP سیستم را در Windows، macOS و Linux پیدا کنیم؟

Private IP همان آدرسی است که دستگاه شما داخل شبکه محلی می‌گیرد؛ مثلاً چیزی شبیه 192.168.1.23. Public IP آدرسی است که اینترنت بیرونی از اتصال شما می‌بیند.

برای کارهایی مثل port forwarding، عیب‌یابی VPN یا بررسی لاگ، باید بدانید دنبال کدام IP هستید. خیلی از اشتباه‌ها از همین‌جا شروع می‌شود.

این دستورها IP داخلی کارت شبکه را نشان می‌دهند. اگر هم Wi-Fi و هم Ethernet فعال باشد، ممکن است چند آدرس ببینید.

برای Public IP ساده‌ترین راه استفاده از صفحه آی پی من است. اگر در terminal هستید، دستورهای زیر هم کار می‌کنند.

برای اینکه نتیجه این بررسی قابل اعتماد باشد، آن را فقط از یک زاویه نبینید. اگر موضوع درباره IP است، Public IP، ISP، ASN و موقعیت تقریبی را کنار هم بررسی کنید. اگر موضوع درباره دامنه است، وضعیت WHOIS، nameserver و رکوردهای DNS را با هم ببینید.

پیشنهاد عملی این است که اول از ابزار مرتبط همین مقاله شروع کنید؛ مثلاً نمایش آی پی من. بعد همان خروجی را با یک دستور local در سیستم خودتان مقایسه کنید. اختلاف بین ابزار آنلاین و خروجی سیستم معمولاً از DNS cache، VPN، Proxy، CDN یا resolver متفاوت می‌آید.

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

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

اشتباه دوم ترجمه کردن بی‌دلیل مفاهیم فنی است. اصطلاح‌هایی مثل Public IP، DNS، WHOIS، Ping، Traceroute، TTL، CDN و ASN بهتر است با همان نام فنی خوانده شوند؛ مهم این است که کاربردشان روشن باشد، نه اینکه برای هرکدام معادل‌سازی اجباری انجام دهیم.

اشتباه سوم این است که به جای بررسی مرحله‌ای، همه چیز را هم‌زمان تغییر بدهیم. اگر DNS، CDN، SSL و firewall را با هم دست‌کاری کنید، بعداً نمی‌فهمید مشکل از کدام تغییر بوده است. یک تغییر، یک تست و یک یادداشت کوتاه معمولاً مسیر عیب‌یابی را روشن‌تر می‌کند.

فرض کنید یک سرویس برای شما درست کار نمی‌کند، اما همکار یا کاربر دیگری همان سرویس را بدون مشکل باز می‌کند. در این حالت حدس زدن کافی نیست. باید سه چیز را جدا کنید: وضعیت سیستم شما، وضعیت شبکه‌ای که از آن وصل شده‌اید، و وضعیت سرویس مقصد. این مقاله کمک می‌کند همین سه لایه را مرحله‌به‌مرحله از هم جدا کنید.

اگر با تغییر شبکه، مثلاً رفتن از Wi-Fi به اینترنت موبایل، مشکل تغییر کرد، احتمالاً با DNS cache، routing، محدودیت ISP یا تفاوت Public IP طرف هستید. اگر روی همه شبکه‌ها مشکل ثابت بود، باید دامنه، DNS، SSL، server response یا تنظیمات خود سرویس را جدی‌تر بررسی کنید.

برای گزارش دادن مشکل، بهتر است خروجی‌ها را با زمان دقیق نگه دارید. مثلاً بنویسید «در ساعت ۱۴:۳۰ با اینترنت X، Public IP این بود، DNS این جواب را داد، Ping این‌قدر بود و Traceroute در این hop متوقف شد». چنین گزارشی برای یک آدم فنی خیلی ارزشمندتر از جمله‌ی کلی «سایت باز نمی‌شود» است.

یک یادداشت کوتاه بسازید و در آن دامنه یا IP، سیستم‌عامل، شبکه، کشور IP، DNS resolver و خروجی دستورها را بنویسید. لازم نیست گزارش پیچیده باشد؛ همین چند خط باعث می‌شود فرد بعدی بتواند مسیر شما را تکرار کند و به همان نتیجه برسد یا تفاوت را پیدا کند.

اگر نتیجه را در ticket پشتیبانی می‌فرستید، خروجی commandها را به‌صورت متن ارسال کنید، نه فقط screenshot. متن قابل جست‌وجو است، می‌شود آن را copy کرد و خطاهای کوچک مثل IP اشتباه، رکورد قدیمی یا resolver متفاوت سریع‌تر دیده می‌شوند.