साइट-टू-साइट 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” सुरंग स्थिति अपने आप में दोनों में से किसी निष्कर्ष का समर्थन नहीं करती।