VPN द्वारे 169.254: हा पत्ता कधीही मार्गस्थ होऊ शकला नाही
लिंक-लोकल गंतव्य बोगद्यापर्यंत पोहोचण्यापूर्वीच टाकून दिले जाते, त्यामुळे मार्ग जोडल्याने फक्त अपयश वाढते. सबनेट दुरुस्त करणे किंवा पूल बांधणे यातून निवडा.
तुम्ही मार्ग जोडता, बोगदा वर येतो, तरीही पलीकडे जाणारा ping «network unreachable» ऐवजी पूर्ण नुकसानाने मरतो. हा फरक महत्त्वाचा आहे, कारण तो मार्ग तक्त्याकडून पत्त्याकडे लक्ष वळवतो. 169.254 हे गंतव्य लिंक-लोकल आहे आणि त्याची व्याप्ती रचनेनुसार पहिल्या hop वर संपते, चुकीच्या संरचनेमुळे नाही.
पुढील निर्णय अरुंद आहे: सर्व्हरच्या बाजूचे सबनेट दुरुस्त करा किंवा स्तर 2 चा भाग वाढवा. अगदी रुंद मार्गही तोच अपयश अधिक गंतव्यांपर्यंत पसरवतो.
पत्त्याला मार्ग नाही असे नाही, तो मार्गस्थ होऊ शकत नाही
IPv4 लिंक-लोकल पत्ते जेव्हा चांगले काही उत्तर देत नाही तेव्हा स्वतःला देतात; Windows मधील स्वयंचलित खाजगी पत्ता नियुक्ती येथूनच येते. हा परिघ प्रत्येक दुव्यावर एकाच वेळी वापरला जातो आणि म्हणूनच तो चालतो: एकाच भागातील दोन होस्ट कोणत्याही समन्वयाशिवाय बोलू शकतात.
याच गुणधर्मामुळे राउटरने हे पॅकेट नेटवर्कदरम्यान पाठवू नयेत. लिंक-लोकल गंतव्यासाठीचे पॅकेट घेऊन दुसऱ्या इंटरफेसने बाहेर पाठवल्यास अस्पष्टता निर्माण होईल, कारण पाठवणाऱ्याचे «स्थानिक» आणि घेणाऱ्याचे «स्थानिक» वेगवेगळी ठिकाणे आहेत. कोणते अभिप्रेत होते हे ठरवणारा शोध नाही. येथे पाठवणे हा प्रशासक सुरू करू शकणारा धोरण पर्याय नाही.
म्हणून 169.254.1.10 बोगद्यातून उपलब्ध असे नोंदवणारा प्रवेशद्वार कर्नेलला असे काही मागतो जे पत्त्याच्या स्वरूपाने प्रतिबंधित केले आहे. पॅकेट दूरच्या होस्टपर्यंत पोहोचण्यापूर्वीच टाकून दिले जाते.
बोगदा व्याप्तीची समस्या का दाखवतो
TUN इंटरफेस दोन बाजूंमध्ये IP पॅकेट वाहून नेतो आणि त्यामागे सामायिक भाग नाही. प्रसारण नाही, दुसऱ्या बाजूसाठी ARP नाही आणि शेजारी शोधही नाही.
लक्षणे नेमकी जुळतात. मार्ग तक्त्यात आहे, ping पूर्ण नुकसान सांगतो, शेजारी तक्ता अपूर्ण नोंद दाखवतो. बोगद्यावरील नोंद पॅकेट बाहेर जात असल्याचे दाखवते, ज्यामुळे लोक पत्ता वर्गाकडे नाही तर दूरच्या टोकाकडे पाहतात.
Windows मध्ये त्याच मुळाचे दुसरे, बिनसंबंध वाटणारे लक्षण आहे: फक्त लिंक-लोकल पत्ता असलेल्या अडॅप्टरला वापरण्यायोग्य प्रवेशद्वार नसते, त्यामुळे फायरवॉल प्रोफाइल public वर पडते. बोगदा कारण नाही; पत्ता कारण आहे.
तीन प्रश्नांनी ठरवा
सबनेट दुरुस्त करणे आणि पूल बांधणे यातील निवड तीन अटींवर अवलंबून आहे.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
बहुतेक प्रकरणे पहिल्या प्रश्नावर थांबतात. लिंक-लोकल पत्ता दाखवणारा होस्ट म्हणजे सहसा DHCP ने उत्तर दिले नाही, केबल किंवा VLAN चुकीचे आहे, किंवा कोणी पत्ता हाताने लिहिला. हे दुरुस्त करणे कोणत्याही बोगदा कामापेक्षा स्वस्त आहे आणि पुढील सर्व ग्राहकांकडून समस्या दूर करते.
काहीही गृहीत धरण्यापूर्वी सर्व्हरची बाजू तपासा. होस्टवर ip addr show आणि ip route, ग्राहकावर arp -n किंवा route print -4 चालवा.
पूल योग्य उत्तर असताना त्याचा खर्च
भौतिक अडॅप्टरला TAP अडॅप्टरशी पूल करून दूरचा ग्राहक स्थानिक प्रसारण क्षेत्राचा भाग होतो.
खर्च खरा आहे आणि कोणी स्वीकारण्यापूर्वी सांगावा. प्रसारण रहदारी बोगद्यातून जाते, ग्राहक स्थानिक भागासमोर सर्व हेतूंसाठी खुला असतो, आणि सर्व्हर आता पॅकेट मार्गस्थ करण्याऐवजी फ्रेम पाठवतो. प्रयोगशाळेसाठी हे योग्य, दूरस्थ प्रवेशासाठी वाईट डीफॉल्ट.
पूल बांधताना दोन्ही अर्धे लागतात: सर्व्हरवरील पूल आणि ग्राहक प्रोफाइलमधील मार्ग. फक्त पूल ग्राहकाला अंदाज करायला लावतो आणि फक्त मार्ग पत्ता वर्ग दुरुस्त करू शकत नाही.