اجرای VPN روی هاست یا داخل ماشین مجازی؟ راهنمای تصمیم

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

پیش از دست زدن به کلاینت، مالک را تعیین کنید

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

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

پاسخ را در یک خط کنار نام ماشین مجازی بنویسید: guest-owned یا host-owned. در آزمایشگاهی با شش ماشین، آن یادداشت بیش از هر گام زیر وقت صرفه‌جویی می‌کند، چون جلوی شما را از عیب‌یابی تونلی می‌گیرد که هرگز در ماشینی که وارد آن شده‌اید نبوده است.

WSL1 و WSL2 دو حالت متضادند

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

WSL2 برعکس است. هستهٔ واقعی را در یک ماشین مجازی کمکی سبک پشت یک سوئیچ مجازی Hyper-V اجرا می‌کند و فضای نشانی‌اش از راه یک مبدل در سمت هاست NAT می‌شود. بنابراین کلاینت لینوکسی داخل توزیع مانند یک ماشین فیزیکی لینوکس رفتار می‌کند: tun0 یا wg0 می‌سازد، مسیرهای خودش را نصب می‌کند و کار می‌کند. شکست در سمت هاست زندگی می‌کند. وقتی کلاینت VPN ویندوز با سیاستی وصل می‌شود که ترافیک شبکه‌های محلی را مسدود می‌کند، زیرشبکهٔ WSL2 را شبکهٔ محلی نامطمئن می‌پندارد و مسیر NAT را قطع می‌کند. آن‌گاه توزیع DNS و دسترسی خروجی را از دست می‌دهد در حالی که تونل خودش هنوز سالم است: wg show از دست‌دادن خبر می‌دهد، ip route درست به نظر می‌رسد، و curl معلق می‌ماند.

کدام راه‌حل را می‌توانید به کار ببرید به بیلد ویندوز بستگی دارد. قدیمی‌تر یک استثنا در کلاینت هاست برای زیرشبکهٔ WSL است که زیر تنظیمات شبکهٔ محلی یا تونل تقسیم‌شدهٔ کلاینت افزوده می‌شود. جدیدتر، روی بیلدهای ویندوز 11 که پشتیبانی می‌کنند، شبکهٔ آینه‌ای است: networkingMode=mirrored را در بخش [wsl2] فایل %UserProfile%\.wslconfig بگذارید، wsl --shutdown را اجرا کنید، و توزیع رابط‌های هاست را به جای یک زیرشبکهٔ NAT خصوصی شریک می‌شود. حالت آینه‌ای رفتار localhost و درگاه‌های ورودی را هم تغییر می‌دهد، پس آن را مهاجرت بدانید نه کلید تغییر.

NAT، پل، و آنچه هاست می‌تواند ببیند

زیر NAT، بسته‌های تونل مهمان به نشانی عمومی سرور VPN نشانه‌گذاری می‌شوند و از مبدل هاست به‌صورت UDP یا TCP رمزگذاری‌شده بیرون می‌روند. هاست یک جریان و شمار بایت‌هایش را می‌بیند، و هیچ چیز دربارهٔ مقصدهای درون آن. زیر مبدل پلی مهمان هویت لایهٔ 2 خودش را روی LAN فیزیکی دارد، اجارهٔ DHCP خودش را می‌گیرد، و برای هر سیاست مبتنی بر MAC مانند دستگاه دومی به نظر می‌رسد. هیچ‌کدام از دو حالت به هاست اجازهٔ خواندن محتوای تونل را نمی‌دهد؛ مهمان پلی‌شده صرفاً برای شبکهٔ اطرافش بسیار نمایان‌تر است.

انزوا هم کف دارد. مهمان نمی‌تواند از ماشینی که مالک حافظه‌اش است پنهان شود، و هر که هاست را کنترل کند می‌تواند کلیدها را از RAM مهمان بخواند. آنچه تونل مهمان به شما می‌دهد یک مرز مسیریابی و یک مرز بدافزار است، نه محافظت در برابر کسی که لپ‌تاپ را در دست دارد. بهتر است حالت‌های مستند مبدل را هنگام انتخاب باز نگه دارید، چون حالت هم آنچه هاست می‌بیند و هم آنچه LAN می‌بیند را تغییر می‌دهد.

راهنما: جای‌گذاری، تنظیم، اثبات

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

1. ip route get 1.1.1.1 که tun0 یا wg0 برگرداند یعنی مالکیت مهمان، و eth0 با پرش بعدی خصوصی یعنی مالکیت هاست.
2. resolvectl query example.com، یا آنجا که مهمان هیچ سرویس حل‌کننده‌ای اجرا نمی‌کند /etc/resolv.conf را بخوانید. تونلی که ترافیک را حمل می‌کند ولی DNS را نه، رایج‌ترین حالت نیمه‌تنظیم است.
3. خروجی‌ها را مقایسه کنید: curl -4 -s https://ifconfig.me در مهمان در برابر curl.exe -4 -s https://ifconfig.me روی هاست. نشانی‌های متفاوت یعنی مهمان مالک تونل است، و هاستی روی VPN با مهمانی که ارائه‌دهندهٔ خانه را نشان می‌دهد همان حالت «هیچ چیز به ارث نرسید» است.
4. هر دو را با -6 تکرار کنید. تونل فقط v4 نشتی v6 دارد مگر آنکه کلاینت آن را مسدود یا مسیریابی کند، و بسیاری از کلاینت‌ها v6 را به‌طور پیش‌فرض روی رابط فیزیکی رها می‌کنند.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

در سمت WireGuard، AllowedIPs همتای هاست باید زیرشبکهٔ مهمان‌ها را شامل شود، مثلاً 192.168.122.0/24، وگرنه بسته‌های بازگشت هرگز نمی‌رسند و تنظیم مانند یک مشکل دیوار آتش به نظر می‌رسد. هاست ویندوز با اشتراک اتصال اینترنت یا قاعدهٔ NAT روی سوئیچ Hyper-V به همان نتیجه می‌رسد و همان بررسی مسیر بازگشت را لازم دارد.

وقتی چیدمان هنوز باز است، این جدول رایج‌ترین ترتیب‌ها را پوشش می‌دهد:

دو تونل، دو مهمان، و ناسازگاری‌های میان آن‌ها

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

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

تأیید کنید، سپس بازیابی را نزد مالک نگه دارید

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

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