strongSwan ESP-in-UDP: शोधण्यासाठी NAT नसताना

NAT शोध हा पत्त्यांचा अनुवाद शोधतो, फायरवॉल धोरण नाही. NAT नसलेल्या साइट कनेक्शनला तरीही स्पष्ट ESP-in-UDP निवडीची गरज असू शकते.

NAT शोध एका प्रश्नाचे उत्तर देतो: मार्गात पत्ते किंवा पोर्ट बदलले का? फायरवॉल IP प्रोटोकॉल 50 ला परवानगी देतो का, याचे उत्तर तो देत नाही। कोणतेही अनुवाद नसलेले साइट गेटवे अजूनही native ESP टाकून देणाऱ्या धोरणामागे असू शकतात, आणि ती आवश्यकता शोधण्याऐवजी कॉन्फिगर करावी लागते। यंत्रणा ESP-in-UDP आहे, आणि हा निर्णय आहे, स्वतःहून येणारा पर्याय नाही।

शोध हा पत्त्यांवरील अंकगणित आहे, फायरवॉल चाचणी नाही

IKEv2 NAT शोध पेलोड वाहून नेतो, त्यात स्रोत व गंतव्य पत्ते आणि पोर्टचे हॅश असतात। प्रत्येक बाजू मिळालेल्याची स्थानिक पातळीवर दिसणाऱ्याशी तुलना करते, आणि फरक आढळल्यास काहीतरी पॅकेटचे अनुवाद केले असे त्याला कळते। त्या देवाणघेवाणीत मधल्या राउटरने प्रोटोकॉल 50 पुढे पाठवला का हे तपासणारे काहीही नाही।

व्यावहारिक परिणाम सरळ सांगण्यासारखा आहे। native ESP सह चालणारी बोगदा नवीन निर्बंधक फायरवॉल स्वतः शोधणार नाही, आणि IKE यशस्वी होत असतानाच तिचा पुढील प्रयत्न डेटा टप्प्यात अयशस्वी होईल। तुम्हाला प्रस्थापित IKE सुरक्षा संघ दिसतील आणि कोणताही संरक्षित रहदारी नाही, हे तारेवर कॅप्चर करेपर्यंत राउटिंग दोषासारखे वाटते।

म्हणून एन्कॅप्सुलेशन हे तुम्ही कॉन्फिगर करत असलेल्या कनेक्शनचे गुणधर्म आहे, नेटवर्कच्या वर्तनातून पक्षकार वाटाघाटी करणारा निकाल नाही।

encap देवाणघेवाण कशी बदलतो

आधुनिक strongSwan तैनातीत, ती swanctl.conf द्वारे व्यवस्थापित होते, कनेक्शनवरील encap = yes सेटिंग NAT शोध देवाणघेवाणीवर परिणाम करते जेणेकरून दोन्ही पक्ष ESP साठी UDP एन्कॅप्सुलेशन वापरतील। संरक्षित पॅकेट नंतर UDP मध्ये, सामान्यतः पोर्ट 4500 वर प्रवास करतात, आणि दोन्ही टोकांनी या व्यवस्थेला सहमती द्यावी लागते।

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan चे NAT-traversal मार्गदर्शक हे वर्तन वर्णन करते, MOBIKE वापरताना पोर्ट फ्लोटिंगशी होणाऱ्या परस्परसंवादासह।

तुमच्या बॅकएंडची असलेली सेटिंग वापरा

strongSwan मध्ये दोन कॉन्फिगरेशन बॅकएंड आहेत, आणि की त्यांच्यात वेगळी आहे। swanctl.conf कनेक्शन encap घेते, तर जुने ipsec.conf कनेक्शन forceencaps घेते। एका बॅकएंडचा कीवर्ड दुसऱ्यात टाकल्यास तक्रार न करता लोड होणारे आणि काहीही न बदलणारे कॉन्फिगरेशन तयार होते, जे त्रुटीपेक्षा वाईट आहे।

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

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

गुंडाळलेल्या डेटाची पडताळणी करा, केवळ पोर्टची नाही

संरक्षित रहदारी वाहत असताना गेटवेवर कॅप्चर करा, नंतर त्याची strongSwan च्या स्वतःच्या दृश्याशी तुलना करा:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP प्रोटोकॉल 50 म्हणून दिसतो आणि UDP सारखा अजिबात वाटत नाही। गुंडाळलेला ESP 4500 वर UDP डेटाग्राम म्हणून दिसतो, त्यांचा पेलोड IKE नाही। त्याच पोर्टवरील IKE रहदारी एन्कॅप्सुलेशनचा पुरावा नाही, कारण MOBIKE IKE तिथे हलवू शकतो आणि डेटा मार्ग native राहतो, म्हणून पोर्ट क्रमांक नाही, पेलोड वाचा।

मार्गाचा MTU देखील लक्षात ठेवा। आवरण अतिरिक्त खर्च जोडते, आणि native ESP वाहून नेणाऱ्या मार्गाला पॅकेट मोठे झाल्यावर समायोजनाची गरज पडू शकते। आवश्यक ICMP हाताळणी आधीच रचनेचा भाग असावी; एन्कॅप्सुलेशन ते अवलंबन काढून टाकत नाही।

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

संबंधित लेख