இரண்டு தளங்களுக்கு இடையே இருக்கும் VPN வழியாக IPv6 வழியமைத்தல்

IPv4 மட்டுமே உள்ள WAN கூட உள்ளக IPv6-ஐ எடுத்துச் செல்லும். தேர்விகளை, கர்னல் வழித்தடங்களை, முன்னனுப்பலை மற்றும் பதில்களை அமைதியாக வீழ்த்தும் திரும்பு முன்னொட்டைக் கவனியுங்கள்.

இரண்டு தளங்களுக்கு இடையிலான சுரங்கப்பாதையில் IPv6 முன்னொட்டைச் சேர்க்கும்போது, படம் குறிப்பதுபோல் பாக்கெட் பயணிக்காது। உள்ளூர் நுழைவாயில் முழு IPv6 பாக்கெட்டையும் எடுத்து, அதை மறையாக்கி, முன்னால் ஒரு வெளிப்புற IP தலைப்பை வைக்கிறது; அதன் முகவரிக் குடும்பம் உள்ளே இருப்பதால் அல்ல, முனை முகவரிகளால் தீர்மானிக்கப்படுகிறது। தொலை நுழைவாயில் அந்த வெளிப்புற தலைப்பை நீக்கி மூல பாக்கெட்டைத் தன் LAN-க்கு அனுப்புகிறது; அங்கு அது மீண்டும் சாதாரண IPv6 பாக்கெட்। வெளிப்புறச் சுரங்கப்பாதையும் உள்ளகப் போக்குவரத்தும் ஒரு விசை, ஒரு முனை இணை மற்றும் வேறு எதையும் பங்கிடாத இரண்டு தனித்த உரையாடல்கள்।

இரண்டு தலைப்புகள், இரண்டு முகவரிக் குடும்பங்கள்

IPsec சுரங்கப்பாதை பயன்முறையில் உள்ளக IPv6 பாக்கெட் ESP தலைப்புக்குப் பின்னால் உள்ள சுமையாகிறது। அந்த ESP பாக்கெட்டைச் சுமக்கும் வெளிப்புற தலைப்பு IPv4 அல்லது IPv6 ஆக இருக்கலாம்; அது local_addrs மற்றும் remote_addrs-ஐப் பின்பற்றுகிறது। WireGuard இதையே குறைந்த சடங்குடன் செய்கிறது: உள்ளக பாக்கெட் என்பது சகாவின் முனைக்குச் செல்லும் UDP தரவுக்கிராம் சுமை। இரண்டும் உள்ளக தலைப்பைத் தொடாமல் விடுகின்றன; அதனால்தான் தொலைப் பக்கம் கவசம் நீக்கிய பின் அதை வழியமைக்க முடிகிறது।

தளங்களுக்கு இடையிலான பாதை IPsec NAT கடப்பைப் பயன்படுத்தும்போது UDP 4500-ஐ மட்டுமே காண்கிறது; இயல்புநிலை WireGuard கேட்பானுக்கு UDP 51820। பாதையில் எந்தத் திசைவியும் IPv4 மட்டுமாக இருக்கலாம்; IPv6 போக்குவரத்து என்றாலும் கடக்கிறது, ஏனெனில் அது அந்தப் பாதையில் ஒருபோதும் IPv6 பாக்கெட்டாகத் தோன்றுவதில்லை। அது தெளிவான முதல் பிரிவைத் தருகிறது: tcpdump -ni eth0 udp port 51820 மறையாக்கப்பட்ட பாதையைக் காட்டுகிறது, tcpdump -ni wg0 ip6 உள்ளகப் போக்குவரத்தைக் காட்டுகிறது। வெளிப்புறப் பதிவு பரபரப்பாகவும் உள்ளகப் பதிவு அமைதியாகவும் இருந்தால், கர்னல் IPv6-ஐச் சுரங்கப்பாதையில் போடவில்லை என்பது பொருள்; அது வழியமைப்பு அல்லது கொள்கை, இணைப்பு நிலை அல்ல।

நுழைவாயில் முன்னனுப்பும்போது உள்ளக Hop Limit-ஐயும் குறைக்கிறது; எனவே முனைகள் IPv6 பாதையில் திசைவிகளாகக் கணக்கிடப்படுகின்றன। வெளிப்புற ஹாப் எண்ணிக்கையும் உள்ளக Hop Limit-உம் தனித்தனியாக நகரும்; தொலை நுழைவாயிலில் இறக்கும் பாக்கெட் முன்னனுப்பலில் இறந்தது, மறையாக்கத்தில் அல்ல।

தேர்விகளும் AllowedIPs-உம் அனுமதிப் பட்டியல்

IKEv2, child SA எந்த உள்ளக முன்னொட்டுகளைச் சுமக்கலாம் என்பதைப் பேச்சுவார்த்தை செய்கிறது। strongSwan 5.9 மற்றும் அதற்குப் பின், அவற்றை swanctl.conf-இல் எழுதுவது இப்படி இருக்கும்:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

local_ts மற்றும் remote_ts-ஐ விட்டுவிட்டால் strongSwan அவற்றைத் தான் தேர்ந்தெடுக்கும் இடைமுகத்தின் துணை வலைகளிலிருந்து பெறுகிறது। இரட்டை அடுக்கு ஓம்புநரில் அந்தக் குறுக்குவழி பெரும்பாலும் IPv4 இணையை மட்டும் தருகிறது: SA மேலெழுகிறது, IPv6 ESP குறியீட்டை அடையும் முன் மறுக்கப்படுகிறது। இரண்டு முன்னொட்டுகளையும் எழுதுவது SA-ஐ அவற்றைச் சுமக்கத் தகுதியாக்குகிறது; start_action = trap முதல் பொருந்தும் பாக்கெட்டில் அதை மேலெழுப்புகிறது।

WireGuard-க்கு இரண்டு வேலை செய்யும் ஒரே பட்டியல் உள்ளது। சகா தொகுதியில் AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 அனுப்பும்போது நிறுவப்படும் வழித்தடமும் பெறும்போது பயன்படுத்தப்படும் வடிகட்டியும் ஆகும்: உள்ளக மூலம் அந்தச் சகாவின் பட்டியலுக்கு வெளியே விழும் மறைகுறியாக்கப்பட்ட பாக்கெட் அமைதியாக வீழ்த்தப்படுகிறது। wg-quick ஒவ்வொரு பதிவுக்கும் ஒரு வழித்தடத்தைச் சேர்க்கிறது; எனவே கீழே உள்ள சகா தொகுதிக்கு தனி ip -6 route கட்டளை தேவையில்லை।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

இரு பட்டியல்களும் கண்ணாடி போல இருக்க வேண்டும்: தளம் B, தளம் A-வின் முன்னொட்டைத் தொலைத் தேர்வியாக ஏற்று மீண்டும் வழியமைக்கிறது; இரு திசைகளும் ஒத்துக்கொண்டால் மட்டுமே சுரங்கப்பாதை இயங்கும்। சமச்சீரற்ற பட்டியல் அதிக நேரம் எடுக்கும் அறிகுறியைத் தருகிறது — ஆரோக்கியமான கைக்குலுக்கல், ஒரு பக்கத்தில் நகரும் எண்ணிகள், மற்றும் A-விலிருந்து B-க்கு வெற்றிகரமான ping, ஆனால் B-விலிருந்து எதுவும் A-ஐ அடையவில்லை।

முன்னனுப்பல், வழித்தடங்கள் மற்றும் திரும்பு முன்னொட்டு

நீங்கள் சொல்லாதவரை Linux IPv6-ஐ முன்னனுப்பாது; அமைப்பு இடைமுகத்துக்கு அல்ல, namespace-க்கு உரியது:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

இரண்டாவது வரிதான் வழித்தட அடிப்படையிலான வடிவமைப்புகளில் மக்கள் மறப்பது। கொள்கை அடிப்படையிலான IPsec முன்னொட்டுகளுடன் பொருந்தும் XFRM கொள்கையை நிறுவுகிறது; ஆனால் vti6 அல்லது WireGuard உள்ள வழித்தட அடிப்படையிலான அமைப்புக்கு அந்தச் சாதனத்தை நோக்கும் உண்மையான IPv6 வழித்தடம் தேவை। sysctl-ஐ /etc/sysctl.d/-இன் கீழ் நிலைத்திருக்கச் செய்யுங்கள்; இல்லையேல் மறுதொடக்கம் முன்னனுப்பலை அமைதியாக அணைத்து விடும்।

முன்னனுப்பலுக்கு தெரிந்துகொள்ளத் தகுந்த பக்கவிளைவு ஒன்று உண்டு: கர்னல் அப்போது திசைவி அறிவிப்புகளைப் புறக்கணிக்கும், net.ipv6.conf.<wan>.accept_ra 2 ஆக இல்லாவிட்டால்; எனவே WAN முகவரி SLAAC வழியாக வரும் நுழைவாயில், முன்னனுப்பலை இயக்கும் அந்தக் கணமே தன் இயல்புநிலை வழித்தடத்தை இழக்கலாம்। அதே கோப்பில் அந்த இடைமுகத்தில் accept_ra = 2-ஐ அமைக்கவும், வழித்தடம் தப்பிப் பிழைக்கும்। தளம் B-யின் உள்ளகமும் சுரங்கப்பாதை நுழைவாயிலிலிருந்து 2001:db8:aa::/48-ஐக் கற்க வேண்டும்; நிலையான வழித்தடம் அல்லது சுரங்கப்பாதையின் மேல் ஒரு வழியமைப்பு நெறிமுறை மூலம், இல்லையேல் பதில் B-யின் சொந்த வலையமைப்பிலேயே இறக்கும்।

முறிவை இடம் கண்டறியும் நான்கு படி சோதனை

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

  1. தேர்விகள்: swanctl --list-sas child SA-இல் IPv6 முன்னொட்டு இணையைக் காட்ட வேண்டும், அல்லது wg show wg0 allowed-ips தொலை முன்னொட்டைப் புதிய latest-handshakes-உடன்।
  2. கர்னல் வழித்தடம்: ip -6 route get 2001:db8:bb::10 சுரங்கப்பாதைச் சாதனத்துடன் பதிலளிக்க வேண்டும், WAN இடைமுகத்துடன் அல்ல।
  3. உள்ளகப் பதிவு: tcpdump -ni wg0 ip6 உண்மையான LAN ஓம்புநர்களுக்கு இடையே ping செய்யும்போது। வெளியேறும் பாக்கெட்டுகள் ஆனால் எதுவும் திரும்பாதது B-யின் வழித்தடத்தையோ தீச்சுவரையோ சுட்டுகிறது; மொத்தமாகப் பாக்கெட்டுகள் இல்லாதது படி 1 அல்லது 2-ஐ நோக்கித் திருப்புகிறது।
  4. இலக்கு: B ஓம்புநரில், ss -6 -ltn சேவை IPv6-இல் கேட்கிறது என்பதை உறுதிப்படுத்துகிறது; உள்ளூர் தீச்சுவர் எண்ணிகள் பாக்கெட் ஏற்கப்பட்டதா வீழ்த்தப்பட்டதா என்பதைக் காட்டுகின்றன।

MTU அதே சுற்றில் வருகிறது। IPv6 திசைவிகள் துண்டாக்குவதில்லை; எனவே மிகப் பெரிய பாக்கெட் வீழ்த்தப்பட்டு Packet Too Big அனுப்புநருக்குத் திரும்புகிறது। கைக்குலுக்கல்களும் சிறிய ping-களும் இயங்கி, கோப்புப் பரிமாற்றம் தேங்கினால், அது கடக்கும் வரை சுமையைக் குறைக்கவும்: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard இடைமுகங்களின் இயல்புநிலை MTU 1420 பைட்; IPv4-இன் மேல் IPsec மேலும் கழிக்கிறது, எனவே உள்ளக MTU-ஐ அமைப்பது ICMPv6-ஐ வீழ்த்தும் தீச்சுவர் வழியாகப் பாதை MTU கண்டறியலை எதிர்பார்ப்பதை விடச் சிறந்தது।

தீச்சுவர் பிரச்சினைகள் போல் தோன்றும் தோல்வி முறைகள்

மிகவும் பொதுவானது தீச்சுவரே அல்ல: சேவை ::-க்குப் பதிலாக 0.0.0.0-உடன் இணைகிறது; AAAA பதிவு உள்ளது; வாடிக்கையாளர் IPv6 வழியாக விரைவான மறுப்பைப் பெறுகிறார், அதை இரட்டை அடுக்கு உலாவி IPv4-க்குத் திரும்பி மறைக்கிறது। சில பயன்பாடுகள் மட்டும் தோல்வியடைந்தால், விதித் தொகுப்பைத் தொடுவதற்கு முன் கேட்கும் குடும்பத்தைச் சரிபார்க்கவும்।

இரண்டாவது ICMPv6 வடிகட்டல்। Neighbor Discovery-உம் Packet Too Big-உம் சாதாரண இயக்கத்தின் பகுதி, கண்டறிதலின் அல்ல; எல்லா ICMPv6-ஐயும் வீழ்த்தும் கொள்கை, இணைந்து, அங்கீகரித்து, பின்னர் சிறிய பாக்கெட்டை விடப் பெரிய எதிலும் தேங்கும் சுரங்கப்பாதையை உருவாக்குகிறது। பாதை சார்ந்த வகைகளை அனுமதித்து, வீழ்த்தல் தெரிய எண்ணிகளை இயக்கத்தில் விடுங்கள்।

மூன்றாவது, சுரங்கப்பாதையில் சேர்க்கப்படும் ஆனால் அதை உடைமையாகக் கொண்ட தளத்தின் முகவரித் திட்டத்தில் ஒருபோதும் சேர்க்கப்படாத முன்னொட்டு; எனவே எந்தத் திசைவியும் அதை அறிவிக்காது, எந்த ஓம்புநரும் அதிலிருந்து பதிலளிக்க முடியாது। ஒரு முன்னொட்டும் ஒரு ஓம்புநர் இணையும் கொண்டு தொடங்கி, இரு திசைகளையும் நான்கு படிகளால் நிரூபித்து, பின்னர் மீதியைச் சேர்க்கவும்; உடைந்த முன்னொட்டு மறுவடிவமைப்புக்குப் பதிலாக உள்ளமைப்பில் ஒரு வரியாகவே இருக்கும்। திறந்து வைக்கத் தகுந்த ஒரே அதிகாரப்பூர்வ ஆவணம் RFC 8200 ஆகும், அது சுரங்கப்பாதை சுமக்கும் தலைப்பை வரையறுக்கிறது।

தொடர்புடைய கட்டுரைகள்