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 बंद करना एक ही आदेश में लक्षण हटाता है और प्रमाण नष्ट करता है, इसलिए यह पहला नहीं बल्कि अंतिम प्रयोग होना चाहिए।