VPN जोडले आहे पण फायरवॉल अजूनही अडवत आहे: कोणते ते कसे ओळखावे

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

मार्ग धोरणापासून वेगळा करा

अपयशाच्या आकाराने सुरुवात करा, कारण ती मोफत माहिती आहे। पॅकेट पडल्यावर कालबाह्यता येते: क्लायंट पुन्हा प्रयत्न करतो, काहीही परत येत नाही, आणि आदेश हार मानेपर्यंत लटकतो। नाकारणे नकार किंवा रीसेट निर्माण करते: काहीतरी उत्तर दिले आणि नाही म्हणाले। न ऐकणारी सेवा होस्टवरच नाकारते, कोणत्याही फायरवॉलशिवाय।

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

मार्ग एका फेरीत वाचा

एकही नियम पाहण्यापूर्वी टनेल गंतव्यस्थान व्यापते याची खात्री करा। फक्त कार्यालयीन उपजाळे वाहून नेणारी विभाजित टनेल विनंती दुसऱ्या श्रेणीत पाठवणार नाही, आणि मग अपयश फायरवॉल अडवण्यासारखे दिसते, जे तसे नाही:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

मार्गाचे आउटपुट पॅकेट कोणत्या इंटरफेसने बाहेर पडेल आणि कोणता स्रोत पत्ता वाहून नेईल ते सांगते। तो इंटरफेस टनेल नसून तुमचा भौतिक नेटवर्क कार्ड असेल, तर समस्या राउटिंगमध्ये किंवा टनेलच्या परवानगी असलेल्या श्रेणींमध्ये आहे, आणि ती फायरवॉलची नाही, VPN संरचनेची आहे।

VPN-शी संबंधित एक सापळा स्वतंत्र तपासणीस पात्र आहे। WireGuard मध्ये पीअरचे AllowedIPs एकाच वेळी मार्ग आणि क्रिप्टोग्राफिक गाळणी आहे: ज्या पॅकेटचा स्रोत पत्ता पीअरच्या परवानगी असलेल्या संचाशी जुळत नाही ते कोणताही फायरवॉल नियम पाहण्यापूर्वीच टाकून दिले जाते। त्यामुळे पूर्णपणे बरोबर होस्ट फायरवॉल धोरणासारखे दिसणाऱ्या शांत टाकून देण्यामागे असू शकते, आणि उपाय नियम नाही, की संरचनेची एक ओळ आहे।

उत्तर देणाऱ्या स्तरावर धोरण वाचा

मार्ग बरोबर झाल्यावर, होस्टपासून बाहेरच्या दिशेने धोरणातून जा आणि ज्याचे काउंटर हलतात तो एकच स्तर पाहा:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

टनेल तिथेच संपत असेल तर गेटवेचा निर्णय वाचा

साइट-टू-साइट किंवा दूरस्थ प्रवेश गेटवेवर, VPN वापरकर्त्याची पडताळणी करते आणि धोरण संसाधनास अधिकृत करते, आणि ही वेगळी परवानगी आहेत। टनेलमध्ये प्रवेश मिळालेल्या वापरकर्त्यास प्रत्येक अंतर्गत होस्टवर स्वयंचलित प्रवेश नसतो, आणि नकार बऱ्याचदा टनेल स्वतः निरोगी असताना फॉरवर्डिंग नियमातून येतो। तेच विभाजन IPsec मध्ये दिसते, जिथे रहदारी निवडणारे सुरक्षा धोरण ती प्रवेश देणाऱ्या गाळणीपेक्षा वेगळे आहे, आणि म्हणूनच दोन्हींची वेगवेगळ्या यंत्रणा म्हणून RFC 4301।

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

गेटवे हे असेही स्थान आहे जिथे NAT किंवा मास्करेड नियम खरा स्रोत लपवू शकतो। अंतर्गत होस्ट क्लायंटऐवजी गेटवेचा पत्ता पाहत असतील, तर क्लायंट पूलशी जुळायला हवे असलेले त्यांचे होस्ट फायरवॉल नियम कधीच जुळणार नाहीत, आणि उपाय प्रत्येक सर्व्हरवर नाही, गेटवेवर आहे।

सर्वात अरुंद स्तर बदला, नंतर पडताळा

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

ज्या चाचणीत अपयश आले तीच चाचणी, त्याच क्लायंटकडून पडताळा, आणि नंतर पुन्हा जोडल्यावर आणखी एकदा, कारण टनेल पुन्हा बोलणी करण्यापूर्वी जुळणारा नियम नंतर न जुळू शकतो:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

ते बंद करण्यापूर्वी:

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