उत्तर टनेलमधून नाही, LAN मधून बाहेर पडते: का आणि कसे

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

बाहेर जाणारे पॅकेट प्रत्यक्षात काय ठरवते

कर्नल पॅकेटच्या गंतव्यासाठी मार्ग शोधते, धोरण नियम प्राधान्यक्रमाने पाहते आणि नंतर जुळणारा नियम निवडतो तो तक्ता पाहते। पॅकेट ज्या इंटरफेसवरून आले त्याची कोणतीही भूमिका नाही, तो महत्त्वाचा करण्यासाठी नियम किंवा खूण लिहिली नसेल तर। हे या होस्टचे राउटिंग तथ्य आहे, टनेलचा दोष नाही।

म्हणून टनेलवर मिळालेली विनंती भौतिक इंटरफेसवरून बाहेर जाणारे उत्तर निर्माण करू शकते, आणि कोणतेही उपकरण त्रुटी न कळवता प्रवाह एकमार्गी होतो। टनेलबद्दल निष्कर्ष काढण्यापूर्वी दोन्ही दिशा तपासा। चुकीच्या दिशेने जाणारे उत्तर टनेलच्या काउंटरमधून नाहीसे होते, म्हणूनच काही पाठवले गेले का यावर दोन्ही टोके सहमत नाहीत। कोणत्याही नियमाला हात लावण्यापूर्वी कोणता काउंटर बदलला ते पहा।

स्थानिक सबनेट का जिंकते

स्थानिक नेटवर्कवर पत्ता असलेल्या होस्टकडे मुख्य तक्त्यात त्या प्रिफिक्ससाठी जोडलेला मार्ग असतो, आणि जोडलेला मार्ग म्हणजे थेट जुळणी। कॉलर त्याच सबनेटमधून आल्यास, शोध टनेल विचारात घेण्यापूर्वीच स्थानिक दुवा शोधतो।

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

पीअर कव्हरेज आणि स्थापित मार्ग सारखे नाहीत

टनेलच्या बाजूला, पीअरच्या परवानगी असलेल्या श्रेणी टनेलमध्ये काय पाठवता येते आणि त्यातून कोणते स्रोत स्वीकारले जातात हे वर्णन करतात। स्थानिक राउटिंग तक्ता पॅकेट कुठे पाठवेल याबद्दल ते काहीच सांगत नाहीत।

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

स्रोत पत्त्यानुसार तक्ता निवडा

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

शेवटची ओळ अनुपस्थित मार्गाला स्थानिक दुव्यावर परत जाण्याऐवजी दृश्यरूपाने अयशस्वी करते। स्रोत खरोखर होस्टला नेमलेला असला पाहिजे, आणि सामान्य स्थानिक व मुख्य शोध त्यांच्या पूर्वीच्या स्थानांवरच राहिले पाहिजेत। नियम स्रोतानुसार तक्ता निवडतो; तो तक्त्यांमधील प्रिफिक्स लांबीची तुलना करत नाही।

आधी मार्ग, नंतर सेवा याची खात्री करा

कॅप्चरवरून अंदाज न करता कर्नललाच काय करेल ते विचारा, सेवा पत्ता स्रोत-निवडक म्हणून वापरून। इथे योग्य उत्तर संपूर्ण पॅकेट ट्रेस वाचवते।

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

आउटपुटमध्ये टनेलचे नाव असावे। नंतर तुम्ही न छुंलेल्या स्रोताची चाचणी करा आणि तो अजूनही स्थानिक दुवा घेतो याची खात्री करा, जेणेकरून बदल एका पत्त्यापुरता मर्यादित राहील। अधिक व्यापक निवडक मूळ तक्रारीबद्दल काहीही सिद्ध करणार नाही।

हे काय दुरुस्त करत नाही

गेटवेवरील फॉर्वर्डिंग, फायरवॉल नियम आणि ICMPv6 वर्तन पूर्वीप्रमाणे ठेवा, कारण स्रोत-मार्ग यातील कोणतेही बदलत नाही। गहाळ Packet Too Big संदेश कोणता तक्ता शोध जिंकला तरी मोठी उत्तरे तोडतो। राउटिंग नियम जोडण्यापूर्वी ते दुरुस्त करा, नाहीतर बदलानंतरही लक्षण टिकून राहील।

यापैकी काहीही लागू करण्यापूर्वी प्रकाशन मॉडेलची खात्री करा। स्वतःचे बॅकएंड कनेक्शन उघडणारा रिव्हर्स प्रॉक्सी स्वतःचा स्रोत सादर करतो आणि कॉलर जपत नाही, म्हणून त्या रचनेत हा दोष उद्भवू शकत नाही। तिथे नियम लागू केल्यास काहीही सोडवत नसलेला आणि खरे कारण लपवणारा राउटिंग अपवाद जोडला जाईल।

शेवटी, नियम क्रमांक आणि तक्ता होस्टच्या कॉन्फिगरेशन व्यवस्थापनात लिहा। हाताने जोडलेला धोरण नियम पुढील पुनर्बांधणीत नाहीशा होतो, आणि कार्यालयातील कॉलर त्याच तक्रारीसह परत येतो।