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 के बारे में कुछ नहीं कहता, इसलिए नियम के साथ उसी नोट में दोनों परिवारों के लिए इच्छित कवरेज बताएँ। लक्ष्य एक सुसंगत प्रबंधित नीति है, और संयोग से पार्स हुआ टुकड़ा उसका प्रमाण नहीं है।