कुन VRF ले VPN पियरसम्म पुग्छ र कुनले प्याकेट बोक्छ?

ग्राहकको राउटिङ सन्दर्भभित्रको प्रत्येक टनेलले अझै आफ्नो टाढाको पियरसम्म पुग्नुपर्छ, र त्यो खोज पूर्ण रूपमा अर्कै तालिकामा हुन सक्छ। यसलाई गलत गर्दा VRF-थाहा पाउने IPsec मा सबैभन्दा अन्योलपूर्ण असफलताहरूमध्ये एक हुन्छ: टनेल माथि आउँछ, रुटहरू उपस्थित देखिन्छन्, र दुई खोजमध्ये एकले गलत सन्दर्भ प्रयोग गरेको कारण ट्राफिक मर्छ। तलका चार चरण क्रममा गर्नुहोस् र दुई गन्तव्य अलग-अलग लेख्नुहोस्।

दुई खोज, एउटा टनेल

बाहिरी इन्क्याप्सुलेट गरिएको प्याकेट पियरको यातायात ठेगानामा सम्बोधन गरिन्छ, र कुनै पनि सुरक्षा हुनुअघि यसलाई रुट गरिन्छ। भित्री प्याकेट ग्राहक सर्भरमा सम्बोधन गरिन्छ र डिक्याप्सुलेसनपछि, ग्राहकको सन्दर्भभित्र रुट गरिन्छ। यी दुई गन्तव्य, दुई खोज र प्रायः दुई फरक तालिका हुन्।

VRF-थाहा पाउने IPsec का लागि Cisco को कागजातले यिनलाई अगाडिको ढोकाको VRF र भित्री VRF भन्छ। अगाडिको ढोकाले इन्क्रिप्ट गरिएको यातायात बोक्छ, र भित्री सन्दर्भले सुरक्षित ट्राफिक बोक्छ। टनेललाई ग्राहकको नाममा राख्दा दुईमध्ये कुनै पनि रुट देखिँदैन।

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

पियरका लागि यातायात खोज पुष्टि गर्नुहोस्

अगाडिको ढोकाबाट सुरु गर्नुहोस्, किनकि आफ्नो पियरसम्म पुग्न नसक्ने टनेलले एउटै पनि सुरक्षित प्याकेट जान दिँदैन। IOS मा विश्वव्यापी तालिकाको सट्टा यातायात VRF भित्र पियरसम्मको रुट सोध्नुहोस्।

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

पहिलो आदेशले त्यो सन्दर्भमा पियरको ठेगाना पुग्न सकिने छ कि छैन भनेर जवाफ दिन्छ, दोस्रोले वास्तवमै अवस्थित VRF हरू सूचीबद्ध गर्छ, र तेस्रोले सुरक्षा सम्बन्ध बन्यो कि भनेर देखाउँछ। विश्वव्यापी तालिकामा मात्र समाधान हुने पियर ठेगाना नै चिरपरिचित अगाडिको-ढोकाको गल्ती हो, र यो कहिल्यै सुरु नहुने IKE वार्ता जस्तो देखिन्छ।

इन्टरफेसको बाँडफाँट पनि जाँच्नुहोस्। अभिलेखित व्यवहारले टनेलको अगाडिको-ढोकाको VRF र WAN इन्टरफेसको VRF मिल्नुपर्ने माग गर्छ; बेमेलले प्याकेट बाहिर जान दिन सक्छ र तैपनि प्रतिक्रिया सही सन्दर्भमा प्रशोधन हुनबाट रोक्न सक्छ।

सर्भरका लागि भित्री खोज पुष्टि गर्नुहोस्

अगाडिको ढोका प्रमाणित भएपछि ग्राहकको सन्दर्भमा जानुहोस् र सर्भरको प्रिफिक्सबारे त्यही प्रश्न सोध्नुहोस्। यो खोजले डिक्याप्सुलेट भएको प्याकेट अगाडि पठाउन सकिन्छ कि भनेर निर्धारण गर्छ।

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

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

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

सेटिङ मोडेलले अपेक्षा गर्ने ठाउँमा राख्नुहोस्

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

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

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