लिनक्स वितरणाचा फायरवॉल तुमचा VPN रहदारी अडवू शकतो

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

व्यवस्थापक आणि बॅकएंड शोधा

जे प्रत्यक्षात लोड झाले आहे त्यापासून सुरुवात करा, जे स्थापित आहे त्यापासून नाही। वितरण firewalld, ufw आणि साधी nftables सेवा पुरवू शकते, आणि त्यापैकी फक्त एकच चालू नियमसंचाची मालकी बाळगते। पॅकेजेस शांतपणे एकत्र राहतात, आणि चुकीच्या फ्रंटएंडद्वारे प्रविष्ट केलेला नियम कधीही कर्नेलपर्यंत पोहोचत नाही। सक्रिय सेवा वाचा, नंतर तिने तयार केलेला नियमसंच वाचा।

बॅकएंड फ्रंटएंडइतकाच महत्त्वाचा आहे। firewalld ची स्थापना आवृत्ती आणि संरचनेनुसार nftables किंवा जुना iptables बॅकएंड चालवू शकते, आणि दोन्ही वेगळे तपासणी आउटपुट देतात। तुमची प्रणाली कोणत्याही मार्गदर्शकाशी तुलना करण्यापूर्वी वितरण, आवृत्ती आणि बॅकएंड तिकिटात लिहा।

दिशा आणि इंटरफेस जुळवा

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

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

नियमांच्या मालकांना एकमतात ठेवा

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

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

लॉकडाउन न गमावता दुरुस्ती तपासा

लागू स्थितीची तपासणी तिच्या मालक व्यवस्थापकासह करा, तुम्ही नोंदवलेल्या बॅकएंडशी जुळणाऱ्या आदेशांचा वापर करून। खालील यादी firewalld जबाबदार आहे असे गृहीत धरते; सर्व चालवण्याऐवजी nftables किंवा ufw साठी समतुल्य वापरा। एका सत्रात साधने मिसळणे म्हणजे यंत्र दोन परस्परविरोधी नियमसंचांसह राहते।

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

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

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