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 टनेल अडॅप्टरने पाठवलेले मूल्य स्वीकारले का ते दाखवते.

क्लायंट पूल पत्ता दाखवत असेल आणि क्वेरी तरीही टाइमआउट होत असतील, तर दोष टनेल मार्गाचा किंवा फायरवॉल साखळीचा आहे। जो क्लायंट कोणत्याही रिझोल्व्हरची नोंद देत नाही त्याचा अर्थ कॉन्फिगरेशन पेलोड कधीच पोहोचला नाही, म्हणून नेटवर्ककडे न पाहता तो प्लॅटफॉर्म पाठवलेली सेटिंग्ज कशी लागू करतो ते पाहा. दुसरे काहीही बदलण्यापूर्वी या दोनपैकी कोणती स्थिती पाहिली ते लिहा. या दोन्ही अपयश सपोर्ट तिकिटात सारखीच दिसतात आणि विरुद्ध दुरुस्तीकडे नेतात.