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

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

خط DNS ویژگی‌ای از کمک‌کننده است

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

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

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

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

اولین خطایی را بخوانید که کمک‌کننده چاپ می‌کند

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

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

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

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

میزبان در واقع کدام resolver را دارد

میزبان‌های مدرن Linux غالباً یک resolver stub محلی اجرا می‌کنند، بنابراین آدرسی که کمک‌کننده نصب می‌کند توسط همان stub مصرف می‌شود، نه مستقیماً توسط برنامه‌ها. ویرایش دستی یک فایل تولیدشده ممکن است تا اتصال مجدد بعدی کارآمد به نظر برسد، زمانی که کمک‌کننده آن را بازنویسی می‌کند.

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

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

پاک‌سازی به اندازه راه‌اندازی اهمیت دارد

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

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

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

مقالات مرتبط