فقط پورت 25 را به تونل بفرستید، نه میزبان را

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

قاعدهٔ پورت، مسیر پیش‌فرض نیست

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

دو تنظیم wg-quick پیش‌شرط‌اند، نه بخشی از سیاست. AllowedIPs = 0.0.0.0/0 به peer اجازه می‌دهد مقصدهای دلخواه IPv4 را حمل کند، و Table = off مانع می‌شود wg-quick مسیر پیش‌فرض خودش را برای آن پیشوند نصب کند. این دستورها را با مدیری که سیاست مسیریابی خودش را اعمال می‌کند قاطی نکنید، چون آن دو بر سر اینکه جدول اصلی از آنِ کیست توافق نخواهند داشت.

مسیر، انتخاب‌گر و نگهبان را بنویسید

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

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo قاعده را به ترافیک با مبدأ محلی محدود می‌کند، و ipproto tcp dport 25 جهت اتصال را مشخص می‌کند؛ مرجع ip-rule هر دو انتخاب‌گر را مستند می‌کند. آن‌ها در هسته‌ها و نسخه‌های کنونی iproute2 وجود دارند، و در سامانه‌ای قدیمی‌تر قاعده کلاً رد می‌شود، که شکستی روشن‌تر از قاعده‌ای است که بارگذاری می‌شود و با هیچ چیز تطبیق نمی‌یابد.

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

نشانی مبدأ باید سازگار باشد

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

در دروازه، peer مشتری باید مبدأیی را مجاز کند که واقعاً دریافت می‌کند، یعنی 10.77.0.2/32 نه یک پیشوند مقصد گسترده. کپی‌کردن 0.0.0.0/0 مشتری در هر peer دروازه، روشن نمی‌کند که کدام peer مالک کدام ترافیک است. دروازه همچنین به ارسال، سیاست دیوار آتش که جریان را مجاز می‌کند، و مسیر بازگشتی نیاز دارد، از جمله ترجمهٔ خروجی هنگامی که بالادست نمی‌تواند نشانی خصوصی تونل را مسیریابی کند.

مسیر بازگشت را بررسی کنید، سپس پایداری را

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

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

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

جایی که مسیریابی نامتقارن مجاز است، حالت سست محدود به واسط از طریق net.ipv4.conf.wg0.rp_filter=2 می‌تواند مناسب باشد، و ارزش دارد نخست بیشینهٔ مؤثر مقادیر all و واسط را بررسی کنید. اعتبارسنجی را به‌عنوان میان‌بر به‌صورت سراسری خاموش نکنید. سپس جدول، اولویت‌ها و نگهبان را به هر چیزی که مالک پیکربندی است بسپارید، و پس از اتصال دوباره اتصال‌های تازه باز کنید تا تأیید شود انتخاب هنوز برقرار است. به یاد داشته باشید که پاسخ‌های شنوندهٔ محلی SMTP پورت مبدأ 25 را حمل می‌کنند نه پورت مقصد 25، که پرسشی سیاستی جداگانه است.