IPv4 و IPv6 چه تفاوتی دارند و کدام برای شما مهم‌تر است؟

IPv4 همان قالب آشنای 185.231.180.62 است. تعداد آدرس‌های IPv4 محدود است و به همین دلیل NAT در شبکه‌های خانگی و اپراتورها رایج شد.

IPv6 قالب طولانی‌تری دارد، مثل 2001:db8::1. فضای آدرس‌دهی آن بسیار بزرگ‌تر است و برای رشد اینترنت طراحی شده است.

اگر سیستم و ISP شما IPv6 بدهند، معمولاً در کنار IPv4 یک آدرس IPv6 هم روی interface می‌بینید. برای DNS هم رکورد AAAA نشانه مقصد IPv6 است.

گاهی سایت با IPv4 باز می‌شود اما با IPv6 مشکل دارد، یا برعکس. اگر کاربر فقط روی یک شبکه مشکل دارد، بررسی رکوردهای A و AAAA و تست جداگانه هر مسیر کمک زیادی می‌کند.

در آی‌پی اطلس می‌توانید رکوردهای A و AAAA دامنه را جداگانه بررسی کنید و ببینید مقصد IPv4 و IPv6 چه تفاوتی دارند.

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