DNS اوپن‌وی‌پی‌ان روی دروازه: dnsmasq و گسترهٔ دیوار آتش

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

شنونده سرویسی محلی با دو جهت است

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

مهلتی که کلاینت گزارش می‌کند و مهلتی که روی دروازه دیده می‌شود یک عیب نیستند.

نشانی تونل را ببندید، نه همهٔ نشانی‌ها را

یک نمونهٔ اختصاصی dnsmasq برای این کار به نشانی شنود صریح، حالت بستنی که پیدایش تونل پس از آغاز را تحمل کند، و یک بالادست روشن نیاز دارد. این کوچک‌ترین نسخه‌ای است که به کار می‌برم:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic نشانی‌های جداگانه را می‌بندد و وقتی tun0 بعداً پیدا می‌شود کنار می‌آید، که روی میزابی که سرویس VPN دوباره راه‌اندازی می‌شود اهمیت دارد. فهرست‌کردن loopback ابزارهای محلی را بدون افزودن شنوندهٔ عمومی سرپا نگه می‌دارد. no-resolv جلوی ارث‌بری بالادست‌ها از پیکربندی حل‌کنندهٔ میزبان توسط دیمن را می‌گیرد، و no-hosts مانع انتشار پروندهٔ hosts دروازه توسط این نمونه می‌شود. هیچ‌یک از این گزینه‌ها به کسی اجازهٔ پرس‌وجو از سرویس را نمی‌دهد.

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

ورود DNS را مجاز کنید، نه عبور تونل را

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS هم روی TCP و هم روی UDP کار می‌کند، پس قاعده‌ای فقط برای UDP پاسخ‌های بزرگ را به شکلی شکست می‌دهد که متناوب به نظر می‌رسد. این‌ها ufw route مجوز نیستند و نباید به اجازهٔ گسترده روی tun0 تبدیل شوند. ترتیب به اندازهٔ محتوا مهم است: قاعدهٔ زودتری که همهٔ ورودی را از tun0 دور می‌ریزد هنوز برنده است، و افزودن اجازه زیر یک ریزش پایانی چیزی نمی‌سازد.

اگر DNS دروازه حالا بخشی از طراحی است، آن سیاست پیشین را عامدانه بازبینی کنید و دلیلش را ثبت کنید.

نیمهٔ بالادست مسیری جداگانه است

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

برای کارکردن پاسخ‌ها خروجی تونل بی‌محدود اضافه نکنید؛ پاسخ‌های ردیابی‌شده به آن نیاز ندارند.

گزینه را بپوشانید، سپس تحویل را بررسی کنید

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

push "dhcp-option DNS 10.90.0.1"

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

هدف یک مالک برای پیکربندی حل‌کنندهٔ کلاینت است، و پوشش معمولاً همان مالک است تنها وقتی پلتفرم کلاینت موافق باشد.

چیزی را که واقعاً ساخته‌اید بیازمایید

یک نام خصوصی کاملاً واجد شرایط و یک نام بیرونی مجاز را مستقیماً در برابر نشانی تونل، هم روی UDP و هم TCP، پرس‌وجو کنید. سپس از مسیر جست‌وجوی معمول برنامه تکرار کنید.

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

• کلاینت هرگز گزینهٔ پوشش‌ده را اعمال نکرد.
• حل‌کنندهٔ دیگری بعداً تعیین شد و مسابقه را برد.
• برنامه از کتابخانهٔ حل‌کنندهٔ خودش یا پاسخی ذخیره‌شده استفاده می‌کند.

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