strongSwan मधील संपूर्ण टनेलसाठी दोन्ही बाजूंना 0.0.0.0/0 आवश्यक

एका खाजगी सबनेटसाठी काम करणारे strongSwan कनेक्शन केवळ कोणी एक ओळ संपादित केली म्हणून इंटरनेट रहदारी वाहून नेणार नाही। संपूर्ण टनेल म्हणजे child SA कोणत्या पत्त्यांचे संरक्षण करते याबद्दल दोन पक्षांमधील करार, आणि प्रत्येक पक्ष दुसऱ्याला स्वतःच्या संदर्भात नाव देतो। एक बाजू बरोबर आणि दुसरी चुकीची केल्यास child SA एकतर वर येणार नाही किंवा अपेक्षेपेक्षा अरुंद वर येईल। खालील पाच तपासण्या त्या कराराचा क्लायंटपासून गेटवेमार्गे इंटरनेटपर्यंत मागोवा घेतात।

प्रथम क्लायंटचा सिलेक्टर तपासा

क्लायंट दुर्गम बाजूला कशाचे संरक्षण करायचे आहे ते remote_ts म्हणून वर्णन करतो, आणि तो जे पाठवतो ते सर्व त्याच्या स्वतःच्या नेमून दिलेल्या पत्त्यावरून जाते। इंटरनेट रहदारीसाठी ते मूल्य वापरकर्ता प्रत्यक्षात पोहोचणाऱ्या गंतव्यस्थानांचा समावेश करणे आवश्यक आहे, ज्याचा प्रत्यक्ष अर्थ संपूर्ण IPv4 जागा आहे। अजूनही एक सबनेट सूचीबद्ध करणारा क्लायंट इंटरफेसमधील प्रोफाइलचे नाव काहीही असो, विभाजित टनेल मागत आहे। स्रोत बाजू सहसा dynamic असते कारण जोडणीच्या वेळी पत्ता नेमला जातो। तिथे लिहिलेला स्थिर स्रोत पत्त्यांचा संच बदलताच तुटतो।

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

हा तुकडा संपूर्ण कनेक्शन फाइल नाही, आणि हा प्रमाणीकरण, ओळख आणि आभासी पत्त्यांचा संच आधीच संरचित आहे असे गृहीत धरतो। क्लायंटचा स्रोत सिलेक्टर आणि सर्व्हरने नेमलेला पत्ता अजूनही जुळला पाहिजे, अन्यथा child SA कोणत्याही बाजूने अपेक्षा न केलेल्या व्याप्तीसह वर येईल। तो swanctl --load-all ने लोड करा आणि यश गृहीत धरण्यापूर्वी आउटपुट वाचा। पार्स होणारी फाइलही दुसऱ्या पक्षाच्या प्रस्तावाशी न जुळणाऱ्या सिलेक्टरमुळे नाकारली जाऊ शकते।

गेटवेचा सिलेक्टर त्याच्या स्वतःच्या बाजूला तपासा

गेटवे तीच संकल्पना विरुद्ध दिशेने वाचतो। इंटरनेट गंतव्ये गेटवेसाठी स्थानिक असतात, म्हणून त्याचा local_ts रुंद आहे आणि remote_ts क्लायंट संचाचे वर्णन करतो। हे उलटेपण संपूर्ण-टनेल संरचनेतील सर्वात सामान्य चूक आहे, आणि दोन्ही ओळी स्वतंत्रपणे विश्वासार्ह दिसत असल्याने ती पुनरावलोकनातून जाते।

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

क्लायंटचा तुकडा गेटवे फाइलमध्ये कॉपी केल्यास उपयुक्त काहीही वर्णन न करणारी सिलेक्टर जोडी तयार होते, कारण दोन्ही बाजू एकाच भूमिकेचा दावा करतील। strongSwan फॉरवर्डिंग मार्गदर्शक क्लायंट आणि गेटवे जोडीचे स्पष्टपणे दस्तऐवजीकरण करते, आणि ते अपयशानंतर नव्हे तर कनेक्शन फाइलच्या शेजारी वाचण्यासारखे आहे। गेटवे फाइलला remote_ts संदर्भित करणाऱ्या संचाची व्याख्या देखील आवश्यक आहे। अस्तित्वात नसलेल्या संचाचे नाव घेणारा सिलेक्टर तक्रारीशिवाय लोड होतो आणि जोडणीच्या वेळी अपयशी ठरतो।

जुना ipsec.conf वेगवेगळ्या किल्ल्यांसह डाव्या आणि उजव्या भूमिका वापरतो, आणि rightsubnet ओळ swanctl मूल्याची थेट जागा घेणारी नाही। दोन्ही वाक्यरचना एक दुसऱ्यात चिकटवण्याऐवजी वेगळ्या फाइलांमध्ये ठेवा। त्या एकाच डिरेक्टरीत मिसळणे म्हणजे कार्यरत कनेक्शन रीबूटनंतर शांतपणे मागे जाण्याचा मार्ग।

फाइल नाही, वाटाघाटी झालेला child SA तपासा

जतन केलेली संरचना हेतू सिद्ध करते आणि त्यापेक्षा जास्त काही नाही। दुसरा पक्ष मागितलेले अरुंद करू शकतो, आणि त्याखालील फाइल बदलली म्हणून विद्यमान child SA बदलला जात नाही। दुसरे काहीही बदलण्यापूर्वी प्रत्यक्षात काय स्थापित आहे याची पुष्टी करा।

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

पहिला आदेश डीमनने काय लोड केले ते दाखवतो, दुसरा स्थापित child SA दाखवतो, आणि तिसरा कर्नेल लागू करणारी धोरणे दाखवतो। फाइल 0.0.0.0/0 म्हणत असेल आणि यादी एक सबनेट दाखवत असेल, तर वाटाघाटीने व्याप्ती अरुंद केली आहे आणि फाइल पुन्हा वाचल्याने ते स्पष्ट होणार नाही। child थांबवा, पुन्हा सुरू करा, आणि तीनही आउटपुट पुन्हा तुलना करा। त्याच अरुंद व्याप्तीसह परत येणारा child स्थानिक फाइलने नव्हे तर दूरच्या बाजूने अरुंद केला जातो, आणि तो स्थानिक संपादन नसून दुसऱ्या प्रशासकाशी संवाद आहे।

धोरण यादीत दोन्ही दिशा वाचा, कारण एक दिशा स्थापित करून दुसरी न करणारे टनेल म्हणजे संरचनेच्या वेशातील मार्गनिर्देशन समस्या। पुढे आणि मागे धोरणांनी तीच सिलेक्टर जोडी आरशासारखी नावाने नमूद केली पाहिजे, आणि गहाळ आरसा सिलेक्टर मजकुरात नसून डीमन किंवा प्रस्तावातील दोष आहे।

फॉरवर्डिंग आणि परतीचा मार्ग तपासा

सिलेक्टर रहदारीला गेटवेकडे येऊ देतो, पण गेटवेला ती रहदारी पुढे मार्गनिर्देशित करण्यास भाग पाडत नाही। फॉरवर्डिंग सक्षम असणे, फायरवॉलने प्रवाहास परवानगी देणे, आणि उत्तराला क्लायंट संचापर्यंत परतीचा मार्ग सापडणे आवश्यक आहे। या तीन स्वतंत्र अटी आहेत, आणि प्रत्येक वेगळ्या लक्षणाने अपयशी ठरते। गहाळ फॉरवर्ड नियम काळ्या छिद्रासारखा वागतो, तर गहाळ परतीचा मार्ग एकमार्गी टनेलसारखा।

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

खाजगी क्लायंट पत्त्यांना सहसा सार्वजनिक इंटरफेस सोडण्यापूर्वी जाणीवपूर्वक स्रोत भाषांतर आवश्यक असते, तर स्पष्टपणे मार्गनिर्देशित वाटपास वेगळी वागणूक आवश्यक असते। NAT गुंतलेला असल्यास, अंमलबजावणीने समर्थित अपवाद ठेवा जेणेकरून सुरक्षा धोरणाने तपासावयाच्या रहदारीचे त्याच्यापुढे भाषांतर होऊन ती चुकवली जाणार नाही। दुसऱ्या गेटवेवरून कॉपी केलेला रुंद masquerade नियम लेखकाच्या हेतूपेक्षा खूप जास्त प्रवाह बदलतो। नियम केवळ क्लायंट संचासाठी लिहा, आणि तो का आहे हे सांगणारी टिप्पणी ठेवा।

क्लायंटवर तुम्ही गृहीत धरलेल्या मार्गांऐवजी बॅकएंडने स्थापित केलेले मार्ग पुष्टी करा। मार्ग स्थापना बंद असलेल्या व्यवस्थापकाला हाताने सांभाळलेली मार्गनिर्देशन रचना आवश्यक असते, आणि टनेल बदलल्यावर ती रचना अद्ययावत करावी लागते। पुन्हा जोडल्यानंतर मार्गनिर्देशन तक्ता तपासा, केवळ नवीन बूटनंतर नाही।

टनेलने अजून काय व्यापले नाही ते तपासा

सिलेक्टर जोडी IPv4 व्यापते आणि दुसरे काहीही नाही। IPv6, DNS आणि कोणतेही अनुप्रयोग-स्तरीय धोरण हे स्वतंत्र निर्णय आहेत ज्यांना रुंद IPv4 सिलेक्टर शांतपणे दुर्लक्षित करतो। प्रत्येक IPv4 पॅकेट वाहून नेणारे टनेलही प्रत्येक नाव-शोध गळू शकते।

इच्छित DNS मार्ग स्पष्टपणे सांगा, कारण स्थानिक रिझॉल्व्हरद्वारे नावे सोडवणारे संपूर्ण टनेल टनेलबाहेर प्रश्न गळते आणि खाजगी नावे तोडते। क्लायंटला IPv6 पत्ता नेमला गेल्यास त्या पत्ता-कुटुंबालाही तीच वागणूक आवश्यक आहे, अन्यथा यजमान टनेल संरक्षित न करणाऱ्या मार्गाला प्राधान्य देईल। केवळ खाजगी बाजू उत्तर देऊ शकेल अशा नावाने चाचणी करा, आणि सार्वजनिक उत्तर गळती माना।

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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