دست‌دادن WireGuard کار می‌کند، سرویس نه

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

در اولین موردی که برقرار نیست بایستید و برای بقیه قاعده اضافه نکنید.

دست‌دادن فقط تونل را اثبات می‌کند

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

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

شنونده و مسیر را بخوانید

روی کلاینت تأیید کنید که آدرس تونل سرور به داخل تونل مسیریابی می‌شود. روی سرور تأیید کنید که سوکتی روی آدرسی که کلاینت استفاده می‌کند وجود دارد و فرایند پشت آن همانی است که در نظر داشتید.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

قواعد را برای ورودی محلی اعمال کنید، نه برای ارسال به جلو

اگر بسته برسد و سوکت وجود داشته باشد، مرز باقی‌مانده سیاست ورودی است. قاعده‌ای که ارسال به جلو را مجاز می‌کند تحویل محلی را مجاز نمی‌کند، و قاعده‌ای که به یک رابط محدود است شاید با نام رابط تونلی که انتظار دارید سازگار نباشد.

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

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

شکست‌های نام، اندازه و هویت را از هم جدا کنید

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

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

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