टनेल चालु छ, इन्टरनेट छैन: फर्वार्डिङ कहाँ रोकिन्छ

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

इन्टरनेट निकास कहिल्यै डिजाइन थियो कि भएन पुष्टि गर्नुहोस्

स्प्लिट-टनेल प्रोफाइलले केवल सुरक्षित सबनेटलाई 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 को होइन।

सूक्ष्म सुधारपछि क्लाइन्ट र जानाजान सीमित कुनै पनि निजी स्रोत फेरि जाँच्नुहोस्। इन्टरनेट पहुँच दिँदा गेटवेसँग जोडिएको हरेक नेटवर्कमा पहुँच चुपचाप बढाउनु हुँदैन।