UFW को before.rules मा VPN NAT कहाँ जान्छ र यसलाई कसरी परीक्षण गर्ने

शेलमा टाइप गर्दा काम गर्ने NAT नियम before.rules मा टाँस्दा असफल हुन्छ, किनकि त्यो फाइल स्क्रिप्ट होइन। त्यो तालिका खण्ड, चेन घोषणा र प्रत्येक तालिकाका लागि COMMIT चिन्ह भएको रिस्टोर-ढाँचाको कागजात हो। गलत ठाउँमा रहेको लाइनले या त सम्पूर्ण रिस्टोर रोक्छ या तपाईंले भएको ठानेका नियमहरू चुपचाप फ्याँक्छ। तलको रनबुकले टुक्रालाई फ्रेमवर्कले अपेक्षा गर्ने ठाउँमा राख्छ र अर्को रिलोड अघि नतिजा प्रमाणित गर्छ।

शेल आदेश रिस्टोर फाइल होइन

iptables -t nat बाट सुरु हुने लाइन iptables बाइनरीका लागि निर्देश हो, जबकि UFW ले पढ्ने फाइल पूर्ण नियमसेटको विवरण हो। फरक देखावटी होइन: रिस्टोर ढाँचाले कुन तालिकामा छ, कुन चेन अवस्थित छन् र तालिका कहाँ अन्त्य हुन्छ भन्ने जान्नुपर्छ। त्यो कागजातमा टाँसिएको आदेश या त सिन्ट्याक्स त्रुटि हो या, अझ नराम्रो, गलत तालिकामा जोडिएको नियम। फ्रेमवर्कले यी फाइलहरू रिस्टोर उपकरणमार्फत लोड गर्नुको कारण तिनीहरू क्रमिक नभई घोषणात्मक हुनु हो।

कागजात पूरै पनि लोड हुन्छ, त्यसैले एउटा त्रुटिपूर्ण खण्डले बाँकी फाइल लागू हुनबाट रोक्न सक्छ। त्यसैले NAT टुक्रामा सानो गल्तीले फिल्टर नियमहरूलाई पनि सँगै तल ल्याउँछ, र यसरी फायरवाल परिवर्तन अवरोध बन्छ।

टुक्रालाई विद्यमान तालिका खण्डभित्र राख्नुहोस्

NAT टुक्राको एउटा आकार हुन्छ, र आकार भित्रको नियम पाठभन्दा महत्त्वपूर्ण हुन्छ। तालिका शीर्षले खण्ड खोल्छ, चेन घोषणाले काउन्टर स्थापना गर्छ, नियमहरू त्यसपछि आउँछन्, र COMMIT ले खण्ड बन्द गर्छ।

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

माथिको पूल र इन्टरफेस तपाईंका मानहरूका लागि प्लेसहोल्डर हुन्; प्रतिलिपि गर्न लायक भाग संरचना हो। फाइलमा पहिले नै *nat खण्ड छ भने, दोस्रो खोल्नुको सट्टा त्यही खण्डभित्र नियम थप्नुहोस्, किनकि ढाँचाले प्रत्येक तालिकाका लागि एक COMMIT अपेक्षा गर्छ र एउटै तालिकाका लागि दुई खण्ड हुनु भविष्यमा हुने मर्मत हो। वितरणका चेन परिभाषाहरू अक्षुण्ण राख्नुहोस्, विक्रेताले आफ्नै एकीकरणका लागि थपेका सहित। UFW फ्रेमवर्क म्यानुअल ले before, user र after फाइलहरू तथा मिल्ने COMMIT को आवश्यकता अभिलेख गर्छ।

फाइल खाली भेटियो भने, यसलाई कुनै ट्युटोरियलबाट नभर्नुहोस्। कुन प्याकेज यसको मालिक हो र वास्तविक सक्रिय नीति के हो भनी पुष्टि गर्नुहोस्, किनकि खाली स्थायी फाइलले कर्नेलमा कुनै नियम छैन भनी प्रमाणित गर्दैन, र लोड गरिएको नियमसेटले अर्को रिलोडमा पढ्न पूर्ण फाइल हुन्छ भनी प्रमाणित गर्दैन। पहिले समर्थित आधाररेखा पुनर्स्थापित गर्नुहोस्, त्यसपछि साइट परिवर्तनहरू त्यसमाथि पुनः लागू गर्नुहोस्।

उम्मेदवारलाई नलागू गरी परीक्षण गर्नुहोस्

रिस्टोर उपकरणले नियमसेट नलागू गरी पार्स र निर्माण गर्न सक्छ, जो उपलब्ध सबैभन्दा सस्तो परीक्षण हो। यसलाई सक्रिय फाइलमा नभई सुरक्षित प्रतिमा चलाउनुहोस्, र केवल एक्जिट स्थिति नभई त्रुटि पाठ पढ्नुहोस्। पार्स असफलताले लाइन र सामान्यतया तालिकाको नाम दिन्छ, जो असफल रिलोडले भन्नेभन्दा बढी हो।

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

त्यो जाँच पास गर्नुले कागजात पार्स हुन्छ भन्ने मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन। उम्मेदवारमा UFW निर्भर प्रत्येक चेन अझै छ, यसले तपाईंले इच्छाएका स्रोतलाई मात्र अनुमति दिन्छ, वा दूरस्थ प्रशासन पहुँचयोग्य रहन्छ भनी यसले प्रमाणित गर्दैन। यी छुट्टाछुट्टै समीक्षा हुन्, र अन्तिमले सुरु गर्नुअघि खोलिने दोस्रो सत्रको योग्यता राख्छ।

स्थापित ब्याकएन्ड र ठेगाना परिवारसँग मिल्ने उपकरण छान्नुहोस्। अनुकूलता तहमार्फत nft ब्याकएन्ड चलाउने होस्टलाई सम्बन्धित आदेश चाहिन्छ, र IPv6 नियमहरू पूर्ण रूपमा अर्कै फाइलमा बस्छन्।

फर्वार्डिङ, NAT र पहुँच नीति अलग राख्नुहोस्

स्रोत अनुवादले ठेगाना समस्या समाधान गर्छ र केही दिँदैन। फर्वार्डिङ sysctl र फिल्टर तालिकाले नियन्त्रण गर्ने छुट्टै अनुमति हो, र टनेलले मार्ग बनाउँछ तर ट्राफिक पार गर्दैन भने मानिसहरूले यही बिर्सन्छन्। पहुँच नीति कुन स्रोतले कुन सेवासम्म पुग्न सक्छन् भन्ने तेस्रो निर्णय हो, र कुनै NAT नियमले त्यो व्यक्त गर्दैन। यी तीनलाई अलग राख्नुले नै असफलतालाई एक अस्पष्ट लक्षणको सट्टा निदानयोग्य बनाउँछ।

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

ती तीन आउटपुट एकैसाथ पढ्नुहोस्, एक-एक गरी होइन। फर्वार्डिङ बन्द भएको masquerade नियमले जोडिने तर कतै नपुग्ने क्लाइन्ट बनाउँछ, जो क्लाइन्टको तर्फबाट ठ्याक्कै मार्ग त्रुटिजस्तो देखिन्छ र मानिसहरूलाई गलत फाइलतिर पठाउँछ। फिल्टर तालिका पनि धेरै फराकिलो accept लुकेर बस्ने ठाउँ हो, त्यसैले त्यहाँ हुँदा यसको पूर्वनिर्धारित नीति जाँच्नुहोस्।

रिलोड, अस्वीकार र VPN हानि प्रमाणित गर्नुहोस्

तीन अवलोकनले पूर्ण स्वीकृति परीक्षण बनाउँछन्: रिलोड सफल हुन्छ, अनुमति दिइएको क्लाइन्ट कार्य सञ्चालन हुन्छ, र अस्वीकार गर्नुपर्ने अनुरोध वास्तवमै अस्वीकार हुन्छ। तेस्रो त्यही हो जो छोडिन्छ, र नीतिले केही गरिरहेको छ भन्ने एकमात्र प्रमाण त्यही हो।

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

त्यसपछि तपाईंले डिजाइन गरेको असफलता परीक्षण गर्नुहोस्। टनेल खसाल्नुहोस् र होस्टले के गर्छ हेर्नुहोस्, किनकि VPN खुला रहेसम्म मात्र काम गर्ने नीति नभनिएको निर्भरतासहितको नीति हो। त्यसपछि अझै एक पटक रिलोड गर्नुहोस्, काम गर्ने नतिजा बाँकी चलिरहेको अवस्थाले होइन फाइलले दिन्छ भनी प्रमाणित गर्न।

IPv4 को NAT ले IPv6 बारे केही भन्दैन, त्यसैले नियमसँगै त्यही टिप्पणीमा दुवै परिवारका लागि इच्छित कभरेज उल्लेख गर्नुहोस्। लक्ष्य सुसंगत व्यवस्थापित नीति हो, र संयोगवश पार्स भएको टुक्रा त्यसको प्रमाण होइन।