सर्वर का IP बदलने के बाद भी SNAT नियम पुराने पते का ही ज़िक्र करता है

सर्वर नए पते पर चला गया, क्लाइंट अब भी जुड़ते हैं, और वे जो भेजते हैं उसमें से कुछ भी इंटरनेट तक नहीं पहुँचता। यही विभाजन सुराग है: सुनने वाला सॉकेट और पोर्ट फ़ॉरवर्डिंग स्थानांतरण में टिक गए, इसलिए टनल ऊपर आती है, जबकि फ़ॉरवर्ड किए गए पैकेट पर लागू स्रोत अनुवाद अब भी ऐसे पते का ज़िक्र करता है जो होस्ट के पास अब नहीं है। उन फिर से लिखे गए पैकेट के उत्तर ऐसी मशीन पर जाते हैं जो अब वहाँ नहीं है।

जुड़ना और फ़ॉरवर्डिंग अलग-अलग जगहों पर विफल होते हैं

स्थापना उस अंतिम बिंदु पर निर्भर करती है जिसे क्लाइंट पहले से जानते हैं: सार्वजनिक पता, उसके सामने की पोर्ट फ़ॉरवर्डिंग और अंदर का श्रोता। फ़ॉरवर्ड किया गया ट्रैफ़िक दूसरे निर्णय पर निर्भर करता है जो पैकेट के टनल में प्रवेश करने के बाद लिया जाता है, जब होस्ट अपना स्रोत फिर से लिखता है ताकि उत्तर वापसी का रास्ता पा सकें।

पता बदलने से केवल दूसरा निर्णय टूटता है, और इसीलिए लक्षण "जुड़ा है पर इंटरनेट नहीं" के रूप में पढ़ा जाता है। यह यह भी समझाता है कि क्लाइंट पक्ष की सामान्य जाँचें स्वस्थ क्यों दिखती हैं: हैंडशेक पूरा होता है, क्लाइंट को पता मिलता है, और सर्वर के टनल पते पर ping भी उत्तर दे सकता है। दूसरी तरफ़ रहने वाली खराबी के लिए क्लाइंट पर घंटे बर्बाद होते हैं, इसलिए नियमों की तालिका पहली देखने की जगह है।

संपादन से पहले नियम और उसके काउंटर पढ़ें

काउंटरों के साथ अनुवाद नियमों की सूची बनाएँ और कॉन्फ़िगर किए गए स्रोत की तुलना उन पतों से करें जो होस्ट के पास वास्तव में हैं। मृत पते पर फिर से लिखा गया नियम आम तौर पर अंदर जाने वाले रास्ते पर ट्रैफ़िक दिखाता है, क्योंकि पैकेट उस तक पहुँचते हैं और अनूदित होते हैं, और वापसी के रास्ते पर कुछ नहीं।

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

वहाँ रहते हुए तीन फ़ील्ड जाँचें: स्रोत मिलान में पूल, नियम के किसी इंटरफ़ेस का नाम लेने पर एग्ज़िट इंटरफ़ेस, और वह अपवर्जन जो टनल-से-टनल ट्रैफ़िक को फिर से लिखे जाने से रोकता है। संपादन के दौरान वह अपवर्जन खोना आसान है, और उसे खोने से साथी ट्रैफ़िक काम करता दिखता है जबकि उसके उत्तर अजीब रास्ता लेते हैं।

अगर काउंटर शून्य पर अटके हैं, तो पैकेट कभी इस नियम तक नहीं पहुँचते और पता मौजूदा समस्या नहीं है। श्रृंखला में पहले का कोई प्रतिस्पर्धी नियम खोजें, जो तब होता है जब कोई मूल को संपादित करने के बजाय प्रतिस्थापन जोड़ देता है। नियम संख्याओं की तुलना एक मिनट पहले लिखे गए आउटपुट से करें। क्रम कॉन्फ़िगरेशन का हिस्सा है, सजावटी ब्यौरा नहीं।

स्रोत बदलें, या उसका नाम लेना बंद करें

जब होस्ट के पास स्थिर पता हो, तो दूसरा जोड़ने के बजाय नियम को उसकी जगह बदलें। नियम संख्या से बदलना वह क्रम बनाए रखता है जिस पर श्रृंखला का बाकी हिस्सा निर्भर है।

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

जब पता गतिशील रूप से दिया जाता है, तो किसी स्रोत का नाम न लें और कर्नेल को एग्ज़िट इंटरफ़ेस से मौजूदा चुनने दें। यह रूप अगले स्थानांतरण में बिना संपादन के टिक जाता है, इस कीमत पर कि कौन-सा पता इस्तेमाल हुआ वह छिपा रहता है।

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

पुष्टि करें कि IPv4 फ़ॉरवर्डिंग प्रबंधित कॉन्फ़िगरेशन के ज़रिए अब भी सक्षम है, फिर वितरण की अपनी व्यवस्था से नियम को स्थायी बनाएँ। केवल चल रहे कर्नेल में किया गया बदलाव अगले रीबूट के साथ लौट आता है, आम तौर पर ऐसी रखरखाव खिड़की में जिसे कोई बदलाव से नहीं जोड़ता।

प्रतिस्थापन गलत करने के दो तरीके

पूल का अनुवाद सर्वर के LAN पते के बजाय उसके टनल पते पर करने से उत्तर सीधे टनल में वापस चले जाते हैं, जहाँ वे ऐसे क्लाइंट की ओर रूट होते हैं जिसने उन्हें कभी माँगा ही नहीं। कनेक्शन रूटिंग लूप जैसे तरीके से अटक जाता है, क्योंकि वह वास्तव में लूप है।

पुराने के ऊपर दूसरा अनुवाद चढ़ाना दूसरी गलती है। पहला मेल खाने वाला नियम जीतता है, इसलिए पुरानी प्रविष्टि हटाए जाने तक पैकेट संभालती रहती है, और नए नियम के काउंटर शून्य पर रहते हैं जबकि सब प्रतिस्थापन को दोष देते हैं। कुछ नया जोड़ने से पहले डुप्लिकेट मिटाएँ। फिर सूची एक बार और पढ़ें और पुष्टि करें कि पूल से ठीक एक ही अनुवाद मेल खाता है।

अगर टनल IPv6 भी ढोती है, तो पूरी समीक्षा दूसरे स्टैक पर दोहराएँ। अनुवाद और रूट किए गए प्रीफ़िक्स के बिना IPv6 डिफ़ॉल्ट रूट उतनी ही चुपचाप विफल होता है, और इसे भूलना आसान है क्योंकि उसके ऊपर का सब कुछ एक जैसा दिखता है।

इनबाउंड सेवाओं को उल्टा अनुवाद चाहिए

VPN क्लाइंट पर ऐसी सेवा जो बाहर से पहुँचने योग्य होनी चाहिए, उसे गंतव्य अनुवाद चाहिए, स्रोत अनुवाद नहीं: सार्वजनिक पोर्ट प्रवेश से पहले क्लाइंट के टनल पते पर फिर से लिखा जाता है। फिर फ़ॉरवर्ड पथ को उस ट्रैफ़िक की अनुमति देने वाला स्पष्ट नियम चाहिए।

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

उस पोर्ट का कभी अनुवाद न करें जो खुद टनल ढोता है, क्योंकि वह फिर से लिखना उस कनेक्शन को बाधित करता है जो सेवा को पहुँचने योग्य रखता है। टनल पोर्ट को गंतव्य नियमों से पूरी तरह बाहर रखें। अंत में दोनों सिरों से जाँचें: नए नियम पर काउंटर, टनल डिवाइस पर एक छोटा कैप्चर, और सार्वजनिक पते को आज़माने से पहले टनल के अंदर के पते पर एक अनुरोध।