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 वा प्रशासन प्यानल फर्वार्ड गर्नु सेवा प्रकाशित गर्नुभन्दा धेरै ठूलो निर्णय हो।