Public IP و Private IP چه فرقی دارند؟

آدرس‌هایی مثل 192.168.1.10 یا 10.0.0.5 معمولاً داخل شبکه خانه یا شرکت استفاده می‌شوند. این آدرس‌ها در اینترنت عمومی route نمی‌شوند.

مودم یا روتر شما با NAT کاری می‌کند که چند دستگاه داخلی بتوانند از یک Public IP مشترک استفاده کنند.

وقتی وارد یک سایت می‌شوید، سرور معمولاً Public IP شما را می‌بیند. اگر VPN روشن باشد، Public IP شما همان IP سرور VPN خواهد بود.

برای دیدن هر دو نوع IP می‌توانید دستورهای زیر را اجرا کنید.

اگر می‌خواهید به یک سرور SSH وصل شوید، port forwarding تنظیم کنید یا IP را در firewall مجاز کنید، اشتباه گرفتن Public و Private IP وقت زیادی تلف می‌کند.

در لاگ‌های امنیتی هم معمولاً Public IP ثبت می‌شود؛ پس برای تحلیل درست باید آن را با ابزار بررسی IP و ASN چک کنید.

برای اینکه نتیجه این بررسی قابل اعتماد باشد، آن را فقط از یک زاویه نبینید. اگر موضوع درباره 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 متفاوت سریع‌تر دیده می‌شوند.