IPv4 VPN சேவையகம் வழியாக IPv6 சென்றாலும் உண்மையான IPv6 வெளியேற்றம் தேவை

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

அறிகுறி: முகவரி உள்ளது, வழி இல்லை

வாடிக்கையாளர் பக்க சரிபார்ப்பு சுரங்கப்பாதை சாதனத்தில் உலகளாவியதாகத் தெரியும் IPv6 முகவரியையும் அதை நோக்கிக் காட்டும் வழியையும் காட்டுகிறது, அதனால் இது தவறாக வாடிக்கையாளர் பிழையாகப் படிக்கப்படுகிறது. போக்குவரத்து சுரங்கப்பாதைக்குள் நுழைகிறது, சேவையகம் அதை டீகேப்சுலேட் செய்கிறது, பின்னர் பொதி அனுப்புநர் அட்டவணையில் உண்மையான இடத்திற்கு IPv6 இயல்புநிலை வழி இல்லாத ஹோஸ்டில் இறங்குகிறது. ஸ்டாக்கைப் பொறுத்து உடனடி அணுகமுடியாமை அல்லது அமைதியான நீக்கம் கிடைக்கும், இரண்டிலும் வாடிக்கையாளர் தீப்பிடிப்புச் சுவரைப் போலவே தெரியும் நேர முடிவைக் காண்கிறார்.

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

டீகேப்சுலேஷனுக்குப் பிறகு பொதியைப் பின்தொடருங்கள்

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

IPv4 மேல் IPv6 கேப்சுலேஷனின் இயங்குமுறை RFC 4213-ல் விவரிக்கப்பட்டுள்ளது, அங்குள்ள முக்கிய விவரம் என்னவென்றால் முனைகளுக்கு சுரங்கப்பாதையின் மறுபக்கத்தில் இன்னும் உண்மையான IPv6 இணைப்பு தேவை. தலைப்பைச் சுற்றுவதால் upstream மாயமாக உருவாகாது.

இரண்டு சுரங்கப்பாதை அடுக்குகள், இரண்டு சுயாதீன சரிபார்ப்புகள்

ஒவ்வொரு அடுக்கையும் தனித்தனியாகச் சரிபார்க்கவும், ஏனெனில் வேலை செய்யும் வெளி சுரங்கப்பாதை உடைந்த உள் சுரங்கப்பாதையை மறைக்கிறது. வெளி வழியை வாடிக்கையாளரிலிருந்து சேவையகத்திற்கு IPv4 ping மூலம் சரிபார்த்து நீங்கள் பயன்படுத்தும் துறையை உறுதிப்படுத்துங்கள். பின்னர் சேவையகத்தில் உள் வழியைச் சரிபார்க்கவும், அங்கு ip -6 route உண்மையான upstream-இல் இருந்து கற்ற இயல்புநிலை அல்லது குறிப்பிட்ட வழியைக் காட்ட வேண்டும், மேலும் ip -6 addr upstream ஏற்கும் மூல முன்னொட்டைக் காட்ட வேண்டும். அதை விடக் குறைவானது இடைமுகத்தில் உள்ள அலங்காரம் மட்டுமே.

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

அதே விஷயம் வாடிக்கையாளருக்கும் பொருந்தும்: ip -6 route get 2001:4860:4860::8888 சுரங்கப்பாதை சாதனத்தைக் குறிப்பிட வேண்டும், அது இயற்பியல் சாதனத்தைக் குறிப்பிட்டால், வாடிக்கையாளர் IPv6-க்கு VPN-ஐ சிறிதும் பயன்படுத்தவில்லை.

மூல முன்னொட்டு, அளவு மற்றும் ICMPv6

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

உங்கள் ஸ்டாக் உண்மையில் பயன்படுத்தும் கூடுதல் கேப்சுலேஷனுக்கு நிதி ஒதுக்குங்கள், Packet Too Big உட்பட ICMPv6-ஐ இயங்கச் செய்யுங்கள். இரண்டாவது தலைப்பு பயன்படுத்தக்கூடிய சுமையைக் குறைக்கிறது, எனவே சிறிய ping-களுக்குப் பதிலளிக்கும் வழியும் கோப்பு பரிமாற்றத்தில் தோல்வியடையலாம், எல்லா ICMPv6-ஐயும் தூக்கி எறியும் தீப்பிடிப்புச் சுவர் சரிசெய்யக்கூடிய அளவுப் பிரச்சினையை கருங்குழியாக மாற்றுகிறது. சேவையை அறிவிக்கும் முன் ஒரு பெரிய பரிமாற்றத்தைச் சோதியுங்கள்.

எது முற்றிலும் வேறு பிரச்சினை

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

சேவையகத்திற்கு பயன்படுத்தக்கூடிய IPv6 upstream இல்லையென்றால், தேர்வுகள் ஆதரிக்கப்படும் upstream, வேறு வெளியேற்றம், அல்லது IPv6 சுரங்கப்பாதைக்கு வெளியே இருக்கும் என்பதற்கான ஆவணப்படுத்தப்பட்ட முடிவு. ஏற்றுக்கொள்ள முடியாதது என்னவென்றால், IPv6 சேவை உள்ளது என்று வாடிக்கையாளர்களிடம் சொல்வது, அதே நேரத்தில் அவர்களின் சாதாரண IPv6 இணைப்பு அமைதியாக VPN-ஐத் தவிர்க்கிறது.