CGNAT मागून VPN क्लायंट पोर्ट प्रकाशित करा: तपासणी यादी

सेवा ऑपरेटर-स्तरीय NAT मागील लॅपटॉपवर ठेवा, तो लॅपटॉप VPN द्वारे VPS कडे वळवा, आणि बाहेरचा कोणीही त्याच्यापर्यंत पोहोचू शकत नाही। तुम्ही VPS वर डेस्टिनेशन NAT नियम जोडता आणि शांततेपेक्षाही वाईट काही मिळवता: कनेक्शन उघडतात, मग अडकतात। प्रतिसाद गहाळ नाही, तो क्लायंटच्या स्वतःच्या डीफॉल्ट मार्गाने बाहेर पडत आहे, म्हणजे सर्व्हर तो कधीही पाहत नाही। हे पाच तपासणे क्रमाने करा आणि पहिल्या अयशस्वी तपासणीवर थांबा।

सर्व्हर अजिबात फॉरवर्ड करेल याची खात्री करा

एकही भाषांतर लिहिण्यापूर्वी हा चौकोन टिक करा। कर्नेल फॉरवर्ड करण्यास नकार देणाऱ्या पॅकेटसाठीचा DNAT नियम नियम पार्सर स्वीकारतो आणि नंतर फॉरवर्ड मार्ग तो टाकून देतो, ज्यामुळे फायरवॉल समस्येसारखा वाटणारा टाइमआउट तयार होतो।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

चालू कर्नेलमध्ये तो सेट करणे हे रीबूटमधून सेट करण्यासारखे नाही। net.ipv4.ip_forward=1 /etc/sysctl.d/ खालील फाइलमध्ये लिहा, sysctl --system चालवा, आणि नंतर फाइल उचलली गेली यावर विश्वास ठेवण्याऐवजी मूल्य पुन्हा वाचा। स्वतःचे नेटवर्क नेमस्पेस सांभाळणाऱ्या कंटेनरला त्या नेमस्पेसच्या आतही तेच मूल्य लागते, केवळ होस्टवर नाही।

पुन्हा वाचल्यावरही शून्य असेल, तर इथेच थांबा। खालील काहीही चालणार नाही।

कोणताही नियम त्याचा उल्लेख करण्यापूर्वी टनलचा पत्ता स्थिर करा

पूल कनेक्शनच्या क्रमाने पत्ते वाटतो, त्यामुळे आजच्या लीजसाठी लिहिलेला नियम पुढील आठवड्यात शांतपणे दुसऱ्या क्लायंटकडे निर्देश करू शकतो। पत्ता आगमनाच्या क्रमाशी नाही, तर प्रमाणपत्राच्या ओळखीशी बांधा।

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

ती जोडी पॉइंट-टू-पॉइंट टनलचे क्लायंट टोक आणि पीअर टोक आहे, सर्व्हर प्रमाणपत्राच्या सामान्य नावाशी जोडलेला आहे। सबनेट टोपोलॉजीमध्ये दुसरे मूल्य त्याऐवजी नेटमास्क म्हणून वाचले जाते, म्हणून वापरात असलेल्या टोपोलॉजीशी जुळणारे स्वरूप लिहा। नंतर क्लायंट पुन्हा जोडा आणि पत्ता क्लायंटवरच वाचा, कारण पूलबद्दल सर्व्हरची दृष्टी क्लायंटने काय कॉन्फिगर केले याचा पुरावा नाही।

पुन्हा जोडल्यानंतर पत्ता बदलत असेल, तर थांबा। हलत्या लक्ष्याचा पाठलाग करणारा NAT नियम अधूनमधून अयशस्वी होईल आणि तुम्हाला काहीही शिकवणार नाही।

दोन्ही दिशांनी भाषांतर करा

डेस्टिनेशन भाषांतर येणारे पॅकेट क्लायंटकडे पाठवते। स्रोत भाषांतरच क्लायंटला मूळ प्रेषकाकडे नव्हे, तर सर्व्हरला उत्तर देण्यास भाग पाडते, आणि तोच नियम लोक विसरतात।

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

दुसऱ्या नियमाशिवाय क्लायंट आपल्या ISP अपलिंकमधून उत्तर देतो, त्यामुळे दूरचा पीअर असा स्रोत पत्ता पाहतो ज्याच्याशी त्याने कधीही बोलले नाही, तर सर्व्हरकडे प्रतिसादासाठी कोणतीही ट्रॅकिंग नोंद नसते। बाहेरचा निरीक्षक अर्धा पूर्ण होणारा हस्तांदोलन पाहतो, आणि तेच ते लक्षण आहे जे लोकांना नसलेल्या फायरवॉल बगच्या शोधात पाठवते।

दोन्ही नियम iptables -t nat -S ने पुन्हा वाचा आणि इंटरफेसचे नाव सार्वजनिक पत्ता वाहणारे आहे याची खात्री करा। आधीच nftables ने फिल्टर करणाऱ्या होस्टवर साधने मिसळण्याऐवजी जुळणाऱ्या पत्ता कुटुंबाच्या nftables NAT साखळीत भाषांतर लिहा।

फिल्टर तक्त्याला जाऊ द्या

NAT तक्ते शीर्षके पुन्हा लिहितात; ते परवानगी देत नाहीत। डीफॉल्ट DROP धोरणासह फॉरवर्ड होणाऱ्या प्रवाहाला स्वतःची परवानगी लागते, शिवाय परतीची दिशा जी बहुतेक धोरणे आधीच established,related नियमाने झाकतात।

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

काहीही जोडण्यापूर्वी FORWARD साखळीचे धोरण तपासा, कारण लवकर येणाऱ्या DROP चा क्रम तुमचा नियम कधी पाहिला जाईल हे ठरवतो। ज्या होस्टचे फिल्टरिंग nftables मध्ये राहते, तिथे inet तक्त्याच्या forward हुकमध्ये समतुल्य नियम जोडा आणि मूळ साखळी केवळ स्थानिक इनपुट नव्हे, तर खरोखर फॉरवर्ड होणारा रहदारी पाहते याची खात्री करा। नवीन नियमावरील पॅकेट काउंटर शून्यावर राहिला आणि NAT काउंटर वाढले, तर पॅकेट तुमच्या नियमापूर्वीच टाकला जात आहे। हा साखळ्यांचा क्रम वाचण्याचा संकेत आहे, तोच नियम दुसऱ्यांदा जोडण्याचा नाही।

बाहेरील नेटवर्कवरून ते सिद्ध करा

असंबंधित नेटवर्कवरून चाचणी करा। त्याच LAN वरील दुसऱ्या मशीनवरून केलेली तपासणी hairpin NAT आधारातून जाऊ शकते आणि दूरचा क्लायंट वापरतो त्या मार्गाचा कधीही सराव करत नाही, त्यामुळे तिथले हिरवे निकाल चुकीची गोष्ट सिद्ध करते।

tcpdump -ni any port 29443
conntrack -L | grep 29443

सर्व्हरवर आणि क्लायंटवर एकाच वेळी कॅप्चर चालवा। सर्व्हरचे कॅप्चर भाषांतरित पॅकेट टनलकडे निघते का हे दाखवते; क्लायंटचे कॅप्चर विनंती पोहोचते का आणि प्रतिसाद कुठे संबोधित आहे हे दाखवते। conntrack -L मधील भाषांतर नोंद नियम जुळला हे सिद्ध करते, आणि तिची अनुपस्थिती पॅकेट कधीच NAT साखळीपर्यंत पोहोचले नाही हे सिद्ध करते।

पोर्ट स्कॅनर कमकुवत पुरावा आहेत। अनुप्रयोग बांधला गेला आणि ऐकत नाही तोपर्यंत ते पोर्ट बंद असल्याचे नोंदवतात, म्हणून खऱ्या सेवेसाठी खरे कनेक्शन वापरा। शेवटी चालले की, उघडपणा त्या एकाच पोर्टवर ठेवा: पहिला नियम अवघड वाटला म्हणून SSH किंवा प्रशासन पॅनेल फॉरवर्ड करणे हे सेवा प्रकाशित करण्यापेक्षा खूप मोठे निर्णय आहे।