dnsmasq نمی‌تواند پورت 53 را bind کند: سوکتی را که آن را در اختیار دارد پیدا کنید

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

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

گام 1: خطا را بازتولید و خواندن آن

dnsmasq را با همان پیکربندی‌ای که سرویس استفاده می‌کند در پیش‌زمینه اجرا کنید تا خطا در ترمینال شما ظاهر شود، نه در گزارشی که باید حدس بزنید. به خانواده نشانی و نشانی محلی در پیام توجه کنید. bind به یک نشانی مشخص و bind به wildcard دو خطای متفاوت با دو مالک متفاوت هستند.

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

گام 2: مالکان را فهرست کنید

نخست سوکت‌ها را فهرست کنید. صافی روی پورت مبدأ 53 هر دو پروتکل انتقال و فرایند مالک را نشان می‌دهد، وقتی اختیار دیدنش را دارید:

ss -lntup 'sport = :53'

خروجی را ستون‌به‌ستون بخوانید: پروتکل انتقال، نشانی محلی، پورت، فرایند. شنونده TCP و شنونده UDP دو سوکت جدا هستند، پس متوقف کردن یکی دیگری را آزاد نمی‌کند. نشانی wildcard همه رابط‌ها را می‌پوشاند، یعنی نشانی VPN از قبل اشغال شده است، حتی اگر هیچ خطی آن را به نام ذکر نکند. و نام فرایند به شما می‌گوید این یک resolver مدیریت‌شده توسط توزیع است، یک کانتینر، یا چیزی که آزمایشی پیشین در حال اجرا رها کرده است.

گام 3: تله wildcard

گزینه bind-interfaces تعیین می‌کند dnsmasq یک سوکت wildcard bind کند یا برای هر رابط پیکربندی‌شده یک سوکت، همان‌طور که مرجع dnsmasq توصیف می‌کند. بدون آن، dnsmasq می‌تواند wildcard را bind کند و در عوض درخواست‌ها را بر اساس رابط صافی کند، که به‌محض در اختیار داشتن wildcard توسط سرویس‌دهنده‌ای دیگر بی‌درنگ شکست می‌خورد. Linux گزینه bind-dynamic را می‌افزاید که رابط‌های ساخته‌شده پس از آغاز را مدیریت می‌کند، نگرانی واقعی وقتی رابط VPN تنها هنگام اتصال پدیدار می‌شود.

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

گام 4: کار را تخصیص دهید

تصمیم بگیرید کدام سرویس‌دهنده به کارخواهان VPN پاسخ می‌دهد و کدام به میزبان. یک resolver که روی نشانی تونل گوش می‌دهد و به بالادست ارسال می‌کند چیدمانی رایج است؛ دو resolver که هرکدام گمان می‌کند مالک پورت 53 است اصلاً چیدمان نیست.

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

گام 5: سوکت را بررسی کنید، سپس مسیر را

پس از راه‌اندازی مجدد، پیش از آزمودن کارخواه تأیید کنید که سوکت‌های موردنظر وجود دارند. سرویس‌دهنده‌ای که هرگز bind نشده را نمی‌توان با مسیر نجات داد، و شکست کارخواه در برابر سوکتی که درست bind شده، مسئله‌ای دیگر با راه‌حلی دیگر است. سپس دسترسی‌پذیری را از کارخواهی روی تونل بررسی کنید. تنها پس از آن ارزش دارد بپرسید آیا نام‌های لازم تجزیه می‌شوند.

سه نتیجه جدا که باید از هم جدا بمانند: سوکت وجود دارد، کارخواه به آن می‌رسد، پاسخ درست است.

چه کاری نباید کرد

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

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