मार्क-आधारित 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 कडे आहे की कोणी टाइप केलेल्या सार्वजनिक पत्त्याकडे, आणि क्वेरी होस्टपर्यंत पोहोचतेच का, हे तपासा। मार्किंग पॅकेटला आत सोडते आणि दुसरे काही नाही, त्यामुळे खराब अपस्ट्रीम किंवा तुटलेले व्हर्च्युअल नेटवर्क कितीही नियम जोडले तरी तुटलेलेच राहते।