मार्क-आधारित VPN फायरवालले रोकेको libvirt गेस्ट DNS ठीक गर्नुहोस्

पूर्वनिर्धारित 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 पंक्ति पछिको कुनै चेनमा थप्दा पनि त्यो प्याकेटका लागि कहिल्यै हेरिँदैन, त्यसैले स्पष्ट देखिने नियम सही देखिन्छ तर केही पनि बदल्दैन।

केही काम नगरेसम्म यसलाई फराकिलो बनाउनु दोस्रो पासो हो। होस्टको input मार्गमा सम्पूर्ण 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 मा छ कि कसैले टाइप गरेको सार्वजनिक ठेगानामा, र क्वेरी होस्टसम्म पुग्छ कि पुग्दैन जाँच्नुहोस्। मार्किङले प्याकेट भित्र छाड्छ र अरू केही होइन, त्यसैले बिग्रिएको अपस्ट्रिम वा बिग्रिएको भर्चुअल नेटवर्क जति नियम थपे पनि बिग्रिएकै रहन्छ।