پیشوند میزبان در WireGuard: چرا یک نشانی کار می‌کند و بقیه نه

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

پیشوند واسط در واقع چه چیزی می‌سازد

در Linux، اختصاص یک نشانی به واسط یک مسیر متصل برای آن پیشوند می‌سازد. اگر پیشوند میزبان اختصاص دهید، مسیر متصل یک نشانی را پوشش می‌دهد. اگر /24 اختصاص دهید، 256 نشانی را پوشش می‌دهد، و هر یک از آن‌ها اکنون از طریق آن پیوند قابل دسترسی شمرده می‌شود.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs دو قاعده زیر یک نام است

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

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

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

مسیر از کجا می‌آید

اگر از wg-quick استفاده می‌کنید، مسیرها برای شما از فهرست مجاز هر همتا ساخته می‌شوند، مگر اینکه Table = off را تنظیم کرده و کنترل را خودتان به دست گرفته باشید. این رفتار مستند ابزار است، و همان دلیلی است که پیکربندی بدون دستورهای صریح مسیر هم کار می‌کند.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

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

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

پیشوند گسترده‌تر ورودی همتا را اضافه نمی‌کند

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

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

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

پیش از تغییر هر چیزی هر دو جهت را تأیید کنید

دو انتها را جداگانه بررسی کنید و بنویسید هر کدام چه می‌گوید. روی کارخواه مسیر و ورودی همتا؛ روی سرور تصویر آینه‌ای به‌همراه مسیر بازگشت خودش:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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