टनल चालू है, इंटरनेट नहीं: फ़ॉरवर्डिंग कहाँ रुकती है

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

पुष्टि करें कि इंटरनेट निकास कभी डिज़ाइन था या नहीं

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

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

एक सार्वजनिक अनुरोध को गुज़ारें

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

अगर गेटवे पैकेट कभी नहीं देखता, तो क्लाइंट रूट या टनल चयन गलत है। अगर पैकेट आकर नहीं निकलता, तो समस्या गेटवे पर है, और शेष तीन जाँचें लागू होती हैं।

फ़ॉरवर्डिंग, रूट और अनुवाद जाँचें

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

असममित सेटअप में रिवर्स-पथ फ़िल्टरिंग भी वैध पैकेट गिरा सकती है। उस नियम का काउंटर पढ़ें, यह मानने के बजाय कि सब ठीक है, क्योंकि सार्वजनिक इंटरफ़ेस पर सख़्त सेटिंग उस ट्रैफ़िक को अस्वीकार करती है जो रूट तालिका के अनुमान से अलग पथ से आता है।

उत्तर पथ और रिज़ॉल्वर दो अलग उत्तर हैं

सिर्फ़ अनुरोध नहीं, उत्तर पर भी नज़र रखें। अगर अनुरोध अनुवादित होकर निकलता है और उत्तर अनुवादित प्रवाह में लौटता है, तो फ़ॉरवर्डिंग तब भी काम करती है जब ऐप अब भी विफल हो, और अगली जाँच ऐप या DNS की है।

जो साइट HTTP त्रुटि लौटाती है वह प्रमाण है कि इंटरनेट पर फ़ॉरवर्डिंग काम करती है। ऐसा नाम जो हल न हो जबकि पते से पहुँच काम करे, रिज़ॉल्वर की समस्या है, NAT की नहीं।

सटीक सुधार के बाद क्लाइंट और किसी भी जानबूझकर सीमित निजी संसाधन को फिर से जाँचें। इंटरनेट पहुँच देना गेटवे से जुड़े हर नेटवर्क तक पहुँच चुपचाप नहीं बढ़ानी चाहिए।