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

بلندترین پیشوند درون WireGuard برنده می‌شود

هر ورودی peer مجموعه‌ای از پیشوندهای مقصد را حمل می‌کند. هنگامی که بسته‌ای به رابط مسیریابی می‌شود، پیاده‌سازی ورودی‌ای را با دقیق‌ترین پیشوند منطبق جست‌وجو می‌کند — همان قاعده‌ای که جدول مسیریابی اعمال می‌کند. بنابراین /24 بر /16 که آن را در بر می‌گیرد پیروز می‌شود، و peer باریک‌تر ترافیک را دریافت می‌کند.

پیکربندی‌های road-warrior این را عمداً به کار می‌گیرند. یک peer محدوده‌ای گسترده برای یک سایت دارد، و میزبان‌های فردی با ورودی‌های /32 که به peerهای دیگر تعلق دارند جدا می‌شوند. این الگو کار می‌کند چون جداها دقیق‌ترند، نه به خاطر ترتیب.

مالکیت را به صورت جدولی از پیشوند و peer بنویسید. اگر دو ورودی یک پیشوند را توصیف کنند، پیکربندی دیگر بیانگر یک نیت نیست، بیانگر یک مسابقه است.

سیستم‌عامل نخست رابط را انتخاب می‌کند

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

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

بسته‌های ورودی بر اساس مبدأ بررسی می‌شوند

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

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

مالکیت باریک مبدأ این را به یک مزیت تبدیل می‌کند. به هر peer یک /32 برای نشانی خودش بدهید و فایروال پایین‌دست منبع قابل‌اعتمادی برای تطبیق خواهد داشت، به جای محدوده‌ای در سطح گروه که هر عضوی می‌تواند آن را ادعا کند.

محدوده‌های تکراری failover نیستند

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

گسترش یک محدوده برای رفع یک شکست نامرتبط اشتباه رایج دیگر است. ترافیک را از peerی که کار می‌کرد دور می‌کند، و نشانه جدید پیش از آنکه قدیمی درک شود می‌رسد.

پیش از ویرایش، انتخاب را تأیید کنید

سه فرمان به سه پرسش به ترتیب پاسخ می‌دهند. اولی محدوده‌هایی را که هر peer ادعا می‌کند فهرست می‌کند. دومی نشان می‌دهد میزبان برای یک مقصد از کدام رابط استفاده می‌کند. سومی وضعیت زنده peerها را پس از جریان یافتن ترافیک نشان می‌دهد.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

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

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

مقالات مرتبط