StrongSwan एक DNS पता भेजता है जहाँ Mac नहीं पहुँच सकता

सब कुछ तब तक काम करता है जब तक कोई MacBook नहीं खोलता। टनल बन जाता है, आंतरिक होस्ट पते से जवाब देते हैं, और नाम रिज़ॉल्यूशन मर जाता है। iPhone पर वही प्रोफ़ाइल वैसे ही व्यवहार करती है, जबकि Windows और Linux क्लाइंट ठीक हैं। आमतौर पर भेजा गया DNS एट्रिब्यूट ही दोषी होता है: सर्वर अपना सार्वजनिक इंटरफ़ेस पता बाँटता है, और Apple का IKEv2 क्लाइंट टनल से होकर वहाँ क्वेरी नहीं भेजता। रिज़ॉल्वर को पूल के अंदर ले जाएँ और लक्षण क्लाइंट को छुए बिना गायब हो जाता है।

लक्षण भेजे गए पते की ओर इशारा करता है

जब केवल कुछ प्लेटफ़ॉर्म विफल होते हैं, तो टनल और क्रेडेंशियल लगभग निश्चित रूप से ठीक होते हैं, क्योंकि वे साझा हैं। जो अलग है वह यह है कि हर क्लाइंट मिले कॉन्फ़िगरेशन पेलोड को कैसे लागू करता है, जिसमें आंतरिक DNS सर्वर भी शामिल है। जो क्लाइंट पता स्वीकार करता है पर क्वेरी टनल के बाहर से भेजता है, वह ऐसे रिज़ॉल्वर पर पहुँचता है जिसे वह देख सकता है और उपयोग नहीं कर सकता।

सार्वजनिक पता सामान्य विकल्प है क्योंकि यही वह है जिसे एडमिनिस्ट्रेटर पहले से जानता है। यह वह एकमात्र पता भी है जो टनल के अपने प्रीफ़िक्स से बाहर होने की गारंटी देता है, और यही गुण Apple के क्लाइंट को तोड़ता है।

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

रिज़ॉल्वर को लीज़ रेंज से अलग काटें

टनल को ऐसी पता योजना दें जिसमें रिज़ॉल्वर पूल के अपने सबनेट का सदस्य हो, फिर उस पते को आरक्षित रखें ताकि वह कभी किसी क्लाइंट को लीज़ पर न मिले। इस उदाहरण में पूल 10.180.7.0/24 है, सर्वर 10.180.7.1 रखता है, और लीज़ 10.180.7.2 से शुरू होती हैं।

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

पूल प्रीफ़िक्स और रिज़ॉल्वर एक ही सबनेट साझा करते हैं, इसलिए जो रूट पहले से टनल ट्रैफ़िक ढोता है वही क्वेरी भी ढोता है। यही एक गुण सुधार को क्लाइंट के पार ले जाने योग्य बनाता है। swanctl कॉन्फ़िगरेशन में वही दो तथ्य ipsec.conf सिंटैक्स के बजाय पूल परिभाषा और कनेक्शन पर DNS सेटिंग के रूप में दिखते हैं।

सर्वर को इसके लिए नया भौतिक इंटरफ़ेस नहीं चाहिए। लूपबैक इंटरफ़ेस में 10.180.7.1 जोड़ना ही पर्याप्त है ताकि रिज़ॉल्वर बाइंड होकर जवाब दे, क्योंकि क्लाइंट पहले से मौजूद पूल रूट से वहाँ पहुँचते हैं। पते को लीज़ रेंज से बाहर रखें ताकि कोई क्लाइंट गलती से उसे न ले। अगर पूल बाहरी DHCP या RADIUS सेवा से प्रबंधित है, तो वहाँ भी पता आरक्षित करें, वरना पूछने वाला पहला क्लाइंट उसे ले लेगा।

रिज़ॉल्वर बाइंड करें और पोर्ट 53 बंद करें

पता देना उस पर सुनना नहीं है। जो रिज़ॉल्वर केवल LAN पते पर सुनता है वह पूल पते पर भेजी क्वेरी अस्वीकार या अनदेखा करेगा, और क्लाइंट को राउटिंग विफलता जैसा टाइमआउट दिखता है।

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

यह unbound अंश टनल पूल से क्वेरी स्वीकार करता है और बाकी सब अस्वीकार करता है, जो अधिकांश कॉर्पोरेट रिज़ॉल्वर चाहते हैं। अगर वही इंस्टेंस LAN क्लाइंट को भी जवाब देता है, तो श्रोता को सभी स्रोतों तक बढ़ाने के बजाय LAN प्रीफ़िक्स स्पष्ट रूप से जोड़ें।

फिर फ़ायरवॉल नियमों को रिज़ॉल्वर के अपने एक्सेस नियंत्रण से मेल खाना चाहिए। पूल से पोर्ट 53 स्वीकार करें और बाकी हर जगह उसे गिरा दें, पर पहले चेन का क्रम जाँचें।

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

पहले का, अधिक व्यापक स्वीकृति नियम उन आखिरी दो पंक्तियों को सजावट बना देता है, और रिज़ॉल्वर इंटरनेट से पहुँचने योग्य रहता है। आपके इरादे के क्रम पर भरोसा करने के बजाय काउंटरों के साथ प्रभावी नियम-समुच्चय पढ़ें। वैकल्पिक नीति, सार्वजनिक पता भेजना और किसी भी स्रोत से क्वेरी की अनुमति देना, कई क्लाइंट के लिए काम करती है, पर रिज़ॉल्वर को इंटरनेट पर रखती है और उसे अपनी दर-सीमा और निगरानी चाहिए।

जाँचें कि क्लाइंट को वास्तव में क्या मिला

पहले सर्वर का दृश्य देखें, फिर क्लाइंट का, क्योंकि दोनों सूचनाप्रद तरीके से असहमत होते हैं। पूल सूची दिखाती है कौन-सा पता लीज़ पर दिया गया, और सुरक्षा संबंधों की सूची दिखाती है कि कनेक्शन अपेक्षित पहचान के साथ चालू है या नहीं।

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

सीधी क्वेरी साबित करती है कि रिज़ॉल्वर पूल पते पर ऐसे होस्ट से जवाब देता है जो वहाँ पहुँच सकता है। यह साबित नहीं करती कि Mac ने वही सर्वर चुना। macOS पर scutil --dns हर स्कोप्ड सेवा के लिए रिज़ॉल्वर सूचीबद्ध करता है और सारांश पैनल से अधिक जानकारीपूर्ण है; Windows पर Get-DnsClientServerAddress दिखाता है कि टनल एडाप्टर ने भेजा गया मान स्वीकार किया या नहीं।

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