OpenVPN ஆய்வகத்தில் தனிப்பட்ட IPv6 சேர்ப்போம், ஒரு நேரத்தில் ஒரு சரிபார்ப்பு புள்ளி

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

முதல் சரிபார்ப்புப் புள்ளி: ஏற்கனவே செயல்படும் இணைப்பு

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

நீங்கள் ஏற்கனவே நம்பியிருக்கும் தொகுப்பு, இடவியல் மற்றும் தள்ளப்பட்ட வழிகளைக் குறித்துக்கொள்ளுங்கள். IPv6 வேலை அந்த அமைப்பை விரிவாக்குகிறது; மாற்றாது.

இரண்டாவது சரிபார்ப்புப் புள்ளி: உட்புற முன்னொட்டுகளைத் தேர்ந்தெடுங்கள்

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

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

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

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

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

நான்காவது சரிபார்ப்புப் புள்ளி: முன்னனுப்பல் மற்றும் பதில் வழி

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

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

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

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

ஐந்தாவது சரிபார்ப்புப் புள்ளி: வாடிக்கையாளரைப் படித்து, பின்னர் பரிசோதிக்கவும்

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

சுரங்கப்பாதையைத் தேர்ந்தெடுக்கும் வழி, பாக்கெட்டை எங்கு அனுப்புவது என்பதை வாடிக்கையாளர் அறிவார் என்பதை நிரூபிக்கிறது. ஆனால் சேவையகம் அதை முன்னனுப்புகிறது, LAN வழியமைப்பானிடம் திரும்பும் வழி உள்ளது, அல்லது பயன்பாட்டுக்குப் பதிலளிக்க அனுமதி உள்ளது என்பதை நிரூபிக்காது.

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

IPv6 பாதை முதல் முதல் இறுதி வரை பதிலளித்த பிறகே AAAA பதிவை வெளியிடுங்கள். IPv4 வழியாகக் கேட்கப்பட்ட DNS இன்னும் IPv6 முகவரியைத் திருப்பித் தரலாம், எனவே தீர்க்கக்கூடிய பெயர் ஏதோ கேட்பதற்கான சான்று அல்ல. RFC 4193 ULA வழிகாட்டுதல் இந்த முன்னொட்டுகளை நகல் அல்ல, உங்களதாக்கும் உலகளாவிய ID உருவாக்கத்தை உள்ளடக்குகிறது.