VPN क्लाइन्ट जोडिएपछि वेब सर्भर गायब हुन्छ

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

लक्षण: अनुरोध भित्र, उत्तर गलत ढोकाबाट बाहिर

संकेत भनेको होस्टमा बाँकी सबै काम गरिरहेको बेला असफल हुने आगमन जडान हो। अर्को संकेत भनेको LAN बाट पुग्न सकिने तर इन्टरनेटबाट नपुग्ने होस्ट, वा टनेल फेरि जोडिनेसम्म चल्ने र त्यसपछि रोकिने होस्ट हो। प्रत्येक अवस्थामा अगाडिको दिशा चल्यो र फर्किने दिशा चलेन, जसले नीतिभन्दा राउटिङ असममितिलाई संकेत गर्छ।

उत्तर कहाँ जान्छ हेरेर यसको पुष्टि गर्नुहोस्, अनुरोध कसरी आउँछ हेरेर होइन।

भौतिक इन्टरफेस र टनेल यन्त्रमा एकैसाथ क्याप्चर गर्नुहोस्। यदि अनुरोध भौतिक इन्टरफेसमा देखियो र उत्तर टनेलमा देखियो भने निदान सकियो। कतै नदेखिने उत्तरको अर्थ सेवाले जडान कहिल्यै स्वीकार गरेन, जुन फरक कारणको फरक अनुसन्धान हो।

दुई पूर्वनिर्धारित मार्ग र एउटा राउटिङ निर्णय

पूर्वनिर्धारित मार्ग स्थापना गर्ने क्लाइन्टले LAN गेटवेभन्दा राम्रो मेट्रिकसहित दोस्रो प्रविष्टि थप्छ। केही क्लाइन्टले त्यसको सट्टा आधा-दायराका दुई मार्ग स्थापना गर्छन्, जसले त्यही ठाउँ अझ विशिष्ट रूपमा ढाक्छन् र त्यसै गरी खोज जित्छन्। दुवै प्रविधिले सामान्य बाहिर जाने प्याकेटलाई टनेल इन्टरफेस छान्न दिन्छन्।

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

टनेलले सधैं सही व्यवहार गर्छ। यसलाई पूर्वनिर्धारित मार्ग बोक्न भनिएको थियो र यसले ठ्याक्कै त्यही गर्छ।

टनेल नतोडी फर्किने मार्ग सुधार्नुहोस्

मर्मतका तीन टिकाउ रूप छन्, र छनोट होस्टको आफ्नै कति ट्राफिक टनेलभित्र रहनुपर्छ भन्नेमा निर्भर छ। सेवाको गन्तव्य वा पोर्ट बहिष्कृत गर्नु सबैभन्दा सानो परिवर्तन हो। स्रोत वा चिन्ह अनुसार नीति-राउटिङ सबैभन्दा सटीक हो। स्रोत अनुवाद सबैभन्दा मोटो र दुई वर्षपछि बुझाउन सबैभन्दा सजिलो हो।

होस्टले के गर्नुपर्छ भन्ने आधारमा छान्नुहोस्, तपाईंले पहिले कुन टुक्रा भेट्टाउनुभयो भन्नेमा होइन।

गन्तव्य बहिष्कृत गर्नु स्थिर सार्वजनिक ठेगाना भएको सेवाका लागि उपयुक्त हुन्छ, र डेमनलाई हरेक ठेगानामा होइन भौतिक ठेगानामा बाँध्नुले त्यो बहिष्करण अझ सुरक्षित बनाउँछ। स्रोत अनुसार तालिका छान्ने नीति नियमले होस्टका आफ्नै जडानहरू टनेलभित्र राख्छ र सेवाका उत्तरहरू WAN गेटवेबाट फर्काउँछ। WAN इन्टरफेसमा उत्तरहरू मास्क गर्नुले त्यही मार्गमा पुग्छ, तर सेवाका लगबाट क्लाइन्टको ठेगाना लुकाउने मूल्यमा। पूर्वनिर्धारित मार्गको तत्काल परिवर्तन निदान हो, कन्फिगरेसन होइन, किनकि क्लाइन्टले हरेक पुनःजडानमा मार्गहरू फेरि लेख्छ।

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

जब होस्टले आफ्नो पछाडिको LAN का लागि पनि राउट गर्छ

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

दुई परिवर्तनले त्यो सुधार्छ: आगमन जडान आन्तरिक यन्त्रसम्म पुग्न गन्तव्य अनुवाद, र त्यो यन्त्रको उत्तर राउटरबाटै आएको जस्तो देखिन स्रोत अनुवाद।

राउटर फर्मवेयरमा सामान्य अभिव्यक्ति भनेको पोर्ट-फर्वार्डिङलाई WAN तर्फ पिन गर्ने नीति नियम हो, जबकि राउटरको आफ्नै ट्राफिक टनेलमा चल्छ। स्रोत अनुवाद बिना त्यो उत्तर बाह्य क्लाइन्टलाई सम्बोधित छ र आन्तरिक यन्त्रसँग त्यहाँ पुग्ने कुनै मार्ग छैन। तीन कुरा अलग-अलग परीक्षण गर्नुहोस्, किनकि ती फरक कारणले असफल हुन्छन्: बाहिरबाट आउने जडान, होस्ट आफैंले सुरु गर्ने जडान, र नामको खोजी।