सर्भरको 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

टनेल आफैं बोक्ने पोर्टको कहिल्यै अनुवाद नगर्नुहोस्, किनकि त्यो पुनःलेखनले सेवा पुग्न सकिने राख्ने जडान तोड्छ। टनेल पोर्टलाई गन्तव्य नियमबाट पूर्ण रूपमा बाहिर राख्नुहोस्। अन्तमा दुवै छेउबाट प्रमाणित गर्नुहोस्: नयाँ नियममा काउन्टर, टनेल उपकरणमा छोटो क्याप्चर, र सार्वजनिक ठेगाना प्रयास गर्नु अघि टनेलभित्रको ठेगानामा एउटा अनुरोध।