VPN मार्ग की फायरवॉल नियम: पॅकेट कोण सोडत आहे?

एकाच पॅकेटवर दोन स्वतंत्र निर्णय घेतले जातात आणि यापैकी कोणताही विनंती शांतपणे संपवू शकतो. मार्ग शोध एक इंटरफेस आणि पुढील हॉप निवडतो, नंतर पॅकेट फिल्टर ते संयोजन अनुमत आहे की नाही हे ठरवतो. कालबाह्यता तुम्हाला सांगते की दोनपैकी एकाने नकार दिला, कोणी हे नाही. टप्पे क्रमाने करा आणि दुरुस्ती सहसा अंदाज राहणे थांबते.

दोन निर्णय, एक पॅकेट, दोन मालक

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

फिल्टरिंग वेगळे आहे. Linux होस्टवर netfilter हुक पॅकेट कोणासाठी आहे यानुसार रहदारी विभागतात: आउटपुट मशीन सोडते, इनपुट त्यावर संपते, फॉरवर्ड त्यातून जाते. VPN क्लायंट स्वीकारून त्यांना LAN मध्ये मार्गस्थ करणाऱ्या गेटवेला फॉरवर्ड मार्ग आवश्यक असतो आणि बहुतेक डीफॉल्ट संरचना रिकामी ठेवतात तीच साखळी ही आहे.

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

शोधाने प्रत्यक्षात काय निवडले ते वाचा

निर्णयाचा अंदाज न लावता तो छापा. खालील आदेश त्या गंतव्यासाठी कर्नेल वापरेल तो मार्ग सोडवतो, त्यात इंटरफेस आणि तो निवडेल तो स्रोत समाविष्ट आहे:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN क्लायंट अनेकदा मुख्य तक्त्याच्या खालील प्राधान्यांवर धोरण नियम स्थापित करतात, त्यामुळे स्वच्छ मुख्य तक्ता स्वतःहून काहीही सिद्ध करत नाही. नियमांच्या प्राधान्यांची ते निवडतात त्या तक्त्यांशी तुलना करा आणि टनेल मार्ग एकदा हाताने जोडण्याऐवजी पुन्हा जोडणीनंतर टिकतो का ते तपासा.

धोरण-आधारित IPsec तिसरा जुळणी टप्पा जोडतो जो मार्गनिर्देशन व्यापत नाही, असे strongSwan च्या फॉरवर्डिंग टिपा टनेल आणि वाहतूक संरचनांसाठी वर्णन करतात. सुरक्षा धोरण रहदारी उपसर्ग आणि प्रोटोकॉलनुसार निवडते, तर मार्ग केवळ असंरक्षित पॅकेट कुठे जाईल हे ठरवतो. मार्गस्थ केलेला पण जुळणारा निवडक नसलेला उपजाळ एकतर असंरक्षित राहतो किंवा संरचनेनुसार टाकला जातो आणि दोन्हीपैकी कोणताही परिणाम फायरवॉल समस्येसारखा दिसत नाही. धोरण छापा आणि त्याच्या निवडकांची टनेल वाहून नेईल अशी अपेक्षा केलेल्या उपसर्गांशी तुलना करा.

फिल्टरिंग हुकवर लागू होते, मार्गावर नाही

VPN श्रोत्याला परवानगी देणारा नियम गेटवेकडेच पाठवलेल्या रहदारीबद्दलचा नियम आहे. त्या गेटवेच्या मागील होस्टपर्यंत पोहोचणाऱ्या क्लायंटबद्दल तो काहीही सांगत नाही, कारण फॉरवर्ड केलेली रहदारी वेगळ्या साखळीतून जाते. नियमसंच एक सपाट यादी म्हणून वाचणे हेच बरोबर दिसणारा नियम कधीही सक्रिय न होण्याचे नेहमीचे कारण आहे.

मोजण्या प्रश्न लवकर निकालतात. शून्य पॅकेट मोजणीच्या नियमापर्यंत कधीही पोहोचले नाही, जे चुकीची साखळी, चुकीचा इंटरफेस किंवा आधीचा टाका दर्शवते. टाका धोरणाखाली वाढणाऱ्या मोजणीचा नियम हीच तुम्ही शोधत असलेली सीमा आहे आणि पॅकेट चुकीच्या मार्गाने जाण्याऐवजी टाकला जातो.

क्लायंट वापरतो त्या मार्गाने प्रोब पाठवा

गेटवेवरच चालवलेल्या चाचण्या गेटवेच्या स्वतःच्या स्रोत पत्त्यासह आउटपुट आणि इनपुटमधून जातात. तो क्लायंटच्या फॉरवर्ड केलेल्या विनंतीपेक्षा वेगळा मार्ग आहे, त्यामुळे यशस्वी स्थानिक curl दिसते त्यापेक्षा कमी सिद्ध करतो. अयशस्वी होणाऱ्या मशीनवरून चाचणी करा किंवा इंटरफेस आणि स्रोत स्पष्टपणे पिन करा.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

दोन्ही टोकांवर कॅप्चर उर्वरित प्रकरणे वेगळी करते. क्लायंट सोडून कधीही न पोहोचणारा SYN म्हणजे मार्गनिर्देशन, एन्क्रिप्शन किंवा वरची प्रवेश यादी. पोहोचून उत्तर न मिळणारा SYN म्हणजे सेवा किंवा तिचा होस्ट फिल्टर आणि टनेल कधीही समस्या नव्हता.

परत येणारी रहदारी स्वतंत्र पाहण्यास पात्र आहे. असममित मार्गनिर्देशन आणि उलट मार्ग फिल्टरिंग चुकीच्या इंटरफेसवर येणारी उत्तरे टाकतात, जे बंद पोर्टऐवजी एकमार्गी जोडणी म्हणून दिसते. फायरवॉलने निर्माण न केलेल्या लक्षणासाठी त्याला दोष देण्यापूर्वी sysctl मूल्य तपासा.

लॉगिंग पहिली पायरी नाही तर दुसरे मत म्हणून काम करते. फॉरवर्ड साखळीवरील तात्पुरते लॉग विधान त्याला लागलेले इंटरफेस आणि पत्ते नावे देतात आणि नंतर काढणे सोपे आहे. ते कायम ठेवले तर उत्तराऐवजी लॉग व्हॉल्यूमची समस्या निर्माण केली आहे.

प्रत्येक बदल पुन्हा जोडणीनंतर टिकेल तिथे ठेवा

ip route add ने जोडलेला मार्ग इंटरफेस खाली जाईपर्यंत जिवंत राहतो. त्याऐवजी कनेक्शन प्रोफाइलमध्ये जतन करा: NetworkManager कनेक्शनवर अतिरिक्त मार्ग स्वीकारतो आणि netplan ते बूटदरम्यान ठेवतो. तोच नियम क्लायंट-साइड फायरवॉल अपवादाला लागू होतो, जो पुढील रीलोडनंतर जातो.

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

नंतर मूळ अनुप्रयोग विनंती सुरुवातीपासून शेवटपर्यंत पुन्हा करा आणि कोणता स्तर बदलला ते नोंदवा. ज्या मार्ग दुरुस्तीला फिल्टर बदलही आवश्यक होता ती तरीही अयशस्वी होईल आणि पहिली गेली हे कळल्यावर दुसरी अयशस्वीता वाचणे खूप सोपे असते. निकालाशेजारी तारीख आणि क्लायंट आवृत्ती नोंदवा, कारण मार्गनिर्देशन आणि फिल्टरिंग दोन्हींचे डीफॉल्ट आवृत्त्यांमध्ये बदलतात. ती नोंद तिकिटावर ठेवा जेणेकरून पुढील व्यक्ती दोन-टप्प्यांची यात्रा पुन्हा न करता तुम्ही थांबलात तिथून सुरुवात करेल.