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 बद्दल काहीही सांगत नाही, म्हणून नियमासोबत त्याच टीपेत दोन्ही कुटुंबांसाठी हेतू असलेली व्याप्ती नमूद करा। उद्दिष्ट सुसंगत व्यवस्थापित धोरण आहे, आणि योगायोगाने पार्स झालेला तुकडा त्याचा पुरावा नाही।