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

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

در این نمونه، کلاینت‌های پایین‌دست از 10.90.0.0/24 استفاده می‌کنند، آدرس تونل بالادستی اختصاص‌یافته به دروازه 10.80.0.6 است و منبع دور تأییدشده 172.20.0.30 است. دو مدل با این شکل سازگار است: حفظ مبدأ پایین‌دست و واداشتن طرف دور به مسیریابی آن، یا ترجمهٔ مبدأ به آدرس تونل خود دروازه. هرچه پس از این تصمیم می‌آید مکانیکی است و خود تصمیم به مالک سرویس نیاز دارد. یکی از دو سطر بالا توافق مسیریابی با طرف دور است؛ دیگری تغییری محلی در سیاست که خودتان می‌توانید انجام دهید. اشتباه گرفتن این دو همان چیزی است که تغییری ده‌دقیقه‌ای را به مذاکره تبدیل می‌کند.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

یک سطر را انتخاب کنید و به آن پایبند بمانید. سطرها جایگزین یکدیگرند، نه گام‌های پیاپی، و آمیختن آن‌ها طرحی می‌سازد که هیچ‌کس در بازبینی نمی‌تواند توضیح دهد.

حفظ مبدأ با مسیریابی

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

اگر پاسخ بله بود، پیکربندی محلی کوچک است: ارسال فعال، allowed-ips های peer در WireGuard که محدودهٔ پایین‌دست را پوشش می‌دهند، و سیاست فایروالی که عبور را در هر دو جهت اجازه می‌دهد.

ترجمهٔ عامدانهٔ مبدأ

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

IPv6 طرح خودش را می‌خواهد؛ کپی کردن یک خط masquerade برای IPv4 معماری نیست. مسیر ترجمه‌شده را با اتصالی تازه بیازمایید، نه اتصالی ذخیره‌شده در کش.

مسیر دادهٔ محلی هنوز باید کار کند

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

از یک دستگاه پایین‌دست واقعی بیازمایید، نه از دروازه. آدرس مبدأ تمام منظور این تمرین است.

یک مبدأ یعنی یک هویت نشست

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

آن تأیید را در runbook کنار قاعده بنویسید، چون بازبین بعدی خواهد پرسید آیا طرح تأیید شده بود یا فقط راحت بود.

وضعیت قطع ارتباط را تعریف کنید، سپس سه درخواست را بیازمایید

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

بازگردانی را برای هر قاعده در یک سطر ثبت کنید تا تغییر بدون بازسازی قصد قابل لغو باشد.

مقالات مرتبط