VPN जोडिन्छ तर LAN यन्त्रहरूमा पुग्दैन: के जाँच गर्ने

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

अबदेखि गेटवेको अर्को छेउमा केही कुरा परीक्षण गर्नुहोस्। फर्वार्डिङ जतिसुकै बिग्रेको भए पनि गेटवेको आफ्नै ठेगानाले जवाफ दिइरहनेछ।

गेटवे आफ्नै स्ट्याकबाट जवाफ दिन्छ

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

सुरुङबाट पुगिने प्रशासन पृष्ठहरू पनि पहिलो श्रेणीमा पर्छन्। ती सुरुङबारे प्रमाण हुन्, त्यसको पछाडिको नेटवर्कबारे होइन।

प्रवाहलाई यसलाई छोड्ने पहिलो सीमासम्म पछ्याउनुहोस्

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

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

फर्कने मार्ग र होस्ट फायरवाल अलग-अलग असफल हुन्छन्

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

ग्राहकबाट पठाएर फर्काइ हेरेर फर्कने मार्ग जानाजान परीक्षण गर्नुहोस्। एकतर्फी क्याप्चरले एक घण्टाको अनुमानले नसुल्झाउने कुरा सेकेन्डमा सुल्झाउँछ।

ग्राहकको स्रोत ठेगानाले प्रत्येक हप पुष्टि गर्नुहोस्

जाँचहरू क्रममा चलाउनुहोस् र प्रत्येक आउटपुट राख्नुहोस्, किनकि मूल्य तुलनामा छ, कुनै एउटा लाइनमा होइन। तलका कमाण्डहरूले स्रोत ठेगाना स्थिर गर्छन्, छानिएको मार्ग देखाउँछन् र फर्वार्डिङका दुवै पक्ष क्याप्चर गर्छन्। आफ्नै LAN होस्ट र सुरुङ इन्टरफेस राख्नुहोस्।

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

कुन ठेगानाले जवाफ दियो र कुन फर्वार्ड गरिएको गन्तव्य असफल भयो भनी टिप्नुहोस्। त्यही वाक्यले प्रतिवेदनलाई सर्भर अगम्य छ भन्ने दाबीको सट्टा कार्ययोग्य बनाउँछ।