VPN मागील सेवेसाठी ufw allow 443 ने काहीही केले नाही

VPN क्लायंटवरून ping यशस्वी होतो, TCP सेवेची वेळ संपते, आणि ufw allow 443/tcp काहीही बदलत नाही। जेव्हा अनुप्रयोग गेटवेवर नसून गेटवेमागील होस्टवर चालतो, तेव्हा ती परवानगी चुकीच्या रहदारी मार्गासाठी लिहिलेली होती। पॅकेट फायरवॉलकडे पत्ता दिलेले नाही आणि स्थानिक प्रक्रियेकडे दिले जात नाही, म्हणून आंतर्गत नियम ते कधीही पाहत नाहीत। उपाय म्हणजे फॉरवर्ड होणाऱ्या प्रवाहाकडे लक्ष्य असलेला रूट नियम, आणि त्याचा पुरावा आधीच लॉगमध्ये आहे।

गंतव्य स्थानिक आहे की फॉरवर्ड, हे ठरवा

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

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

कोणताही नियम जोडण्यापूर्वी ब्लॉक वाचा

एक अधिकृत कनेक्शन प्रयत्न पुन्हा करा आणि गेटवेने नोंदवल्याप्रमाणे त्याचा स्रोत, गंतव्य, प्रोटोकॉल आणि गंतव्य पोर्ट नोंदवा। ती चार मूल्ये लॉग नोंदीशी आणि सेवेच्या प्रत्यक्ष स्थानाशी तुलना करा। पूर्वीचे यशस्वी ping फक्त त्याची स्वतःची देवघेव अनुमत होती हे सिद्ध करते, आणि फायरवॉल अनुप्रयोगाकडे जाणाऱ्या TCP SYN ला पूर्णपणे वेगळ्या पद्धतीने हाताळू शकतो।

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

बसणारा सर्वात अरुंद रूट नियम लिहा

या उदाहरणात क्लायंट 172.20.8.0/24 वरून tun0 वर येतात, सेवा 8443 पोर्टवर 10.30.0.15 वर ऐकते, आणि गेटवे ens5 मधून बाहेर पडतो। ही मूल्ये क्लाउड VPC च्या डीफॉल्ट 10.0.0.0/16 किंवा घरातील 192.168.0.0/16 सारखी मुळीच वाटू नयेत म्हणून निवडली आहेत, आणि 8443 उदाहरणाला गेटवेच्या स्वतःच्या 443 श्रोत्यापासून दूर ठेवते।

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

ड्राय रन तयार होणारा नियमसंच छापतो, आणि तुमचा नियम विद्यमान नकाराच्या आधी पडतो की नंतर हे पाहण्याचा हा सर्वात स्वस्त मार्ग आहे। इंटरफेस नावे आणि आतील पत्ते उदाहरणाशी नाही तर तैनातीशी जुळवून पहा, आणि लक्षात ठेवा की गंतव्य NAT आधी चालतो तेव्हा गाळणी भाषांतरित गंतव्य पाहते।

परतीचा मार्ग स्थितीसह ठेवा

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW तुमच्या वतीने काय लागू करू शकत नाही ते तपासा

योग्य नियमाला अजूनही कर्नेल फॉरवर्डिंग आणि सेवेपर्यंत पोहोचणारा रूट लागतो। फायरवॉलला दुसऱ्यांदा दोष देण्यापूर्वी दोन्हीची खात्री करा।

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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