जेव्हा स्प्लिट टनेलचे मार्ग एकमेकांवर आच्छादतात: कोणता प्रीफिक्स जिंकतो

दोन स्प्लिट टनेल प्रोफाइल, दोन खाजगी प्रीफिक्स आणि दोन्ही हक्क सांगत असलेला एक होस्ट। लक्षण क्वचितच स्वच्छ अपयश असते: एखादी सेवा सोमवारी चालते, दुसरा क्लायंट पुन्हा जोडल्यानंतर वेळोमिती संपते आणि रीबूटनंतर पुन्हा चालते। तुम्ही क्लायंट कोणत्या क्रमाने जोडले यावर निकाल ठरत नाही, आणि क्लायंटच्या इंटरफेसमधील ओळींच्या क्रमानेही ठरत नाही। या तपासण्या क्रमाने करा आणि जी पहिली जुळत नाही तिथे थांबा, कारण नंतरच्या तपासण्यांना अर्थ तेव्हाच असतो जेव्हा आधीच्या खऱ्या असतात।

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 उत्तर पुन्हा वाचा। दुसरा क्लायंट जोडताना स्वतःचा मार्ग पुन्हा बसवू शकतो आणि संघर्ष पुन्हा निर्माण करू शकतो, म्हणून स्थितीची तपासणी शेवटचा क्लायंट जोडल्यानंतर झाली पाहिजे, त्यापूर्वी नाही।

एक नाही तर दोन प्रवाह तपासा: जी विनंती आधी अपयशी होत होती आणि दुसऱ्या टनेलने वापरायचे असलेले संसाधन। सर्व खाजगी रहदारी एका जोडणीवर हलवल्यास पहिली चाचणी पास होईल पण दुसरी तुटेल, आणि हे फक्त जोडीने केलेली चाचणीच पकडते। तुम्ही ठेवलेला प्रत्येक अपवाद गंतव्यस्थान आणि कारणासह नोंदवा, जेणेकरून पुढचा माणूस जाणीवपूर्वक केलेला होस्ट मार्ग उरलेल्यापासून वेगळा ओळखू शकेल।