TCP वर IKE 4500: पोर्ट नियमापूर्वी दोन्ही टोके तपासा
TCP एन्कॅप्सुलेशन दोन्ही टोके वाटाघाटी करतात, फायरवॉल नियम ते देत नाही। लिसनर तपासणी, कॅप्चर आणि चार स्वीकृती टप्पे क्रमाने चालवा।
सपोर्ट तिकिटे अनेकदा तेव्हा येतात जेव्हा फायरवॉल बदल आधीच मंजूर असतो आणि टनेल अजूनही वर येण्यास नकार देत असते। एका टोकाकडेच सुविधा असेल तेव्हा हाच अपेक्षित परिणाम असतो: RFC 9329 नुसार TCP एन्कॅप्सुलेशन दोन्ही टोकांवर अंमलात आणून कॉन्फिगर करावे लागते, आणि कोणताही संरक्षित रहदारी हलण्यापूर्वी करार कनेक्शनच्या आत होतो। पोर्ट उघडणे म्हणजे कदाचित नसलेल्या लिसनरची जाहिरात करणे, आणि दुसऱ्या बाजूला जुळणारी कॉन्फिगरेशन नसलेला लिसनर कनेक्शन स्वीकारून नंतर गप्प बसतो। खालील क्रम स्वस्त तपासण्या आधी ठेवतो।
पर्याय प्रत्यक्षात काय जोडतो ते जाणून घ्या
मूळ IPsec एन्क्रिप्टेड पेलोड अशा प्रकारे वाहतो: IP प्रोटोकॉल 50, परवानगी देण्यासाठी कोणताही पोर्ट क्रमांक नसताना। NAT ट्रॅव्हर्सल ती पॅकेट UDP मध्ये गुंडाळून पोर्ट 4500 वर पाठवते, आणि म्हणूनच इतके फायरवॉल नियम त्या पोर्टचा उल्लेख करतात। RFC 9329 स्ट्रीम प्रस्तुती जोडते: IKE आणि IPsec पॅकेट दोन्ही एकाच TCP कनेक्शनच्या आत, सामान्यतः पोर्ट 4500 वर प्रवास करतात।
स्ट्रीम वेब सेवा नाही। 4500 वरचे TCP कनेक्शन HTTP, TLS किंवा प्रॉक्सी-अनुकूलतेबद्दल काहीही सांगत नाही, आणि मार्गातील HTTP प्रॉक्सी सामान्यतः ते वाहण्याऐवजी फ्रेमिंग तोडते।
फायरवॉलला स्पर्श करण्यापूर्वी पूर्व-तपासणी
मानक TCP ला UDP मार्ग सोडणाऱ्या नेटवर्कसाठी बॅकअप म्हणून ठेवते, त्याच्या पर्याय म्हणून नाही। प्रत्येक विक्रेत्याकडून दोन तथ्ये मिळवा: सुविधेचे नेमके नाव आणि मालकी हक्काच्या प्रकाराऐवजी RFC 9329 अंमलात आणणारी आवृत्ती। IPsec over TCP सारखी लेबले असंबंधित रचनांसाठी वापरली गेली आहेत, म्हणून दस्तऐवज संदर्भ आणि ते सुरू करणारी कॉन्फिगरेशन किल्ली मागा। दोन्ही उत्तरांशिवाय वायर सुसंगततेबद्दल काहीही गृहीत धरू नका।
दोन्ही टोके तुमची असलेल्या प्रयोगशाळेत ते सिद्ध करा। TCP 4500 वर प्रतिसाद देणारा पण IKE कधीही पूर्ण न करणारा गेटवे दुसऱ्या बाजूला जुळणारे एन्कॅप्सुलेशन नसलेल्या लिसनरचे लक्षण आहे, आणि ते तिथे शोधणे बदल विंडोदरम्यान शोधण्यापेक्षा खूप स्वस्त आहे।
प्रतिसादकाकडे: काही ऐकत आहे का
सॉकेटपासून सुरुवात करा। ss -ltnp | grep 4500 TCP लिसनर आहे का आणि कोणती प्रक्रिया त्याची मालक आहे हे दाखवते। ओळ नसणे तपासणी नेटवर्कवर नाही तर गेटवे कॉन्फिगरेशनवर संपवते।
सॉकेट असल्यास, क्लायंट बाजूने अंदाज लावण्याऐवजी हँडशेक पहा: tcpdump -ni any 'tcp port 4500'। पूर्ण झालेला तीन-मार्गी हँडशेक आणि नंतर शांतता म्हणजे स्ट्रीम स्वीकारली गेली आणि त्यातील IKE देवाणघेवाण अयशस्वी झाली, तर उत्तर नसलेला SYN फिल्टरिंग किंवा चुकीच्या पत्त्याकडे निर्देश करतो।
दोन्ही गोंधळू नयेत म्हणून त्याच कॅप्चर विंडोमध्ये UDP मार्गाशी तुलना करा: tcpdump -ni any 'udp port 4500 or proto 50'। TCP वापरला जात आहे असे तुम्हाला वाटत असताना प्रोटोकॉल 50 किंवा UDP पोर्ट 4500 वर रहदारी असणे म्हणजे दोन्ही टोकांनी बॅकअपबद्दल कधीही सहमती दिली नाही। शक्य असल्यास गेटवेवरही कॅप्चर करा, कारण क्लायंट-बाजूचे कॅप्चर दूरच्या टोकाने काय पाठवले हे दाखवू शकत नाही।
चार स्वतंत्र टप्प्यांत स्वीकारा
वर येण्याकडे चार निकाल म्हणून पहा। प्रत्येक वेगळ्या कारणाने अयशस्वी होऊ शकतो, आणि एकच पास किंवा फेल कोणते होते हे लपवते, म्हणून अयशस्वी होणाऱ्या पहिल्या टप्प्यावर थांबा आणि पुन्हा वरून सुरुवात करा।
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
चौथा टप्पा हा वगळला जातो। विद्यमान सत्र कॅश केलेल्या स्थितीवर काम चालू ठेवू शकते, म्हणून बदल बंद करण्यापूर्वी गेटवेच्या मागील होस्टवर नवीन कनेक्शन उघडा। दुसरा टप्पा अयशस्वी होऊन पहिला पास झाला तर मतभेद प्रस्तावात किंवा एन्कॅप्सुलेशन सेटिंगमध्ये आहे, फायरवॉलमध्ये नाही।
रोलबॅक, आणि ते सुरू ठेवण्याची किंमत
बदलापूर्वी पूर्ववत करण्याची योजना करा: दोन्ही टोकांवर एन्कॅप्सुलेशन पर्याय बंद करा आणि टनेल UDP वर परत येते याची खात्री करा। बॅकअप पुन्हा लागल्यास एका पुनरावलोकन चक्रासाठी TCP नियम ठेवा, नंतर तो काढून टाका। 4500 वरचा न वापरलेला लिसनर कोणत्याही कार्यात्मक मूल्याशिवाय पृष्ठभाग आहे।
खरे काम वाहू लागल्यावर कार्यक्षमतेचे लक्षण पहा। TCP च्या आतला TCP एकाच नुकसानीवर थांबणारे पावतीचे थर जोडतो, आणि एक कनेक्शन सामायिक करणारे स्ट्रीम एकमेकांना अडवू शकतात, म्हणून ping ऐवजी टनेल वापरणारे अनुप्रयोग मोजा।
स्वीकृती यादी
दोन्ही टोकांवर सुविधेचे नाव आणि आवृत्ती, प्रतिसादकाकडील लिसनर, पूर्ण हँडशेक दाखवणारे कॅप्चर, आणि वेळ-छापांसह नोंदवलेले चार टप्पे यांची खात्री करा। पुढील अभियंत्याला TCP का आहे हे कळावे म्हणून बदल नोंदीत बॅकअपचे कारण जोडा। गरज पडण्यापूर्वी रोलबॅकचा सराव करा।
कोणताही टप्पा अयशस्वी झाल्यास फक्त तोच टप्पा दुरुस्त करा। वाहतूक समस्येमागे लागण्यासाठी सायफर संच किंवा ओळख सेटिंग्ज बदलल्याने सामान्यतः पहिल्यावर दुसरी, असंबंधित अयशस्वीता येते।