
هنگام بررسی VPN، هر دو IPv4 و IPv6 را بررسی کنید
IPv6 را همراه IPv4 بررسی کنید؛ مسیر مورد انتظار را ثبت کنید، نبود اتصال را جدا بدانید و از یک آزمون نتیجهٔ کلی نگیرید.
ترجمهشده از انگلیسی با Codex editorial review
صفحهٔ آدرس عمومی ممکن است پس از اتصال VPN، یک IPv4 متفاوت نشان دهد و هنوز پرسش مهمی بیپاسخ بماند: وقتی برنامه از IPv6 استفاده میکند چه میشود؟ بسیاری از اتصالهای روزمره بیش از یک خانوادهٔ آدرس دارند، در حالی که بعضی شبکهها فقط یکی را ارائه میکنند. بررسی مفید، قابلیت موجود و رفتار مورد نظر پیکربندی انتخابی را میسنجد. هدف، روشن کردن اجباری IPv6 در همهجا یا خاموش کردن آن در همهجا نیست؛ هدف این است که یک درخواست موفق را شرح کامل تمام مسیرهای ممکن دستگاه ندانیم.
بررسی IPv6 را با نتیجهٔ مورد انتظار شروع کنید
بپرسید کلاینت و پیکربندی قرار است IPv6 را منتقل کنند، آن را بیرون تونل ببندند یا روش مستند دیگری داشته باشند. اینها سیاستهای متفاوتاند. نبود نتیجهٔ IPv6 ممکن است در یک تنظیم طبیعی و در دیگری خطا باشد. بدون رفتار مورد انتظار، تفسیر آزمون دشوار است.
آدرس نقطهٔ اتصال و ترافیک داخل تونل هم دو مفهوم جدا هستند. اتصال به سرور VPN از طریق IPv4 بهتنهایی مشخص نمیکند تونل چه خانوادههای آدرسی را حمل میکند. به همین ترتیب، دیدن نقطهٔ اتصال IPv6 ثابت نمیکند همهٔ برنامهها پس از آن IPv6 استفاده کنند. قابلیت به کل پیکربندی و شبکهٔ پیرامون وابسته است.
پیش از ویرایش، راهنمای پروتکل و کلاینت را بخوانید. مقایسهٔ VLESS و WireGuard به شناخت نوع تنظیم کمک میکند، ولی نام پروتکل بهتنهایی سیاست مسیریابی نیست. برنامه، نسخه، پیکربندی انتخابی و فعال بودن تونل تفکیکی یا استثناهای محلی را ثبت کنید.
مشخص کنید شبکهٔ عادی چه فراهم میکند
اگر مقایسهٔ غیرحساس بدون VPN مناسب است، بررسی کنید شبکهٔ پایه IPv4، IPv6 یا هر دو را بهصورت سالم ارائه میکند. فقط برای ساختن مبنا، تونل اجباری کاری را قطع نکنید و فعالیت حساس را آشکار نکنید. اگر سیاست اجازه نمیدهد، محدودیت را ثبت کنید و روش تأییدشده از مدیر بخواهید.
از تشخیصی استفاده کنید که خانوادهها را جدا گزارش میدهد. صفحهای با یک آدرس شاید فقط نخستین مسیر سالم را به کار برده باشد. مشخصات Happy Eyeballs از IETF توضیح میدهد برنامهها چگونه آدرسها یا خانوادههای جایگزین را برای کاهش تأخیر امتحان میکنند. این برای کاربری مفید است، اما باز شدن صفحه لزوماً کارکرد هر دو مسیر را اثبات نمیکند.
مشاهده را به شبکهٔ واقعی پیوند دهید. نتیجهٔ وایفای خانه وضعیت دادهٔ موبایل نیست، و لپتاپ متصل به اشتراک اینترنت لزوماً معادل تلفن فراهمکنندهٔ اتصال نیست. روش دسترسی و زمان را بنویسید. اگر آزمون میگوید IPv6 موجود نیست، برای پر کردن جدول آدرس نسازید یا نبود آن را نشت ننامید.
با تونل فعال همان مشاهدهها را تکرار کنید
پیکربندی مورد نظر را وصل کنید و با همان دستگاه و برنامه درخواست تازه بفرستید. IPv4 و در صورت وجود IPv6 را جدا ثبت کنید. شکست را شکست بنویسید، نه اینکه چون صفحهٔ دیگری باز شده آن را حذف کنید. هنگام مقایسه، نقطهٔ اتصال را ثابت نگه دارید.
آزمون مرورگر درخواستهای مرورگر را میسنجد. اگر برنامهٔ دیگری مهم است، از تشخیص مناسب آن استفاده کنید یا از پشتیبانی بخواهید. استثناها، پراکسی سیستم و رفتار اختصاصی برنامه میتوانند دامنهٔ پوشش را تغییر دهند. راهنمای وضعیت VPN توضیح میدهد چرا نشانگر اتصال فقط شروع بررسی است، نه اثبات همهٔ اتصالهای بعدی.
اگر جایی که مسیر محافظتشده انتظار داشتید ظاهراً آدرس ارائهدهندهٔ عادی دیده میشود، تا بررسی سیاست از آن تنظیم برای کار حساس استفاده نکنید. مشاهده را خصوصی حفظ و دقیق توصیف کنید. کنار آزمون آدرس، پیکربندی کامل یا کلید منتشر نکنید. پشتیبانی معمولاً پیش از هر اطلاعات دسترسی محرمانه، کلاینت و رفتار مورد انتظار را لازم دارد.
آدرسها را دقیقتر از برچسب کشور تفسیر کنید
جستوجوی آدرس ممکن است سازمان یا کشوری به آدرس مشاهدهشده نسبت دهد. این برچسبها زمینهٔ مفید هستند، نه اندازهگیری قطعی محل فیزیکی. پایگاهها ممکن است اختلاف داشته باشند و IPv4 و IPv6 مرتبط با یک سرویس متفاوت طبقهبندی شوند.
برای تأیید مسیر، آدرسهای دیدهشده را با انتظار ارائهدهنده از همان پیکربندی مقایسه کنید. رفتار مکانی را پرسش جدا بدانید. مقالهٔ کشور VPN و زبان وبسایت توضیح میدهد چرا ترجیح زبانی سایت بهتنهایی موضوع را حل نمیکند. رابط روسی یا صفحهٔ جستوجوی انگلیسی جای بررسی خانوادهٔ آدرس را نمیگیرد.
ثبت سادهای با چهار مورد داشته باشید: IPv4 عادی، IPv6 عادی، IPv4 در تونل و IPv6 در تونل. موارد ناموجود یا آزمایشنشده را صریح علامت بزنید و سیاست مورد نظر را زیرشان بنویسید. این قالب کمک میکند خانوادهٔ پشتیبانینشده، مسیر مستقیم ناخواسته و اختلاف برچسب جغرافیایی را از هم جدا کنید، نه اینکه همه را «VPN خراب است» بنامید.
مسیر را با حدس زدن فیلدهای پیکربندی اصلاح نکنید
فقط چون نمونهای در انجمن شامل مسیر گسترده است، آن را اضافه یا حذف نکنید. برای مثال، مستندات VPN اندروید مسیرهای جدا برای تمام مقصدهای IPv4 و IPv6 را شرح میدهد. این تنظیمها تعیین میکنند چه مقصدهایی وارد رابط مجازی شوند؛ خط تزئینی نیستند که بدون فهم بقیهٔ تنظیم کپی شوند.
همین احتیاط برای فایل واردشدهٔ دستی لازم است. تغییر مسیر میتواند دسترسی DNS، سرویسهای محلی و اتصال دوباره را تحت تأثیر قرار دهد. فایل اصلی سالم را امن نگه دارید و از پیکربندی پشتیبانیشدهٔ ارائهدهنده برای کلاینت استفاده کنید. هیچوقت برای پرسیدن درستی یک خط، پیکربندی را منتشر نکنید.
اگر راهحل پشتیبانیشده عمداً خانوادهٔ ناموجود را مسدود میکند، رفتار را از کنترلهای مستند کلاینت تأیید کنید. خاموش کردن کلی IPv6 در سیستمعامل یا روتر ممکن است برنامههای نامرتبط و کاربران دیگر را متأثر کند. چنین تغییر را فقط با دلیل روشن و اختیار مناسب انجام دهید، نه درمان عمومی برای نتیجهٔ نامفهوم یک سایت.
با تغییر شبکهٔ دسترسی دوباره بررسی کنید
نتیجهٔ وایفای دیروز رفتار یکسان در شبکهٔ موبایل امروز را تضمین نمیکند. بعد از بهروزرسانی بزرگ کلاینت، جایگزینی پیکربندی یا تغییر روش دسترسی مهم، مشاهدهٔ کوتاه را تکرار کنید. برای تنظیم بدون تغییر، آزمون بیپایان لازم نیست؛ روی جابهجاییهایی تمرکز کنید که مسیرهای موجود را عوض میکنند.
در مورد حلنشده، نسخهٔ کلاینت، نوع شبکه، سیاست مورد انتظار و نتیجهٔ جداگانهٔ دو خانواده را به راهنمای Lumeraya بفرستید. بگویید آیا مبنای بدون VPN ممکن بوده است. گزارش نباید کلید خصوصی داشته باشد و اگر فقط یک برنامه آزمایش شده، ادعای خرابی عمومی نکنید.
بررسی روشن دوپشته با نتیجهٔ محدود پایان مییابد: مسیر مشاهدهشدهٔ IPv4 طبق انتظار بود، IPv6 نیز چنین بود یا عمداً در دسترس نبود، و ابهام باقیمانده مشخص است. این از یک آدرس اطمینانبخش مفیدتر است، چون نتیجه را به تنظیم واقعی و ترافیکی که میخواهید محافظت کنید وصل میکند.