دو لپ‌تاپ روی یک روتر خانگی می‌توانند از خروجی‌های متفاوت VPN به اینترنت برسند و Wi-Fi مشترک هیچ نقشی در این میان ندارد. آنچه نتیجه را تعیین می‌کند این است که تونل کجا اجرا می‌شود و کدام سیاست مسیر هر درخواست را انتخاب می‌کند. باور مخالف هم به همان اندازه رایج و به همان اندازه نادرست است: دو دستگاه با پروفایل‌های جدا به‌طور خودکار دو نشانی عمومی تولید نمی‌کنند. هر دو اشتباه از آنجا می‌آید که با یک نشانی طوری رفتار شود که گویی سه نشانی است.

سه نشانی، و تنها یکی از آن‌ها بیرون می‌رود

لپ‌تاپ نشانی LAN خانگی دارد که آن را در بخش محلی شناسایی می‌کند و ممکن است نشانی تونلی هم داشته باشد که درون VPN به آن داده شده است. هیچ‌یک از این دو برای یک سرویس دوردست دیده نمی‌شود. آنچه آن سرویس ثبت می‌کند، نشانی خروجی عمومی دستگاهی است که در نهایت بسته را می‌فرستد، پس از هر ترجمه‌ای در مسیر.

RFC 3022 همان تمایزی را می‌کشد که بیشتر سردرگمی اینجا را توضیح می‌دهد. NAT سنتی نشانی‌های داخلی را به نشانی‌های عمومی نگاشت می‌کند، در حالی که ترجمه درگاه به نشانی‌های داخلی بسیاری اجازه می‌دهد همزمان یک نشانی عمومی را به اشتراک بگذارند. خانواده‌ای با یک نشانی عمومی و چند دستگاه حالت دوم است و این تقریباً همه‌جا پیش‌فرض است.

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

چه چیزی دو خروجی را واقعاً متفاوت می‌کند

یک خروجی زمانی متفاوت است که آخرین دستگاه پیش از اینترنت برای آن ترافیک نشانی عمومی دیگری به کار ببرد. این می‌تواند رخ دهد چون VPN در جای دیگری پایان می‌یابد، چون استخر خروجی نشانی دیگری تخصیص می‌دهد، یا چون ارائه‌دهنده درخواست را از خروجی دیگری مسیریابی می‌کند. هر سه تصمیم‌های سیاستی در سر دوردست‌اند و هیچ‌یک از روتر خانه دیده نمی‌شوند.

دو دستگاهی که هر یک کارخواه خود را با پروفایل یکسان اجرا می‌کنند معمولاً در یک استخر می‌افتند و برای یک نشست معین شاید همان خروجی را بگیرند. این یک اشکال نیست، رفتار طبیعی یک استخر مشترک است. گرفتن خروجی‌های جدا معمولاً یعنی از سرویس تخصیص‌های جدا بخواهیم، نه اینکه کارخواه را دو بار پیکربندی کنیم.

پیش از طراحی بر پایهٔ یک تضمین، شرایط سرویس دربارهٔ اتصال‌های همزمان را بخوانید. ورود دوم اجازهٔ اتصال است، نه وعدهٔ نشانی انحصاری. اگر شرایط چیزی نمی‌گوید، از ارائه‌دهنده بپرسید نه اینکه فرض کنید. پاسخ بیش از هر تنظیم کارخواه طراحی را تغییر می‌دهد.

چرا پروفایل‌های جدا، خروجی‌های جدا نیستند

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

عکس آن هم صادق است. یک کارساز VPN می‌تواند بیش از یک خروجی عمومی ارائه دهد وقتی مسیریابی و سیاست ترجمه‌اش این‌گونه ساخته شده باشد، در حالی که کارسازهای جدا ممکن است یک خروجی پایین‌دستی را تغذیه کنند. پس شمار نام کارسازها در پیکربندی شما چیزی دربارهٔ شمار نشانی‌ها نمی‌گوید. به همین دلیل پیکربندی جای اشتباهی برای یافتن این پاسخ است.

تنها پاسخ قابل اعتماد از درخواستی می‌آید که از همان چیدمانی که می‌خواهید استفاده کنید انجام شود. هر چیز دیگری استنتاج است.

جداسازی را کجا بگذاریم

تونل روتر تمام خانه را پوشش می‌دهد، که راحت است و دقیقاً یک خروجی مشترک برای هر دستگاه پشت آن می‌سازد. کارخواه روی هر دستگاه کنترل هر دستگاه را به شما می‌دهد اما می‌خواهد هر دستگاه آماده شود و آماده بماند. روتری که قابلیت سیاست دارد در میان می‌نشیند و برای هر دستگاه مسیری انتخاب می‌کند، و تنها وقتی کار می‌کند که بتواند دستگاه‌ها را در بازاتصال‌ها و تغییرهای DHCP به‌طور قابل اعتماد بشناسد.

ساختن یک اجارهٔ DHCP خصوصی دیگر روی روتر همانند ساختن یک نشانی عمومی دیگر نیست. نمای محلی را عوض می‌کند و خروجی را دست‌نخورده می‌گذارد. جداسازی در سیاست خروجی زندگی می‌کند، چه آن سیاست روی روتر باشد چه در سرویس VPN.

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

خروجی‌ای را که واقعاً گرفتید بررسی کنید

بررسی را از برنامه‌ای انجام دهید که مهم است و همان خانوادهٔ نشانی را روی هر دو دستگاه مقایسه کنید. نتیجهٔ IPv4 از یکی و نتیجهٔ IPv6 از دیگری چیزی دربارهٔ هیچ‌کدام ثابت نمی‌کند. سپس بررسی را پس از بازاتصال تکرار کنید، چون تخصیص استخر می‌تواند میان نشست‌ها تغییر کند.

آن را از پایانهٔ درون سیاست تونل اجرا کنید، نه از دستگاهی که آن را دور می‌زند. میزبان اشتباه پاسخ اشتباه مطمئنی می‌دهد.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

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

مقالات مرتبط