OpenVPN சுரங்கப்பாதை வழியாக IPv6: வீட்டு ரவுட்டருக்கான படிப்படியான வழிகாட்டி

மடிக்கணினியில் IPv6 முகவரி உள்ளது, சுரங்கப்பாதை IPv4 மேல் இயங்குகிறது, இருந்தும் ஒவ்வொரு IPv6 சோதனையும் தோல்வியடைகிறது. அல்லது மோசமாக: சோதனை வெற்றியடைகிறது மற்றும் போக்குவரத்து சுரங்கப்பாதைக்குள் நுழையாமலேயே ISP பாதை வழியாக வெளியேறுகிறது. இரண்டு முடிவுகளும் ஒரே காணாமல் போன முடிவுக்குத் திரும்புகின்றன: யாரும் ரவுட்டருக்கு வாடிக்கையாளர்களை நோக்கி வழிமாற்றக்கூடிய முன்னொட்டைக் கொடுக்கவில்லை. வாடிக்கையாளரிடமிருந்து வெளிப்புறமாகப் பாதையை நடந்தால் எந்தப் பகுதி காணாமல் உள்ளது என்பது தெரியும்.

வாடிக்கையாளர் இருக்கும் இடத்திலிருந்து தொடங்குங்கள்

சேவையகத்தைத் தொடுவதற்கு முன் வாடிக்கையாளரைப் பாருங்கள். ip -6 addr குளத்திலிருந்து சுரங்கப்பாதை முகவரியைக் காட்ட வேண்டும், ip -6 route சுரங்கப்பாதை சாதனத்தை நோக்கிக் காட்டும் தள்ளப்பட்ட முன்னொட்டைக் காட்ட வேண்டும். முகவரி இருந்து பாதை இல்லாவிட்டால், தள்ளல் காணாமல் உள்ளது அல்லது வாடிக்கையாளர் அதைப் புறக்கணித்தார். இரண்டும் இல்லாவிட்டால், சேவையகம் எதையும் ஒதுக்கவில்லை.

பின்னர் வாடிக்கையாளர் வெளி உலகைப் பற்றி என்ன நினைக்கிறார் என்பதைப் பாருங்கள். சுரங்கப்பாதை வழியாக இயல்புநிலைப் பாதை அனைத்து IPv6 போக்குவரத்தையும் கோருகிறது, ஆனால் 2000::/3-க்கான பாதை உலகளாவிய யூனிகாஸ்ட் மட்டுமே கோருகிறது. இரண்டும் சரியாக இருக்கலாம், அவை கசிவு பற்றி வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன.

எந்த IPv6 இயல்புநிலையும் இல்லாத வாடிக்கையாளர் சுரங்கப்பாதை முழுவதும் ஆரோக்கியமாக இருந்தாலும் ஒவ்வொரு பொதுச் சோதனையிலும் தோல்வியடைகிறார். அது கொள்கையின் இடைவெளி, உடைந்த சுரங்கப்பாதை அல்ல.

சேவையகம் உண்மையில் வழிமாற்றக்கூடிய குளத்தைச் சரிபார்க்கவும்

சேவையகம் தான் உண்மையில் கட்டுப்படுத்தும் முன்னொட்டிலிருந்து மட்டுமே ஒதுக்க முடியும். ISP ஒரு /56 ஒப்படைத்தால், சுரங்கப்பாதைக்கு ஒரு /64 ஒதுக்கி மீதியை LAN-க்கு விடுங்கள். ISP WAN-இல் ஒரு /64 மட்டுமே கொடுத்து மேலும் எதையும் வழிமாற்றவில்லை என்றால், LAN முன்னொட்டை அப்படியே விட்டு சுரங்கப்பாதைக்கு தனித்துவமான உள்ளூர் வரம்பைக் கொடுங்கள், வாடிக்கையாளர்களுக்கு உலகளாவிய வெளியேற்றம் இருக்காது என்பதை ஏற்றுக்கொண்டு.

குளமும் தள்ளலும் சேர்ந்தே செல்கின்றன. server-ipv6 2001:db8:80:10::/64 முகவரிகளை ஒதுக்குகிறது, push "route-ipv6 2000::/3" சுரங்கப்பாதைக்குள் என்ன அனுப்ப வேண்டும் என்பதை வாடிக்கையாளர்களுக்குச் சொல்கிறது. 2000::/3 தள்ளுவது உலகளாவிய யூனிகாஸ்ட்டை உள்ளடக்கி link-local மற்றும் multicast வரம்புகளை சுரங்கப்பாதைக்கு வெளியே வைக்கிறது.

தேர்ந்தெடுத்த முன்னொட்டை வரிசைப்படுத்தல் பதிவில் எழுதுங்கள். அடுத்த முறை ISP ஒப்படைப்பை மாற்றுபவர் சுரங்கப்பாதை ஏற்கனவே எந்த /64-ஐ ஆக்கிரமித்துள்ளது என்பதை அறிய வேண்டும்.

இரண்டாவது குடும்பத்திற்கு முன்னனுப்பலை இயக்குங்கள்

IPv4 முன்னனுப்பல் என்பது IPv6 முன்னனுப்பல் அல்ல. net.ipv6.conf.all.forwarding=1 அமைத்து IPv4 FORWARD கொள்கை ஏற்கனவே அனுமதிப்பதை எல்லாம் பிரதிபலிக்கவும். FORWARD சங்கிலி இயல்பாகவே நிராகரிக்கும் ரவுட்டரில், விடுபட்ட விதித்தொகுப்பு இறந்த சுரங்கப்பாதை போலவே தெரியும்.

கைக்குலுக்கல் வெற்றியடைகிறது, வாடிக்கையாளர் முகவரி பெறுகிறார், திரும்பி எதுவும் வரவில்லை. இரு திசைகளுக்கும் WAN பகுதிக்கும் விதிகளைச் சேர்க்கவும், ஏனெனில் LAN-ஐ அடைந்து இணையத்தை அடையாத சுரங்கப்பாதை மூன்றாவது சோதனையில் தோல்வியடையும். தோல்வியடைந்த முயற்சிக்குப் பிறகு சங்கிலியின் கணக்கிகளைப் பாருங்கள், ஏனெனில் ஒருபோதும் பொருந்தாத விதி பொருந்தி நிராகரித்த விதியை விட வேறு பிரச்சினை.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

ஒரு பக்கவிளைவு இறுதியில் சுரங்கப்பாதையைக் குறை சொல்பவர்களைப் பிடிக்கிறது. முன்னனுப்பலை இயக்கும்போது கர்னல் Router Advertisement வழியாக முகவரி கட்டமைப்பைத் தவிர்க்கிறது, வேறுவிதமாகச் சொல்லாவிட்டால், அப்படிக் கற்ற இயல்புநிலைப் பாதையும் அதனுடன் மறைகிறது. ஒன்று WAN இடைமுகத்தில் வெளிப்படையான இயல்புநிலைப் பாதையைப் பின்னுங்கள், அல்லது அங்கு வேண்டுமென்றே accept_ra-ஐ 2 ஆக அமைக்கவும். எந்த மாற்றத்திற்குப் பிறகும் வாடிக்கையாளர்களை மீண்டும் சோதிப்பதற்கு முன் ரவுட்டரிடம் இன்னும் பயன்படுத்தக்கூடிய IPv6 வெளிப்பாதை உள்ளதா என்பதை உறுதிப்படுத்தவும்.

மேல்பகுதி வழிமாற்றாதபோது அண்டை கண்டறிதலுக்குப் பதிலளியுங்கள்

மேல்பகுதி சாதனங்கள் சில நேரங்களில் ஒப்படைக்கப்பட்ட /64-ஐ தங்கள் சொந்த இணைப்புக்கு உரியதாகக் கருதி VPN பெட்டிக்கு எந்த துணைமுன்னொட்டையும் வழிமாற்ற மறுக்கின்றன. அப்படி நடக்கும்போது, ஒவ்வொரு வாடிக்கையாளர் முகவரிக்கும் தனித்தனியாக அண்டை கோரிக்கைகளுக்கு ஏதாவது பதிலளிக்க வேண்டும்.

OpenVPN ஒதுக்கப்பட்ட முகவரியை client-connect கொக்கிக்கு வெளிப்படுத்துகிறது, எனவே பதிவுகள் கையால் பராமரிக்கப்படும் பட்டியலுக்குப் பதிலாக உண்மையான குளத்தைப் பின்பற்றலாம். கொக்கி ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0-ஐச் சேர்க்கிறது, பொருந்தும் client-disconnect கொக்கி அதை அகற்றுகிறது. அகற்றாவிட்டால் ப்ராக்ஸி அட்டவணை பழையதாகி, பின்னர் வரும் வாடிக்கையாளர் தான் ஒருபோதும் பெறாத முகவரியின் பதிவை வாரிசாகப் பெறலாம். ip -6 neigh show proxy மூலம் நிலையை உறுதிப்படுத்தவும்.

ப்ராக்ஸியை தற்காலிகத் தீர்வாகக் கருதுங்கள். சுரங்கப்பாதையின் /64-க்கு ரவுட்டரை நோக்கிய நிலையான பாதை வாடிக்கையாளர் மாற்றங்களைத் தாங்கி, சிறப்புரிமை பெற்ற ஷெல் கொக்கி எதுவும் தேவைப்படாது.

வெளிப்புறமாகப் பாதையைப் பின்தொடருங்கள், ஒரு ஹாப் வீதம்

மூன்று படிகளில் வெளிப்புறமாகச் சோதிக்கவும்: முதலில் ரவுட்டரின் சுரங்கப்பாதை முகவரி, பின்னர் LAN புரவலன், மூன்றாவதாக traceroute6 வழியாக ஒரு பொது இலக்கு. குளத்தை முதலாவது நிரூபிக்கிறது, முன்னனுப்பலையும் LAN தீச்சுவரையும் இரண்டாவது, மேல்பகுதி வழியாகத் திரும்பும் பாதையை மூன்றாவது. ஒவ்வொரு தோல்வியும் முழு வடிவமைப்பையும் மீண்டும் திறப்பதற்குப் பதிலாகத் தேடலை ஒரு சாதனத்திற்குச் சுருக்குகிறது.

சுரங்கப்பாதையின் MTU-ஐக் கவனியுங்கள், ஏனெனில் பாதையில் உள்ள IPv6 ரவுட்டர்கள் உங்களுக்காகத் துண்டாக்காது. மிகப் பெரிய MTU தூய்மையான தோல்விக்குப் பதிலாக packet-too-big பிழையாகவும் நின்ற TLS ஆகவும் தோன்றும். அதை வெளிப்படையாக அமைத்து வரம்புக்கு அருகிலுள்ள சுமையுடன் சோதிக்கவும்.