peer وایرگارد دسترسی‌ناپذیر است در حالی که دیگری کار می‌کند: فهرست بررسی

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

گام 1: مسیری را که بسته باید طی کند بنویسید

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

مسیر مورد انتظار همچنین می‌گوید کجا را نگاه کنید. اگر بسته باید از هاب بگذرد، گام ناموفق یا AllowedIPs فرستنده است، یا ارسال هاب، یا AllowedIPs گیرنده. اگر باید مستقیم برود، هاب بی‌اهمیت است و فیلدهای نقطه پایانی روی هر دو peer اهمیت دارند.

گام 2: AllowedIPs را در هر دو طرف مقایسه کنید، نه فقط یک طرف

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

وضعیت زنده را بخوانید نه فایل را، زیرا بارگذاری مجدد ممکن است بی‌صدا شکست خورده باشد: sudo wg show wg0 allowed-ips. در سرور، مدخل peer ناموفق باید نشانی تونل آن را داشته باشد، برای نمونه 10.90.0.3/32. در کلاینت، مدخل peer سرور باید مقصدی را داشته باشد که آزمایش می‌کنید، چه نشانی تونل هاب باشد چه زیرشبکه دور. بازه‌های هم‌پوشان جست‌وجو را مبهم می‌کنند و ممکن است peer ای را انتخاب کنند که در نظر نداشتید، پس آن‌ها را جدا نگه دارید.

گام 3: نشانی مبدأ داخلی را بررسی کنید

کلاینتی که 10.90.0.3 را از wg0 مسیریابی می‌کند اما بسته‌ها را از نشانی Wi-Fi خود می‌فرستد، از سوی گیرنده رد می‌شود، زیرا مبدأ با AllowedIPs peer مطابقت ندارد. با ip route get 10.90.0.3 from 10.90.0.2 تأیید کنید که هسته واقعاً چه چیزی را انتخاب می‌کند، و با ip -brief addr show wg0 نشانی تخصیص‌یافته به رابط تونل را تأیید کنید.

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

گام 4: ارسال هاب و مسیر برگشت را مرور کنید

اگر هاب باید میان peerها ارسال کند، هسته به net.ipv4.ip_forward=1 نیاز دارد و دیوار آتش باید جریان ارسال‌شده را بپذیرد: ورود روی wg0، خروج روی wg0، از نشانی تونل فرستنده به نشانی گیرنده. خرابی رایج قاعده ورودی که UDP 51820 را می‌پذیرد اما قاعده ارسال ندارد] است، پس دست‌دادن موفق می‌شود و بار می‌میرد. قواعد مؤثر را با sudo nft list ruleset یا معادل آن برای مدیر دیوار آتش خود فهرست کنید.

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

در پایان، دست‌دادن را از داده جدا کنید. peer ای که دست‌دادن را کامل می‌کند اما در انتقال‌های بزرگ گیر می‌کند معمولاً مشکل MTU یا MSS در همان مسیر دارد، نه مشکل AllowedIPs. نخست با یک پینگ کوچک و سپس با پینگی در اندازه کامل آزمایش کنید و دو peer را مقایسه کنید.

گام 5: یک چیز را تغییر دهید و peer فعال را دست‌نخورده نگه دارید

یک تغییر واحد در مسیر ناموفق بدهید و هر دو peer را دوباره آزمایش کنید. جایگزینی AllowedIPs هر peer با 0.0.0.0/0 سریع‌ترین راه برای شکستن peer ای است که از قبل کار می‌کرد، زیرا تصمیم مسیریابی همه ترافیک آن رابط را تغییر می‌دهد. همان یک مدخل را ویرایش کنید، دوباره بارگذاری کنید و وضعیت زنده را بازخوانی کنید.

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