टनल अजूनही सुरू, मार्ग गेला: दोन VPN बिघाड वेगळे करणे

एक होस्ट पोहोचण्याबाहेर जातो, तर टनल इंटरफेस अजूनही स्वतःला स्थापित असल्याचे सांगते, आणि ही दोन निरीक्षणे विरोधाभासी नाहीत. काहीतरी ट्रॅफिक वापरत असलेला मार्ग काढून टाकले: शेजाऱ्याने आपला प्रीफिक्स मागे घेतला, मागोवा घेतलेला स्थिर मार्ग काढला गेला, किंवा दुसरा मार्ग पसंत केला गेला. तिन्ही प्रकरणांत सुरक्षा संबंध पूर्णपणे निरोगी राहू शकतो. घटना वेगळे करणे म्हणजे VPN अयशस्वी झाला का हे नव्हे, तर कोणता स्तर आधी बदलला हे विचारणे.

एकच घटना वाटणारे तीन टप्पे

राउटिंग निर्णयाला तीन टप्पे असतात. प्रीफिक्स प्राप्त होतो, सर्वोत्तम म्हणून निवडला जातो, आणि फॉरवर्डिंग तक्त्यात स्थापित होतो. प्रत्येक टप्पा स्वतःहून अयशस्वी होऊ शकतो, आणि अनुप्रयोगाच्या बाजूने बिघाड सारखाच दिसतो. शिकलेला पण निवडीत हरलेला प्रीफिक्स, फॉरवर्डिंग तक्ताच पाहिला तर कधीही न आलेल्या प्रीफिक्सपासून वेगळा करता येत नाही.

म्हणून पहिला प्रश्न कोणता प्रोटोकॉल दोषी आहे हा नसून कोणता टप्पा तुटला हा आहे. उत्तर ठरवते की घटना कोणाची आहे आणि पुढील तपासणी कोणते साधन वापरेल.

आधी स्थापित मार्ग वाचा

कर्नेलला विचारा की अयशस्वी गंतव्यस्थानाकडे जाणारा ट्रॅफिक प्रत्यक्षात कुठे जातो. ip route get पुढील हॉप, इंटरफेस आणि कर्नेल वापरेल तो स्रोत पत्ता छापते, आणि संपूर्ण तक्त्यासाठी नव्हे तर एका गंतव्यस्थानासाठी उत्तर देते. उत्तर टनलचे नाव घेतल्यास, फॉरवर्डिंग तक्ता अजूनही मार्ग अस्तित्वात आहे असे मानतो आणि समस्या त्याच्या वर आहे.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

«unreachable» उत्तराचा अर्थ कोणताही स्थापित मार्ग नाही, जे मागे घेणे किंवा गहाळ स्थापनेकडे निर्देश करते. भौतिक इंटरफेसचे नाव घेणारे उत्तर म्हणजे कोणीही ठरविल्याशिवाय ट्रॅफिक टनलबाहेर गेला, आणि पुढील तपासणी जिंकलेली प्राधान्यता आहे. तर पॅकेट अजूनही गायब होत असताना टनलचे नाव घेणारे उत्तर मार्गात पुढे, गाळण्याकडे किंवा पलीकडील बाजूकडे निर्देश करते.

मग प्रोटोकॉलचे स्वतःचे दृश्य पाहा

राउटिंग डेमन एकापेक्षा जास्त तक्ते ठेवतो, आणि मनोरंजक तुलना त्यांच्यातील आहे. BGP साठी, शेजारी सत्राची स्थिती, प्राप्त घोषणा आणि स्थापित मार्ग हे तीन वेगळे पुरावे आहेत. कमी प्रशासकीय अंतराचा मार्ग जिंकल्याने प्रीफिक्स प्राप्त तक्त्यात राहू शकतो आणि कर्नेलपर्यंत कधीही पोहोचू शकत नाही. दुसरी बाजू घोषणा थांबवली असा निष्कर्ष काढण्यापूर्वी तिन्ही तपासा.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

सारांश सांगतो सत्र स्थापित आहे का, प्रीफिक्सनुसारचे दृश्य सांगते प्रीफिक्स स्वीकारला गेला का, आणि कर्नेल शोध सांगतो तो स्थापित झाला का. या क्रमाने वाचल्यास सत्राचा कंप हटवण्यासोबत आणि हटवणे धोरणाधारित नकारासोबत गोंधळण्याचे टळते.

जेव्हा घड्याळे जुळत नाहीत

टनल लॉग, राउटिंग लॉग आणि अनुप्रयोगाचा पहिला बिघाड त्यांच्या खऱ्या कालविभागांचा वापर करून एकाच वेळरेषेवर ठेवा. शेजाऱ्याची हानी आधी आल्यास, टनलने मार्ग आपल्यासोबत खाली आणला. हटवणे आधी आल्यास, राउटिंग बदलले आणि टनलने नंतर प्रतिक्रिया दिली. हे वेगवेगळ्या मालकांचे वेगवेगळे घटनाप्रसंग आहेत, आणि क्रम हाच संपूर्ण शोध आहे.

एक मिनिटाची घड्याळ तफावत तो निष्कर्ष उलटवण्यासाठी पुरते, म्हणून क्रमावर विश्वास ठेवण्यापूर्वी कालविभाग आणि ऑफसेट तपासा. ऑफसेटशिवाय स्थानिक वेळेत लॉग ठेवणारी उपकरणे आत्मविश्वासू पण चुकीच्या वेळरेषेचा नेहमीचा स्रोत आहेत.

लूपशिवाय पुनर्प्राप्ती

हटवल्यानंतर दोन मार्ग पात्र असू शकतात: प्रोटोकॉल निवडतो तो मार्ग आणि तुम्ही हाताने पिन करता तो मार्ग. नेटवर्क तुमच्यासाठी घेत राहणारा निर्णय फक्त पहिलाच आहे, म्हणून हाताने केलेला मार्ग पुनर्प्राप्ती योजना नाही तर तात्पुरता उपाय आहे. पर्यायी घोषणाही आधीच स्थापित सत्रासाठी फायरवॉल किंवा NAT स्थिती जपत नाही, त्यामुळे नवे प्रवाह काम करू शकतात, मूळ मात्र तुटलेले राहते. कोणता बॅकअप सक्रिय व्हायला हवा आणि दूरचे साइट त्यातून परतीचा मार्ग स्वीकारेल का ते तपासा.

हटवणे का झाले हे समजण्यापूर्वी कायमस्वरूपी स्थिर ओव्हरराइड स्थापित करू नका. तो शॉर्टकट ट्रॅफिकला अयशस्वी मार्गावर पिन करू शकतो किंवा जाणीवपूर्वक केलेले राउटिंग धोरण शांतपणे बायपास करू शकतो, आणि मूळ कारण नव्या संरचनेखाली पुरतो. मार्ग पुनर्संचयित झाल्यावर अनुप्रयोग पुन्हा तपासा, आणि निवडलेल्या प्रीफिक्सकडे तक्त्यातील नोंद इतकाच नव्हे तर कार्यरत डेटा मार्ग आहे याची खात्री करा.