चालु VPN हुँदा पनि जवाफमा समय सकिने किन हुन्छ
कुनै अनुरोध निजी सर्भरसम्म पुग्नु भनेको आदानप्रदानको आधा मात्र हो। त्यसको जवाफले इच्छित गेटवे, मार्ग वा अनुवादबाट टनेल क्लाइन्ट भेट्नुपर्छ।
अनुरोध आउँछ, सर्भरले त्यसलाई लग गर्छ, र क्लाइन्टले अझै समय सकिएको रिपोर्ट गर्छ। यो संयोजनको अर्थ हुन्छ जवाफले फर्कने बाटो भेटेन, र यो ती थोरै खराबीमध्ये एक हो जुन तपाईंले दुवै छेउबाट एकैचोटि पुष्टि गर्न सक्नुहुन्छ। जाँचहरू क्रममा गर्नुहोस् र कुनै एक असफल भएपछि रोक्नुहोस्।
अनुरोध कहाँ आयो त्यहीँबाट सुरु गर्नुहोस्
अरू केही जाँच्नुअघि प्याकेट सेवासम्म पुगेको पुष्टि गर्नुहोस्। सर्भरतर्फको लग प्रविष्टि, जडान गणना वा टाढाको छेउमा अनुमति दिइएको क्याप्चर—सबैले एउटै प्रश्नको जवाफ दिन्छन्, र तिनीहरू नहुँदा तपाईंलाई जवाफतर्फ नभई टनेलतर्फ फर्काउँछ। यही त्यो जाँच हो जसले फर्वार्डिङको समस्यालाई फर्कने मार्गको समस्याबाट अलग गर्छ।
अनुरोध कहिल्यै आएन भने यहीँ रोक्नुहोस्। टनेल, निजी प्रिफिक्ससम्मको राउटिङ वा पहुँच नियम विषय हो, र जवाफको मार्ग अझै सान्दर्भिक छैन। सर्भरले देखेको स्रोत ठेगाना पनि लेख्नुहोस्। त्यो या त क्लाइन्टलाई दिइएको पूल ठेगाना हो या अनुवादित ठेगाना, र यही भिन्नताले अबका कुन जाँच लागू हुन्छ निर्धारण गर्छ।
जवाफलाई पूलसम्मको मार्ग चाहिन्छ
रिमोट-पहुँच क्लाइन्टले सामान्यतया पूलबाट ठेगाना पाउँछ, र निजी सञ्जाललाई त्यो पूलसम्म फर्कने मार्ग चाहिन्छ। जसको पूर्वनिर्धारित मार्ग आफ्नै गेटवेतर्फ देखाउँछ त्यस्तो सर्भरले प्याकेट त्यही गेटवेलाई दिन्छ, जसलाई पूल कहाँ छ भन्ने कुनै जानकारी हुँदैन, त्यसैले जवाफ त्यहीँ मर्छ। केही पनि फर्किएन भनेर क्लाइन्टले समय सकिएको देख्छ, र यसलाई कहिल्यै ननिस्केको अनुरोधबाट छुट्याउन सकिँदैन।
सर्भरले आफ्नै सबनेटका लागि प्रयोग गर्ने मार्ग होइन, क्लाइन्ट ठेगानाका लागि छान्ने मार्ग जाँच्नुहोस्। यी दुई खोजले फरक जवाफ दिन सक्छन्, र यहाँ दोस्रो नै महत्त्वपूर्ण छ। अनुवाद वैकल्पिक संरचना हो र यसले सर्भरले देख्ने कुरा बदल्छ। यसले फर्कने मार्ग सरल बनाउन सक्छ, र सर्भरका लगबाट मूल क्लाइन्ट ठेगाना पनि हटाउँछ, जसले त्यो क्षेत्रमा बनेको कुनै पनि नियम वा प्रतिवेदनलाई असर गर्छ।
सर्भर क्याप्चरको तुलना गेटवे क्याप्चरसँग गर्नुहोस्
सर्भरबाट जे निस्कन्छ त्यसको तुलना गेटवेमा जे पुग्छ त्यससँग गर्नुहोस्। सर्भरको आउटबाउन्ड इन्टरफेसमा गरिएको क्याप्चर र टनेल गेटवेमा गरिएको क्याप्चर प्रश्नका फरक आधा भागको जवाफ दिन्छन्, र तिनका बीचको अन्तरले हानिको स्थान देखाउँछ।
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
गेटवे आफैँले बनाएको अनुरोध क्लाइन्ट परीक्षणको कमजोर विकल्प हो, किनभने त्यो अर्को ठेगानाबाट आउँछ र अर्का नियमसँग भेट्छ। त्यसैले गेटवेबाट सफल ping र क्लाइन्टबाट असफल अनुरोध दुवै एकैचोटि सत्य हुन सक्छन्।
मार्गमा धेरै राउटर छन् भने पूलसम्म मार्ग चाहिने प्रत्येकलाई जाँच्नुहोस्। साइट-देखि-साइट संरचनामा टाढाको प्रिफिक्स एकभन्दा बढी यन्त्रमा थाहा हुनु आवश्यक हुन्छ, र गेटवे आफैँले टनेल र LAN बीच फर्वार्ड गर्नुपर्छ; strongSwan का फर्वार्डिङसम्बन्धी टिप्पणी ले यसको sysctl र फायरवाल पक्ष समेट्छन्।
पूल, प्रिफिक्स र जिम्मेवार व्यक्ति लेख्नुहोस्
टिप्पणीमा चार तथ्य पर्छन्: क्लाइन्टले पाएको पूल, उसलाई आवश्यक निजी प्रिफिक्स, जवाफको जिम्मेवार राउटर, र भएमा अनुवाद नियम। यिनका साथ पछिको गेटवे परिवर्तन जाँच नभई तुलना बन्छ।
त्यसपछि सामान्य क्लाइन्ट र एप्लिकेसनको वास्तविक खातासँग फेरि परीक्षण गर्नुहोस्। एप्लिकेसनको अधिकार बढाउँदा प्याकेटको फर्कने मार्ग सुध्रिँदैन, र यो निदानका क्रममा खाता बदल्दा अर्को तुलना अलमलिन्छ। संरचना अनुवादमा निर्भर छ भने सर्भरका लग पढिने ठाउँमै त्यसको अभिलेख राख्नुहोस्। अडिट ट्रेलमा अपरिचित स्रोत ठेगाना देख्नेले टिकटबाट म्यापिङ फेरि पत्ता लगाउनु नपर्ने हुनुपर्छ।