libvirt अतिथि का DNS ठीक करें जो मार्क-आधारित 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 की चौड़ाई में रखें

जैसा लिखा है, यह libvirt सबनेट से मेज़बान तक TCP या UDP पोर्ट 53 पर DNS की अनुमति देता है और कुछ नहीं। यह अतिथियों को टनल के बाहर इंटरनेट तक पहुँचने नहीं देता, और यह मेज़बान को अतिथियों की ओर कनेक्शन खोलने नहीं देता। यदि अतिथि को बाद में कोई अन्य मेज़बान सेवा चाहिए, तो इस नियम को ढीला करने के बजाय उस गंतव्य पोर्ट का नाम लेने वाला अलग नियम जोड़ें।

आप क्या बदल रहे हैं इसके बारे में ईमानदार रहें। जो अतिथि रिज़ॉल्वर तक पहुँच सकता है वह DNS क्वेरी के माध्यम से मनमाना डेटा भी टनल कर सकता है, और यह अपवाद VPN सीमा में जानबूझकर किया गया अंतराल है, स्थानीय नेटवर्क के भरोसेमंद होने का कथन नहीं। स्रोत को 192.168.122.0/24 तक सीमित रखना अंतराल को हर अन्य स्थानीय सबनेट से दूर रखता है, और यदि ख़तरा आपके लिए मायने रखता है तो उस स्रोत के विरुद्ध क्वेरी गिनना सस्ता है।

इसे रीबूट में टिकने दें और दोनों आधों को सिद्ध करें

शेल प्रॉम्प्ट पर टाइप किया गया नियम अगले बूट पर गायब हो जाता है, और VPN इंटरफ़ेस के पहले से ट्रैफ़िक पास करने के बाद लोड होने वाला नियम पहले कनेक्शन पर दौड़ हार जाता है। तालिका को मेज़बान के स्थायी nftables कॉन्फ़िगरेशन में रखें, या VPN सेवा से पहले क्रमित यूनिट में, और क्रम को मानने के बजाय जाँचें।

सत्यापन के लिए तीन अलग उत्तर चाहिए। पुष्टि करें कि श्रृंखला लोड है और पहले क्रमित है, पुष्टि करें कि conntrack प्रविष्टि दोनों दिशाओं में मार्क दिखाती है, और पुष्टि करें कि अतिथि का लुकअप पता लौटाता है। फिर दूसरे आधे की पुष्टि करें: सार्वजनिक मेज़बान के लिए अतिथि का सामान्य वेब ट्रैफ़िक टनल नीचे या अवरुद्ध होने पर अभी भी विफल होता है। यदि DNS काम करता है और बाकी सब लीक होता है, तो आपका नियम ऊपर वाले से चौड़ा है।

यदि मार्क लगाने के बाद भी लुकअप विफल होते हैं, तो स्रोत को चौड़ा करने की इच्छा का विरोध करें। जाँचें कि dnsmasq कहाँ फ़ॉरवर्ड करता है, अतिथि का रिज़ॉल्वर 192.168.122.1 की ओर इशारा करता है या किसी के द्वारा टाइप किए गए सार्वजनिक पते की ओर, और क्या क्वेरी मेज़बान तक पहुँचती ही है। मार्किंग पैकेट को स्वीकार करती है और कुछ नहीं, इसलिए ख़राब अपस्ट्रीम या टूटा वर्चुअल नेटवर्क चाहे जितने नियम जोड़ें टूटा ही रहता है।