Linux मा फर्वार्डिङ खोलेपछि IPv6 को पूर्वनिर्धारित मार्ग हरायो

VPN ग्राहकको ट्राफिक पठाउन सकोस् भनेर मैले एउटा Debian गेटवेमा net.ipv6.conf.all.forwarding=1 राखें, र करिब आधा घण्टापछि मेसिनसँग कुनै IPv6 पूर्वनिर्धारित मार्ग थिएन। माथिको राउटर चालु थियो, link-local छिमेकीले अझै जवाफ दिइरहेको थियो, र अपलिङ्कले अझै आफ्नो विश्वव्यापी ठेगाना राखेको थियो। जे रोकियो त्यो कर्नेलको त्यो इन्टरफेसमा राउटर विज्ञापनहरू लिइरहने तयारी थियो। sysctl लेखेको क्षणमा मार्ग हराएन; RA बाट सिकेको पूर्वनिर्धारित मार्गको आयु सकिँदा हरायो र कसैले त्यसलाई नवीकरण गरेन।

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

कुनै पनि sysctl छुनुअघि मार्गको तालिका पढ्नुहोस्

ip -6 route show default बाट सुरु गर्नुहोस् र गेटवे मात्र नभई विशेषताहरू पढ्नुहोस्। RA बाट सिकेको पूर्वनिर्धारित मार्ग proto ra ले चिन्हित हुन्छ, प्राथमिकता बोक्छ र expires को उल्टो गणना देखाउँछ। हातले थपेको मार्गमा यीमध्ये केही हुँदैन, र यही भिन्नताले मार्गको मालिक कुन संयन्त्र हो भन्ने बताउँछ।

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

त्यसपछि ठेगाना हेर्नुहोस्: ip -6 addr show dev eth0। घण्टामा नापिएको प्राथमिक र वैध आयु भएको विश्वव्यापी ठेगाना, राउटर आयु मिनेटमा नापिने पूर्वनिर्धारित मार्गभन्दा लामो बाँच्नेछ। ठेगाना छ तर पूर्वनिर्धारित मार्ग छैन भने त्यो विज्ञापन समस्याको छाप हो। ठेगाना पनि छैन भने पहिले लिङ्क, प्रिफिक्स जानकारी वा दोहोरो ठेगाना पहिचानतर्फ लाग्नुपर्छ।

किन फर्वार्डिङले RA प्रशोधन बन्द गर्छ

RA भनेको 134 प्रकारको ICMPv6 प्याकेट हो, जो link-local स्रोतबाट 255 हप सीमासहित पठाइन्छ। कर्नेलले यसलाई प्रयोग गर्नुअघि इन्टरफेसको accept_ra हेर्छ। पूर्वनिर्धारित मान 1 हो, र 1 को अर्थ होइन हुन्न। यसको अर्थ हो: यो होस्ट फर्वार्ड नगरेसम्म मात्र स्वीकार गर। forwarding=1 राख्नुहोस् र त्यो सर्त पुग्दैन, त्यसैले विज्ञापनभित्रको कुनै प्रिफिक्स वा पूर्वनिर्धारित राउटर विचार गर्नुअघि नै त्यो खारेज हुन्छ।

तीन मान छन्, र फर्वार्डिङबाट तेस्रो मात्र बाँच्छ:

अरू दुई झन्डाले प्रत्यक्ष रूपमा के स्थापना हुन्छ भन्ने तय गर्छ। accept_ra_defrtr ले विज्ञापनको पूर्वनिर्धारित राउटर मार्ग बन्छ कि बन्दैन नियन्त्रण गर्छ, र accept_ra_pinfo ले प्रिफिक्स जानकारी ठेगाना कन्फिगरेसनमा प्रयोग हुन्छ कि हुँदैन नियन्त्रण गर्छ। accept_ra_defrtr बन्द गर्नु फर्वार्डिङ होस्टमा पूर्वनिर्धारित मार्ग नसिकी SLAAC ठेगाना राख्ने सामान्य तरिका हो। यो accept_ra भन्दा फरक लिभर हो, र ठेगाना चाहिन्छ तर मार्ग चाहिँदैन भने यही प्रयोग गरिन्छ। कर्नेलको IP sysctl सन्दर्भ तीनैको सूची दिन्छ।

तीन आदेशले पुष्टि गर्नुहोस्

पहिले लोड भएको ठानिएको फाइलको सट्टा चालु मानहरू पढ्नुहोस्:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

दोस्रो, विज्ञापनहरू अझै आइरहेको प्रमाणित गर्नुहोस्। ICMPv6 प्रकारको बाइटमा फिल्टर गर्नु पर्याप्त हुन्छ, र यसले छिमेकी खोजी ट्राफिकको पर्खाल पढ्नबाट बचाउँछ:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

केही मिनेटमा केही देखिएन भने accept_ra तपाईंको समस्या होइन। माथिल्लो पक्षले विज्ञापन दिन छोड्यो, बाटोमा केहीले ICMPv6 फिल्टर गरिरहेको छ, वा त्यो इन्टरफेस साँच्चै तपाईंले सोचेको खण्डमा छैन। तेस्रो, आफैं विज्ञापन माग्नुहोस् र त्यसका फिल्डहरू पढ्नुहोस्:

rdisc6 eth0

rdisc6 Debian र Ubuntu मा ndisc6 प्याकेजमा आउँछ। आउटपुटमा अरू केही बदल्नुअघि राउटर आयु र प्राथमिकता हेर्नुहोस्। राउटर आयु 0 भएको विज्ञापन पूर्वनिर्धारित राउटर हटाउने निर्देश हो, र accept_ra को कुनै मानले त्यसलाई उपयोगी मार्ग बनाउँदैन। यसरी नै ब्रिज मोडमा रहेको माथिल्लो CPE पनि समातिन्छ, जसले प्रिफिक्स बाँड्छ तर आफूलाई कहिल्यै राउटरका रूपमा प्रस्तुत गर्दैन।

अपलिङ्कलाई एकमात्र अनुमति दिने इन्टरफेस बनाउनुहोस्

यदि माथिल्लो पक्ष नै पूर्वनिर्धारित राउटर हुनुपर्ने हो भने, फर्वार्डिङ हुँदाहुँदै पनि त्यहीं विज्ञापन स्वीकार्नुहोस्, र अन्यत्र होइन:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

सीमा तोक्नु महत्त्वपूर्ण छ किनकि Linux मा IPv6 फर्वार्डिङ एउटै विश्वव्यापी स्विच हो, हरेक लिङ्कको लागि एउटा होइन। net.ipv6.conf.wg0.forwarding मा 1 लेख्नुहोस् र त्यसपछि net.ipv6.conf.all.forwarding पढ्नुहोस्: विश्वव्यापी मान पल्टिन्छ र हरेक इन्टरफेस फर्वार्ड गर्न थाल्छ। तपाईं सुरुङमा राउटर र LAN मा साधारण होस्ट एकैचोटि हुन सक्नुहुन्न। जे सीमित गर्न सकिन्छ त्यो स्वीकृति हो। accept_ra=2 अपलिङ्कमा राख्नुहोस् र सुरुङ तथा LAN इन्टरफेस 1 वा 0 मा छोड्नुहोस्, ताकि सुरुङबाट आएको बाटो बिराएको विज्ञापनले त्यसभित्र देखाउने पूर्वनिर्धारित मार्ग स्थापना गर्न नसकोस्।

अस्थायी sysctl -w अर्को बुटसम्म टिक्दैन, र systemd-networkd तथा NetworkManager दुवैले यी मान आफ्नै कन्फिगरेसनबाट लेख्छन्। networkd मा अपलिङ्कको .network फाइलमा IPv6Forwarding=yes र IPv6AcceptRA=yes राख्नुहोस्; networkd ले कर्नेलकै कारणले IPv6Forwarding लाई विश्वव्यापी भन्छ। NetworkManager मा अपलिङ्कको ipv6.method=auto ले नै accept_ra को मान चलाउँछ, त्यसैले पहिलो जाँचमा भर नपरी nmcli connection up पछि sysctl फेरि पढ्नुहोस्।

स्थिर विकल्प ip -6 route add default via fe80::1 dev eth0 साँच्चै काम गर्छ, र माथिल्लो राउटरसँग स्थिर link-local ठेगाना हुँदा यो उचित उत्तर हो। तपाईं के छोड्दै हुनुहुन्छ स्पष्ट हुनुहोस्। स्थिर पूर्वनिर्धारित मार्ग कहिल्यै नवीकरण हुँदैन र कहिल्यै फिर्ता लिइँदैन, त्यसैले माथिल्लो पक्ष बदलिएपछि पनि त्यो मृत छिमेकीतिर देखाइरहन्छ। RA को मार्ग सुरक्षित रूपमा असफल हुन्छ; स्थिर चाहिँ चुपचाप असफल हुन्छ।

फर्वार्ड भएको प्याकेट परीक्षण गर्नुहोस्, गेटवेको आफ्नै होइन

गेटवेका आफ्नै पिंग कुनै ग्राहकले प्रयोग गर्न नसक्ने मार्गमा सफल हुन सक्छन्, र गेटवे नै स्रोत भएकाले पनि सफल हुन सक्छन्। जोडिएको ग्राहकबाट परीक्षण गर्नुहोस्, त्यसपछि गेटवेलाई सोध्नुहोस् त्यो ग्राहकको ठेगानाका लागि के गर्नेछ:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

त्यसपछि एउटा राउटर आयु पर्खनुहोस् र फेरि हेर्नुहोस्। चाहिएको स्थिर अवस्था भनेको proto ra ले चिन्हित पूर्वनिर्धारित मार्ग हो जसको expires मान बारम्बार रिसेट हुन्छ, साथै all.forwarding=1। यदि expires उल्टो गणना मात्र गरिरहेको छ भने विज्ञापनहरू अझै कतै खारेज भइरहेका छन्, र सामान्य दोषी त्यो सञ्जाल प्रबन्धक हो जसले बुटको बेलाको sysctl चलिसकेपछि accept_ra फेरि लेख्छ।

यो बन्द गर्नुअघि चार कुरा पुष्टि गर्नुहोस्: पूर्वनिर्धारित मार्ग proto ra छ र नवीकरण भइरहेको छ, accept_ra=2 अपलिङ्कमा मात्र लागू हुन्छ, रिबुटपछि र प्रबन्धक रिस्टार्ट गरेपछि पनि फर्वार्डिङ 1 छ, र IPv6 पिंग ग्राहकले पूरा गर्छ, गेटवेले होइन। स्वस्थ मार्ग हुँदाहुँदै पनि ग्राहक असफल भइरहे अर्को शंकास्पद फर्कने बाटो वा माथिल्लो फायरवाल हो, विज्ञापन होइन।