چگونه یک آزمون WireGuard با دو همتا بسازیم که یک مسیر را اثبات می‌کند

یک آزمون WireGuard که مسیر پیش‌فرض، پیشوند LAN، DNS و یک استثنای دیوار آتش را حمل می‌کند نمی‌تواند بگوید کدامشان خراب شده است. آن را به دو همتا، یک جفت نشانی و یک سرویس مجاز کاهش دهید، و خطا جایی برای پنهان شدن ندارد. پایهٔ خسته‌کننده همان تشخیص است. اول آن را بسازید؛ پانزده دقیقه وقت می‌گیرد و بعدازظهری را نجات می‌دهد که در غیر این صورت صرف حدس زدن می‌کردید.

آنچه پایه اثبات می‌کند باریک‌تر از آن است که بیشتر مردم انتظار دارند. اثبات می‌کند که دو هویت توافق دارند، که UDP به درگاه شنود می‌رسد و که یک مقصد مجاز یک درخواست را حمل می‌کند. هدایت، NAT، مسیرهای LAN و DNS ویژگی‌های جداگانه‌ای هستند که بعداً یکی‌یکی اضافه می‌شوند.

کلیدها، نشانی‌ها و تنها نقطهٔ پایانی

روی هر سامانه یک جفت کلید بسازید و فقط نیمه‌های عمومی را میان آنها جابه‌جا کنید. wg genkey | tee privatekey | wg pubkey > publickey همان فرمان یک‌خطی مستند است، و کلید خصوصی را در پرونده‌ای باقی می‌گذارد که بعداً می‌توانید از آن محافظت کنید. نشانی‌های تونل را از بازه‌ای انتخاب کنید که در هیچ پیکربندی دیگری که دارید ظاهر نمی‌شود، مانند 10.99.0.1/24 و 10.99.0.2/24. بنویسید کدام نشانی به کدام ماشین تعلق دارد، چون هر بررسی بعدی به همان نگاشت وابسته است.

کلیدهای خصوصی هرگز سفر نمی‌کنند. اگر آزمونی به کپی شدن یکی به سمت دیگر نیاز داشته باشد، آزمون از قبل اشتباه رفته است. وقتی دو سامانه پشت NAT هستند، دست‌کم یکی به درگاه UDP قابل دسترس نیاز دارد در حالی که دیگری Endpoint دارد که به آن اشاره می‌کند، و نشانی عمومی و درگاه جایشان در یادداشت‌های شماست نه در فرض‌های شما دربارهٔ 51820.

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

فیلدهایی که به wg تعلق دارند و آنهایی که ندارند

مجموعهٔ فیلدهای اصلی کوچک است: PrivateKey و ListenPort زیر Interface، و PublicKey و AllowedIPs و Endpoint زیر Peer. اما Address و DNS به wg-quick تعلق دارند نه به خود wg، و این تمایز همان لحظه‌ای گاز می‌گیرد که همان پیکربندی به ابزار دیگری منتقل شود.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs همزمان دو کار را انجام می‌دهد. انتخاب می‌کند کدام مقصدها به تونل بروند، و به همتا اجازه می‌دهد آن نشانی‌های مبدأ را هنگام رسیدن به کار ببرد. به همین دلیل ورودی آینه‌ای در سمت دیگر باید نشانی تونل شما را دقیق نام ببرد؛ یک /32 برای همتای اشتباه مانند یک مشکل مسیریابی خوانده می‌شود و مثل یک مشکل مجوز رفتار می‌کند. و شروع سریع WireGuard همان شکل دو همتا را با عبارت استاندارد نشان می‌دهد اگر بخواهید نام فیلدها را مقایسه کنید.

خواندن دست‌داد به‌جای نماد

رابط را از طریق هر چیزی که مالک آن است بالا بیاورید، سپس وضعیت را بخوانید نه چراغ وضعیت. wg show آخرین دست‌داد هر همتا را همراه با شمارنده‌های بایت چاپ می‌کند، و دست‌دادی در چند دقیقهٔ گذشته یعنی کلیدها، نقطهٔ پایانی و مسیر UDP همه کار می‌کنند. شمارنده‌ای که فقط در یک جهت بالا می‌رود خودش پاسخ است، و این همان خرابی دست‌دادی نیست که هرگز رخ نمی‌دهد.

دو خرابی به بررسی‌های متفاوتی اشاره دارند. نبود کامل دست‌داد به ناهماهنگی کلید، Endpoint اشتباه، UDP مسدود یا دیوار آتشی اشاره می‌کند که خود دست‌داد را می‌اندازد. دست‌دادی که موفق می‌شود اما داده‌ها به جایی نمی‌رسند به AllowedIPs، سرویسی که روی نشانی تونل شنود نمی‌کند، یا دیوار آتش میزبان اشاره می‌کند که درگاه را برای LAN می‌پذیرد اما برای رابط تونل نه. اینها دو نیمهٔ متفاوت سامانه‌اند، و پایه پیش از آنکه شروع به تغییر قواعد کنید آنها را جدا می‌کند.

اثبات یک سرویس مجاز، سپس جهت عکس

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

جهت عکس را به‌عنوان آزمونی جدا با نتیجهٔ خودش اجرا کنید، چون دو جهت ورودی‌های جداگانهٔ دیوار آتش و AllowedIPs دارند و می‌توانند مستقل شکست بخورند. اگر دست‌داد کار می‌کند و درخواست نه، مشکل در مسیر داده است نه در تونل: AllowedIPs، سرویس شنودکننده، یا دیوار آتش میزبان. پیش از افزودن هدایت، NAT یا DNS آن را درست کنید، وگرنه بعدازظهر را صرف اشکال‌زدایی ویژگی‌ای می‌کنید که هرگز مقصر نبود.

نگه‌داشتن پایه به‌عنوان مرجع

توپولوژی کارآمد و منبع پروفایل را جایی ذخیره کنید که بتوانید از آن بازیابی کنید، و آنها را بیرون از هر پوشه‌ای نگه دارید که با سرویس عمومی همگام می‌شود. سپس هر بار یک ویژگی اضافه کنید و پس از هرکدام درخواست اصلی را تکرار کنید: هدایت، NAT، یک مسیر LAN و تنها بعد از آن DNS. هر افزوده‌ای که آزمون را می‌شکند اکنون قابل شناسایی است، چون چیز دیگری حرکت نکرده.

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