رفع DNS مهمان libvirt که توسط فایروال VPN مبتنی بر نشانه مسدود می‌شود

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

مهمان‌ها در لحظه بالا آمدن تونل DNS را از دست می‌دهند

پیش از تغییر هر چیزی، شکل را تأیید کنید. تونل را پایین بیاورید، dig @192.168.122.1 example.com را از یک مهمان اجرا کنید و ببینید پاسخ می‌دهد. تونل را بالا بیاورید، تکرار کنید و ببینید زمانش تمام می‌شود. این جفت نتیجه در یک گام شبکه libvirt خراب، نشانی حل‌کننده اشتباه و dnsmasq مرده را رد می‌کند.

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

چرا قاعده accept در زنجیره‌ای بعدی هرگز فعال نمی‌شود

فایروال VPN مبتنی بر نشانه با نگاه به نشانه بسته یا نشانه اتصال تصمیم می‌گیرد، نه با نگاه به نشانی مبدأ شما. هر چیزی که بدون نشانه مورد انتظار به رابط فیزیکی برسد رد می‌شود، و این رد در مجموعه قواعدی رخ می‌دهد که آزمون نشانه را در اختیار دارد. خط ip saddr 192.168.122.0/24 accept که به زنجیره‌ای بعدی افزوده شود، برای آن بسته هرگز بررسی نمی‌شود، به همین دلیل قاعده بدیهی درست به نظر می‌رسد و هیچ چیز را تغییر نمی‌دهد.

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

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

پرس‌وجو را پیش از آنکه جدول VPN آن را ببیند نشانه بزنید

استثنا را در جدول خودش بگذارید تا خواننده بعدی بدون تجزیه قواعد VPN آن را بیابد:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle منفی است، که این زنجیره را پیش از زنجیره‌های فیلتر معمولی قرار می‌دهد که بسته VPN با اولویت صفر نصب می‌کند. ترتیب قلاب‌ها چیزی است که قاعده را اثرگذار می‌کند؛ همان قاعده در زنجیره‌ای که پس از زنجیره VPN مرتب می‌شود فقط تزئین است.

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

سوراخ را به عرض درگاه 53 نگه دارید

همان‌طور که نوشته شده، این DNS از زیرشبکه libvirt به میزبان روی TCP یا UDP درگاه 53 را مجاز می‌کند و هیچ چیز دیگر. مهمان‌ها را به اینترنت بیرون از تونل نمی‌رساند، و به میزبان اجازه نمی‌دهد اتصالاتی به سمت مهمان‌ها باز کند. اگر مهمانی بعداً به سرویس میزبان دیگری نیاز داشت، قاعده‌ای جداگانه که آن درگاه مقصد را نام می‌برد اضافه کنید، نه اینکه این یکی را شل کنید.

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

کاری کنید که از راه‌اندازی مجدد جان سالم به در ببرد و هر دو نیمه را اثبات کنید

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

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

اگر جستجوها پس از قرار گرفتن نشانه هنوز شکست می‌خورند، در برابر وسوسه گسترش مبدأ مقاومت کنید. بررسی کنید dnsmasq به کجا ارسال می‌کند، آیا حل‌کننده مهمان به 192.168.122.1 اشاره می‌کند یا به نشانی عمومی که کسی تایپ کرده، و آیا پرس‌وجو اصلاً به میزبان می‌رسد. نشانه‌گذاری بسته را می‌پذیرد و هیچ چیز دیگر، پس یک بالادست بد یا شبکه مجازی خراب هر قدر هم قاعده اضافه کنید خراب می‌ماند.