کلاینت WireGuard به کلاینت OpenVPN نمی‌رسد؟

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

نشانه هر بار یک قطعه کم دارد

این طراحی از یک استخر WireGuard با 10.71.0.0/24 روی wg1 و یک استخر OpenVPN با 10.72.0.0/24 روی tun1 استفاده می‌کند که هر دو روی یک دروازه پایان می‌یابند. درخواست تحت آزمون از 10.71.0.5 به HTTPS روی 10.72.0.30 می‌رود. هر گام زیر دربارهٔ همان یک جریان است. هر بررسی امضای خطای متفاوتی دارد هرچند کاربر همه را یکسان تجربه می‌کند، و معمولاً هر بار فقط یکی از سه مورد کم است.

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

پوشش مقصد پره را گسترش دهید

روی کلاینت WireGuard، مدخل همتای موجود باید دروازه را برای مقصد OpenVPN انتخاب کند، یعنی پیشوند مقصد باید در فهرست مجاز آن همتا بیاید. افزودن آن تونل دومی نمی‌سازد؛ تغییر می‌دهد که کلاینت هنگام جست‌وجوی آن نشانی کدام همتا را انتخاب کند، و با wg-quick مسیر معمولاً به‌طور خودکار از فهرست پیروی می‌کند.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

مالکیت مبدأ را در دروازه نگه دارید

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

AllowedIPs = 10.71.0.5/32

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

به سمت OpenVPN مسیر بازگشت بدهید

مقصد اکنون به مسیری بازگشتی به مبدأ WireGuard نیاز دارد، و برای کلاینت‌های استخری این معمولاً به‌صورت مسیر هل‌داده‌شده از سرور OpenVPN می‌آید. آن را فقط به کلاینت‌هایی که باید داشته باشند هل بدهید، و در کلاینت تأیید کنید که پذیرفته شده است نه اینکه فرض کنید دستور اعمال شده.

push "route 10.71.0.0 255.255.255.0"

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

فقط همان یک سرویسی را مجاز کنید که قصد مجاز کردنش را داشتید

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

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