तपाईंको वेब सर्भरमा रहेको VPN क्लाइन्टले यसका जवाफहरू तोड्छ?

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

स्रोतमा आधारित रुट नियमले प्रायः लक्षण हटाउँछ। यसले सामान्यतया यसलाई जन्म दिने साइटभन्दा बढी ट्राफिकलाई पनि छुट दिन्छ, र नियम सुरक्षित गर्नुअघि बुझ्न लायक भाग त्यही हो।

लक्षण: यसले स्थानीय रूपमा जवाफ दिन्छ, बाहिरबाट होइन

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

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

काम गर्दा स्वतन्त्र प्रशासनिक बाटो खुला राख्नुहोस्। जुन नियमले तपाईंको आफ्नै SSH सत्र तोड्छ, त्यसले दस मिनेटको सुधारलाई भौतिक भ्रमणमा बदल्छ।

स्रोत चयनकर्ताले वास्तवमा केसँग मेल खान्छ

Linux नीति रुटिङमा, from 192.168.50.2 जस्तो नियम ती प्याकेटसँग मेल खान्छ जसको स्रोत त्यो ठेगाना हो। यसले प्याकेट घरायसी राउटरबाट भित्रिएको कुराकानीलाई निरन्तरता दिइरहेको तथ्यलाई कोड गर्दैन, र कुन प्रक्रियाले यो बनायो भन्ने जान्दैन। त्यो उदाहरणको ठेगाना उदाहरणात्मक हो; तपाईंको होस्टले वास्तवमा प्रयोग गर्ने ठेगानाले बदल्नुहोस्। लाइनलाई ठेगानाबारेको भनाईका रूपमा हेर्नुहोस् र त्यसभन्दा बढी केही होइन।

यदि चयन गरिएको तालिकाले सामान्य पूर्वनिर्धारित मार्ग दिन्छ भने, त्यो स्रोत बोक्ने प्रत्येक प्याकेटले त्यही छुट लिन सक्छ। त्यही ठेगानामा बाँधिएको अर्को सेवाले यो उत्तराधिकारमा पाउँछ, र त्यो ठेगानामा जानाजान बाँधिने अनुप्रयोगले पनि यो पाउँछ। नीति नियम सन्दर्भ ले स्रोत, गन्तव्य, प्रोटोकल, पोर्ट, चिन्ह र प्राथमिकतालाई अलग-अलग चयनकर्ताका रूपमा सूचीबद्ध गर्छ, जसले केवल स्रोत नै उपलब्ध सबैभन्दा मोटो विकल्प हो भन्ने सम्झाउँछ।

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

फर्कने बाटो र तपाईंले नसोचेको ट्राफिक जाँच्नुहोस्

नियम र तालिकाहरू पढ्नुहोस्, त्यसपछि कर्नेललाई सोध्नुहोस् कि कुनै विशिष्ट स्रोत र गन्तव्य जोडीले कुन मार्ग लिन्छ। होस्टबाटै परीक्षण गर्नु बाहिरबाट परीक्षण गर्नुसरह होइन, त्यसैले दुवै गर्नुहोस्।

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

ब्राउजरमा सार्वजनिक ठेगाना जाँचले त्यो ब्राउजरले गरेका अनुरोधहरूको मात्र जानकारी दिन्छ। यसले वेब सर्भरका जवाफ, अर्को स्थानीय अनुप्रयोगको स्रोत छनोट, वा अर्को VPN पुनःजडानपछि व्यवस्थापन ट्राफिकलाई के हुन्छ भन्नेबारे केही भन्दैन।

अपवाद कति साँघुरो हुन सक्छ निर्धारण गर्नुहोस्

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

तपाईं जुन सम्झौतामा भर पर्नुहुन्छ त्यो लेख्नुहोस्: सार्वजनिक म्यापिङ, अनुरोध पुर्‍याइने होस्ट ठेगाना, र जवाफले लिनुपर्ने मार्ग। VPN प्रदायकमार्फत प्रकाशित इनबाउन्ड सेवा घरायसी राउटरमार्फत प्रकाशित भन्दा फरक सम्झौता हो, र एउटा उदाहरणबाट प्रतिलिपि गरिएको अपवाद अर्कोका लागि प्रायः गलत हुन्छ।

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