टनेल अझै चालु, मार्ग गयो: दुई 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 स्थिति जोगाउँदैन, त्यसैले नयाँ प्रवाह काम गर्न सक्छन्, मूल भने तुटेकै रहन्छ। कुन ब्याकअप सक्रिय हुनुपर्छ र टाढाको साइटले त्यसबाट फिर्ती मार्ग स्वीकार्छ कि भनी पुष्टि गर्नुहोस्।

फिर्ता लिनुको कारण बुझ्नुअघि स्थायी स्थिर ओभरराइड स्थापना नगर्नुहोस्। त्यो सर्टकटले ट्राफिकलाई असफल मार्गमा पिन गर्न सक्छ वा जानाजानी बनाइएको राउटिङ नीति चुपचाप बाइपास गर्न सक्छ, र मूल कारणलाई नयाँ कन्फिगरेसनमुनि गाड्छ। मार्ग पुनःस्थापित भएपछि अनुप्रयोग फेरि परीक्षण गर्नुहोस्, र छानिएको प्रिफिक्ससँग तालिकाको प्रविष्टि मात्र होइन, काम गर्ने डेटा मार्ग छ भनी पुष्टि गर्नुहोस्।