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 ले टनेल एडाप्टरले पठाइएको मान स्वीकार गर्यो कि भनेर देखाउँछ।

यदि क्लाइन्टले पूल ठेगाना देखाउँछ र क्वेरी अझै टाइमआउट हुन्छन् भने, दोष टनेल मार्ग वा फायरवाल चेनको हो। जुन क्लाइन्टले कुनै रिजोल्भर रिपोर्ट गर्दैन भने कन्फिगरेसन पेलोड कहिल्यै पुगेन भन्ने हुन्छ, त्यसैले नेटवर्कतर्फ नहेरी त्यो प्लेटफर्मले पठाइएका सेटिङ कसरी लागू गर्छ हेर्नुहोस्। अरू केही बदल्नुअघि यी दुईमध्ये कुन अवस्था देख्नुभयो लेख्नुहोस्। यी दुवै असफलता सहयोग टिकटमा उस्तै देखिन्छन् र विपरीत मर्मततर्फ लैजान्छन्।