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