साइट-टू-साइट 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” बोगदा स्थिती स्वतःच दोन्हीपैकी कोणत्याही निष्कर्षाला पुष्टी देत नाही।