जब स्प्लिट टनलिंग के रूट ओवरलैप हों: कौन-सा प्रीफ़िक्स जीतता है

दो स्प्लिट टनलिंग प्रोफ़ाइल, दो निजी प्रीफ़िक्स और एक होस्ट जिस पर दोनों दावा करते हैं। लक्षण शायद ही कभी साफ़ विफलता होता है: कोई सेवा सोमवार को चलती है, दूसरे क्लाइंट के फिर से जुड़ने के बाद समय-सीमा पार कर जाती है, और रीबूट के बाद फिर चलती है। आपने क्लाइंट किस क्रम में जोड़े, यह परिणाम तय नहीं करता, और क्लाइंट के इंटरफ़ेस में पंक्तियों का क्रम भी नहीं। ये जाँचें क्रम से करें, और पहली ऐसी जाँच पर रुक जाएँ जो सही न हो, क्योंकि बाद वाली जाँचें तभी अर्थ रखती हैं जब पहले वाली सही हों।

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 उत्तर को दोबारा पढ़ें। दूसरा क्लाइंट जुड़ते समय अपना रूट फिर से स्थापित कर सकता है और टकराव फिर बना सकता है, इसलिए स्थिति की जाँच अंतिम क्लाइंट के जुड़ने के बाद होनी चाहिए, उससे पहले नहीं।

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