जब स्प्लिट टनेलका मार्गहरू ओभरल्याप हुन्छन्: कुन प्रिफिक्स जित्छ

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

1. गन्तव्य र स्रोत लेख्नुहोस्

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

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

2. कर्नेललाई कुन मार्ग छान्यो भनेर सोध्नुहोस्

मार्ग तालिका पढेर उत्तर अनुमान नगर्नुहोस्। स्ट्याकले सोध्ने प्रश्न नै त्यही स्रोत ठेगानासहित सोध्नुहोस्: Linux मा ip route get 10.20.4.10 from 10.8.0.2 वा PowerShell मा Find-NetRoute -RemoteIPAddress 10.20.4.10। आउटपुटले वास्तवमा प्रयोग हुने मार्ग बताउँछ, र तालिका पढ्दा तपाईंले अपेक्षा गरेको भन्दा त्यो प्रायः फरक हुन्छ।

मिल्ने मार्गहरूमध्ये सामान्यतया बढी विशिष्ट प्रिफिक्स जित्छ: दुवैभित्र पर्ने ठेगानाका लागि /24 ले /16 लाई हराउँछ। समान लम्बाइका मिलानहरूमध्ये कम मेट्रिक जित्छ, र बन्द लिङ्कमा राखिएको मार्ग छोडिन्छ। एउटै /24 लाई एउटै मेट्रिकसँग धकेल्ने दुई टनेल फरक अवस्था हो: कर्नेलले दुवै मार्ग राख्छ र तिनीहरूबीच छनोट गर्छ, त्यसैले क्लाइन्ट जोडिएको क्रम पछ्याउनुको सट्टा नतिजा फेरिइरहन सक्छ। सोमबार-चल्छ-मङ्गलबार-असफल-हुन्छ ढाँचा यही अवस्थाले बनाउँछ, र अर्को क्रममा पुनः जोड्दा त्यो बदलिँदैन।

3. नीति नियमले खोज अन्तै मोडेको छ कि जाँच्नुहोस्

मार्ग तालिका हेर्नु अघि कर्नेलले आफ्ना नीति नियमहरू पार गर्छ। नियमले दिइएको स्रोत, प्रयोगकर्ता वा फायरवाल मार्कको ट्राफिक पूरै अर्को तालिकामा पठाउन सक्छ, त्यसैले मुख्य तालिकाको जित्ने प्रिफिक्स त्यो प्रवाहका लागि कहिल्यै नहेरिन सक्छ। ip rule show ले तिनीहरूलाई मूल्याङ्कन क्रममा सूचीबद्ध गर्छ, र ip route show table 100 ले छानिएको तालिकामा वास्तवमा के छ देखाउँछ।

यहाँ दुई जाल छन्। खाली तालिकातर्फ देखाउने नियमले अर्को नियममा खस्ने खोज बनाउँछ, त्यसैले नियम केही नगरेजस्तो देखिन्छ। अर्को जाल प्राथमिकता नम्बर आफै हो: नियमहरू बढ्दो क्रममा पढिन्छन्, र अन्तर्निहित मानहरू 0 local, 32766 main र 32767 default हुन्। 32767 भन्दा कम नम्बरको नियम सबै समात्ने पूर्वनिर्धारित नियमभन्दा अघि हेरिन्छ। 32767 भन्दा बढी नम्बरको नियम त्यसको पछाडि बस्छ र अघिल्लो कुनै तालिकाले उत्तर नदिएपछि मात्र पुगिन्छ, जसलाई main मा रहेको सामान्य पूर्वनिर्धारित मार्गले रोक्छ, त्यसैले व्यवहारमा त्यहाँ कहिल्यै पुगिँदैन र स्थापित देखिँदादेखिँदै चुपचाप केही गर्दैन। यदि क्लाइन्टले नियम र मार्ग दुवै लेखेको छ भने दुवै जाँच्नुहोस्, र पुनः जोडिएपछि फेरि जाँच्नुहोस्, किनकि पुनः लेखिएको प्रोफाइलले फरक प्राथमिकताको दोस्रो नियम थप्न सक्छ।

4. रुटिङको बराबरी र दोहोरिएको ठेगाना योजना छुट्याउनुहोस्

कहिलेकाहीँ प्रिफिक्स नै समस्या हुँदैन। दुवै साइटले 192.168.1.0/24 प्रयोग गर्नुको अर्थ एउटै ठेगानाले दुई फरक होस्ट चिनाउँछ, र कुनै मार्गले तिनलाई छुट्याउन सक्दैन। दुई उत्तरमध्ये एउटातर्फको होस्ट मार्ग अर्को साइटले त्यही नामको उत्तर नदिएसम्म मात्र काम गर्छ, र त्यसपछि अपवाद चुपचाप नै खराबी बन्छ।

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

5. रिजोल्भर मार्गसँग सहमत छ भनी पुष्टि गर्नुहोस्

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

रिजोल्भरलाई सिधै सोध्नुहोस् र उत्तर दिने सर्भर नोट गर्नुहोस्। छोटो TTL भएको क्यास उत्तरले पुनः जोडिएपछि पहिलो अनुरोध पाँचौँभन्दा फरक किन व्यवहार गर्छ भन्ने पनि व्याख्या गर्न सक्छ।

6. पुनः जोड्नुहोस्, लागू भएको अवस्था हेर्नुहोस्, त्यसपछि दुवै प्रवाह परीक्षण गर्नुहोस्

सुधारपछि पुनः जोड्नुहोस् र प्रोफाइल सम्पादकमाथि भरोसा गर्नुको सट्टा क्लाइन्टले वास्तवमा के स्थापना गर्‍यो हेर्नुहोस्। नियम, तालिका र त्यसबाट आउने ip route get उत्तर फेरि पढ्नुहोस्। दोस्रो क्लाइन्टले जोडिँदा आफ्नै मार्ग पुनः स्थापना गर्न सक्छ र द्वन्द्व फेरि बनाउन सक्छ, त्यसैले अवस्था जाँच अन्तिम क्लाइन्ट जोडिएपछि हुनुपर्छ, अघि होइन।

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