eth0:0 एक लेबल है, डिवाइस नहीं: SNAT मैच ठीक करें

एक NAT नियम जिसे एक VPN क्लाइंट पूल को उसका अपना सार्वजनिक पता देना था, शून्य पैकेट पर बैठा है, जबकि वही पूल गलत स्रोत के साथ बाहर जाता रहता है। नियम आम तौर पर पते में गलती नहीं करता; वह इंटरफ़ेस में गलती करता है। -o eth0:0 ऐसे डिवाइस की ओर इशारा करता है जो मौजूद ही नहीं है, क्योंकि eth0:0 वह लेबल है जो पते से जुड़ा है, और उस पते का डिवाइस eth0 है। काउंटर देखना इसे पुष्ट करने का सबसे तेज़ तरीका है, और सुधार जाँच से जितना बड़ा लगता है उससे छोटा है।

देखें कि कर्नेल डिवाइस को क्या कहता है

कुछ भी बदलने से पहले दोनों दृश्य अलग-अलग पढ़ें:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

लिंक सूची इंटरफ़ेस दिखाती है। पता सूची दूसरा IPv4 पता दिखा सकती है जो लेबल रखता है eth0:0, और उस पते का डिवाइस अब भी eth0 है। iproute2 का पता नियमावली लेबल को पते का नाम मानती है, दूसरा लिंक नहीं, और पूरी समस्या इसी अंतर पर टिकी है।

इतिहास इस उलझन को समझाता है। पुराना ifconfig eth0:0 सिंटैक्स सचमुच नए इंटरफ़ेस जैसा दिखता था, और उस दौर की स्क्रिप्टें अब भी एक का ज़िक्र करती हैं। आज के सिस्टम में उपनाम किसी पते पर एक लेबल है, और रूटिंग या netfilter के रास्ते में कुछ भी उसे अलग निकास बिंदु नहीं मानता।

देखें कि नियम वास्तव में किससे मेल खाया

काउंटर नियम सूची के साथ पढ़ें, याद से नहीं:

iptables -t nat -L POSTROUTING -v -n --line-numbers

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

शर्त को असली डिवाइस पर बदलें और लेबल को उससे बाहर रखें। अगर आपको उस डिवाइस को साझा करने वाले दो क्लाइंट पूल अलग करने हों, तो उन्हें स्रोत उपसर्ग से अलग करें, ऐसे इंटरफ़ेस नाम से नहीं जो हो ही नहीं सकता। दो नियम जिनके -s मेल ओवरलैप नहीं करते, पढ़ने और परखने योग्य हैं; काल्पनिक डिवाइस वाला एक नियम न यह है न वह। हर नियम को टिप्पणी दें जो पूल का नाम बताए, क्योंकि छह महीने बाद उपसर्ग अकेले किसी को नहीं बताएगा कि वह वहाँ क्यों है।

उस रूट को देखें जिसने डिवाइस चुना

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

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

अनूदित स्रोत जानबूझकर चुनें

डिवाइस सही होने के बाद, स्रोत पता अलग फैसला है। यह सिर्फ़ एक उदाहरण IPv4 पूल और एक नमूना पता है:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

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

स्रोत पता बदलना अपलिंक बदलने के बराबर नहीं है। जब असली ज़रूरत अलग भौतिक मार्ग हो, तो रूटिंग नीति को पहले वह मार्ग चुनना होगा; फिर SNAT उसी डिवाइस पर स्रोत फिर से लिखता है जो नीति ने चुना। ज़्यादा लेबल eth0 पर जोड़ने से न मार्ग मिलता है न अधिकार।

उसी कनेक्शन से जाँचें जो आपने अभी खोला

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

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