உங்கள் /64-ஐப் பிரிப்பது IPv6-ஐ VPN வாடிக்கையாளர்களுக்கு வழிமாற்றாது

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

புராணக்கதை: உங்கள் /64-இன் ஒரு பகுதி ஏற்கனவே அடையக்கூடியது

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

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

இதுவே முழுத் தோல்வி: முன்னோக்கிய திசை வேலை செய்கிறது, ஏனெனில் அதை உங்கள் சேவையகம் அனுப்புகிறது, திரும்பும் திசை ஒரு ஹாப் தூரத்தில் இறக்கிறது, ஏனெனில் வாடிக்கையாளர் இருப்பதை upstream ஒருபோதும் அறியவில்லை.

இணைப்பில் விநியோகம் உண்மையில் எதைக் கோருகிறது

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

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

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

வழிமாற்றப்பட்ட விநியோகம் எதைக் கோருகிறது

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

வழிமாற்றப்பட்ட விநியோகம் அண்டை கண்டுபிடிப்பின் கேள்வியை முழுமையாக நீக்குகிறது, எனவே எதையும் புத்திசாலித்தனமாகக் கட்டுவதற்கு முன் வழங்குநரிடம் அதைக் கேட்பது மதிப்புள்ளது. வழியை எழுத்துப்பூர்வமாகக் கேளுங்கள், அடுத்த ஹாப் upstream உண்மையில் அடையக்கூடிய முகவரி என்பதை உறுதிப்படுத்துங்கள்.

இரு வடிவமைப்புகளுக்கும் இன்னும் நுழைவாயிலில் IPv6 அனுப்புதல் இயக்கப்பட்டிருக்க வேண்டும், மேலும் இரு திசைகளிலும் அனுப்பப்பட்ட ஓட்டத்தை அனுமதிக்கும் ஃபயர்வால் விதிகள் தேவை. மீதமுள்ள பாதைக்கு விநியோகம் ஒரு முன்நிபந்தனை, மாற்று அல்ல. அனுப்புதல் அணைக்கப்பட்ட செயல்படும் வழி, வழியே இல்லாததைப் போலவே அதே மௌனத்தை உருவாக்குகிறது, எனவே எதையும் மீண்டும் வடிவமைக்கும் முன் இரண்டையும் சரிபார்க்கவும்.

சரிசெய்ய வேண்டிய இரண்டு சுயாதீன வழிகள்

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

நீங்கள் பயன்படுத்தும் எந்தக் கொள்கையின் கீழும் IPv6 சார்ந்த கட்டுப்பாட்டு போக்குவரத்தை இயக்கத்தில் வைத்திருங்கள். Packet Too Big செய்திகள் TCP மற்றும் UDP-க்கு மட்டும் அனுமதிக்கும் ஃபயர்வாலின் வழக்கமான பலி, அவற்றை நிராகரிப்பது நிறுவப்பட்ட பிறகு பெரிய பரிமாற்றங்களில் நிற்கும் இணைப்புகளை உருவாக்குகிறது.

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

மறுகட்டுமானம் அதை மீண்டும் உருவாக்கும் வகையில் வடிவமைப்பைப் பதிவு செய்யுங்கள்

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

பிறகு திரும்பும் திசையை வெளிப்படையாகச் சோதியுங்கள், வெளியிலிருந்து திரும்ப வேண்டிய பாக்கெட்டுடன். openvpn(8) கையேடு server-ipv6 மற்றும் redirect விருப்பங்களை உள்ளடக்கியது, உங்கள் வழங்குநரின் வழிமாற்ற உறுதிப்படுத்தல் கையேடு உள்ளடக்க முடியாத பாதியை உள்ளடக்குகிறது.