strongSwan vips: IKEv2 से वर्चुअल पता माँगना

vips एक आंतरिक IKEv2 पता माँगता है; गेटवे तय करता है कि क्या देगा। अनुरोध सेट करें, उसे लोड करें, और फिर जाँचें कि प्रतिसादकर्ता ने वास्तव में क्या आवंटित किया।

आपका IKEv2 क्लाइंट गेटवे से आंतरिक पता माँग सकता है, और गेटवे तय करता है कि क्या लौटाएगा। strongSwan में वही अनुरोध vips सेटिंग है, और उसमें कोई ठोस पता लिखने पर भी वह अनुरोध ही रहता है। नीचे दिया गया रनबुक अनुरोध सेट करता है, उसे लोड करता है और जो लौटा उसे पढ़ता है, क्योंकि ये तीन चरण तीन अलग-अलग तरह से विफल होते हैं। ज़ोर से टाइप करने पर भी इनमें से कोई छोटा नहीं होता।

vips क्या माँगता है, और क्या वादा नहीं कर सकता

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

0.0.0.0 माँगना किसी भी उपलब्ध IPv4 वर्चुअल पता को माँगना है, जो आमतौर पर तब सही होता है जब सटीक मान मायने न रखता हो। कोई ठोस पता माँगना गेटवे के लिए एक संकेत है, उस पर कोई माँग नहीं।

swanctl अंश और उसका स्थान

सेटिंग कनेक्शन ब्लॉक के भीतर बैठती है, न अपनी अलग फ़ाइल में और न ऑपरेटिंग सिस्टम प्रोफ़ाइल में। यह अलग किया गया अंश आकार दिखाता है:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

इसे उस फ़ाइल से लोड करें जिसके पास कनेक्शन है, फिर कनेक्शन शुरू करें और परिणाम पढ़ें। गलत खंड में चिपकाया गया अंश पार्स त्रुटि देता है या, इससे बुरा, ऐसा कनेक्शन देता है जो उस अनुरोध के बिना लोड होता है जो आपने किया समझा था। तीनों कमांड क्रम से चलाएँ और आउटपुट रखें।

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts ट्रैफ़िक चुनता है, पता नहीं बनाता

local_ts उस ट्रैफ़िक-समूह का नाम देता है जिसे चाइल्ड SA सुरक्षित रखता है; यह किसी इंटरफ़ेस पर पता नहीं रखता। एक बार वर्चुअल IP पर बातचीत हो जाने के बाद strongSwan अपने डिफ़ॉल्ट गतिशील चयनक का उपयोग बंद कर देता है और उसके बदले आवंटित पता इस्तेमाल करता है। यदि आप चयनक को किसी शाब्दिक पते पर पिन करते हैं, तो आप ऐसी बात का दावा कर रहे हैं जो गेटवे ने शायद आवंटित नहीं की, और इसीलिए विफलता एक काम करते SA के रूप में दिखती है जिसका ट्रैफ़िक कहीं नहीं जा रहा। चयनक ट्रैफ़िक का वर्णन करता है, जबकि आवंटन दूसरे आदान-प्रदान से आता है।

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

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

जाँचें कि प्रतिसादकर्ता ने वास्तव में क्या आवंटित किया

गेटवे ने जो पता दिया उसके लिए SA सूची पढ़ें, फिर पुष्टि करें कि पता इंटरफ़ेस पर मौजूद है। यदि दोनों मेल नहीं खाते, तो सुरंग ऊपर है और ट्रैफ़िक वहाँ नहीं जा रहा जहाँ आप सोचते हैं। आवंटित पता जो कभी इंटरफ़ेस तक नहीं पहुँचता, इस क्रम की सबसे भ्रमित करने वाली विफलता है, क्योंकि हर आधा अकेले में सही दिखता है।

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

स्थिर डिज़ाइन अलग रखें

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

अंतर्निहित Mac क्लाइंट में इनमें से कोई विकल्प नाम मौजूद नहीं है। गेटवे जो भी आवंटन या आरक्षण दे और ऑपरेटर जो प्रोफ़ाइल प्रकाशित करे उसका उपयोग करें, और आवंटन दोबारा पढ़ने तक क्लाइंट-पक्ष के किसी भी मान को संकेत मानें। रोलबैक का अर्थ है vips पंक्ति हटाकर पुनः लोड करना, जो आपको उस स्थिति में लौटा देता है जो गेटवे डिफ़ॉल्ट रूप से आवंटित करता है।

संबंधित लेख