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 या एडमिन पैनल फ़ॉरवर्ड करना सेवा प्रकाशित करने से कहीं बड़ा निर्णय है।