साइट-देखि-साइट VPN एउटै दिशामा मात्र काम गर्छ: दुई फरक खराबी

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

यही भिन्नताले कुन आदेश चलाउनु उपयुक्त हुन्छ भन्ने निर्धारण गर्छ।

एउटै देखिने दुई खराबी

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

असफल प्रयास कुन पक्षले सुरु गर्‍यो भनेर सोध्नुहोस्। त्यो एउटै तथ्यले आधा सम्भावित कारण हटाउँछ।

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

पहिलो अवस्था: फर्कने बाटो छैन

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

अनुवादपछि गन्तव्यले वास्तवमा देख्ने ठेगाना र फर्कने मार्ग मूल सबनेटको सट्टा त्यही ठेगानाका लागि जाँच्नुहोस्।

दोस्रो अवस्था: नीतिले यसलाई कहिल्यै अनुमति दिएन

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

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

एउटै होस्टमा अघि र पछि तुलना गर्नुहोस्

दुई छुट्टै प्रयास होइन, एउटै प्रयासका दुवै छेउ हेर्नुहोस्। सुरु गर्ने होस्टको गेटवे र गन्तव्यमा क्याप्चर गर्नुहोस्, त्यसपछि के भित्र आयो, के बाहिर गयो र टाढाको पक्षले कुन ठेगाना देख्यो तुलना गर्नुहोस्।

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

सुधारपछि एउटै होस्टबाटै त्यही परीक्षण दोहोर्‍याउनुहोस् र असम्बन्धित पहुँच अझै अस्वीकार गरिएको छ भनी पुष्टि गर्नुहोस्। “established” सुरुङ स्थितिले आफैमा दुईमध्ये कुनै पनि निष्कर्षलाई समर्थन गर्दैन।