தளம்-தளம் VPN வழியாக IPv6 முன்னொட்டு ஒப்படைப்பு: சரிபார்ப்புப் பட்டியல்

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

சுரங்கப்பாதையைத் தொடுவதற்கு முன் முன்னொட்டு வரைபடத்தை எழுதுங்கள்

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

ஒவ்வொரு தளத்திற்கும் ஒப்படைக்கப்பட்ட முன்னொட்டு, LAN-இல் உண்மையில் பயன்படுத்தப்படும் /64, சுரங்கப்பாதை முகவரிகள் மற்றும் ஒவ்வொரு வழித்தடத்தின் உரிமையாளரையும் பதிவு செய்யுங்கள். வழங்குநர் தளம் A-க்கு 2001:db8:a1::/56 ஒப்படைக்கிறார், அது தனது LAN-இல் 2001:db8:a1:10::/64-ஐ வழங்குகிறது; தளம் B 2001:db8:b2::/64-ஐ வைத்திருக்கிறது. தளம் A அந்த ஒரு /64-ஐ மட்டுமே வழங்கினால், இரு முனைகளும் முழு /56-க்குப் பதிலாக 2001:db8:a1:10::/64-ஐக் குறிப்பிட வேண்டும்.

கிட்டத்தட்ட எப்போதும் இரண்டு தவறுகள் தோன்றும். ஒன்று தொலை முன்னொட்டை on-link ஆகக் கருதி, அதை பிரிட்ஜ் செய்வது அல்லது சுரங்கப்பாதை இடைமுகத்தில் வைப்பது, அதனால் கேட்வே தான் அடைய முடியாத ஹோஸ்ட்களுக்கான அண்டை கோரிக்கைக்கு பதிலளிக்கிறது. மற்றொன்று ஒரே ஒரு /64 மட்டும் அமைக்கப்பட்டிருக்கும்போது முழு /56-ஐ விளம்பரப்படுத்துவது: வழித்தட அட்டவணை தொகுதி அடையக்கூடியது எனக் கூறுகிறது, பெரும்பாலான முகவரிகள் கருங்குழிக்குள் விழுகின்றன.

இரு முனைகளின் டிராஃபிக் தேர்விகளை வழித்தடங்களுடன் பொருத்துங்கள்

IKEv2 மற்றும் WireGuard இரண்டும் பொருந்தாத டிராஃபிக்கை நிராகரிக்கின்றன, சுரங்கப்பாதை இன்னும் ஆரோக்கியமாகத் தெரியும் அளவுக்கு அமைதியாக.

strongSwan-இல் தேர்விகள் வெளிப்படையானவை. தளம் A-இல்:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

தளம் B-இன் conn இரண்டு துணை வலைப்பிணைப்புகளையும் பிரதிபலிக்கிறது. அவை பொருந்தாதபோது, பதிலளிப்பவர் CHILD_SA-ஐ TS_UNACCEPTABLE உடன் நிராகரிக்கிறார், எனவே IKE_SA எழுந்தாலும் child SA ஒருபோதும் எழாது. இரு பக்கங்களிலும் அமைக்கப்பட்ட துணை வலைப்பிணைப்பு, உள்ளூர் கர்னல் சுரங்கப்பாதை நோக்கி வழித்தடம் செய்வதற்குச் சமமாக இருக்க வேண்டும்.

WireGuard அதே தகவலை AllowedIPs-இல் கொண்டு செல்கிறது, ஒரு திருப்பத்துடன்: AllowedIPs பெறும்போது மூல வடிகட்டி, அனுப்பும்போது வழித்தடம். தளம் B-இன் தளம் A-க்கான peer பதிவு 2001:db8:a1:10::/64-ஐ விட்டுவிட்டால், தளம் A-இலிருந்து வரும் பாக்கெட்டுகள் செல்லுபடியாகும் handshake-இல் வந்து அனுமதிக்கப்படாதவை எனத் தள்ளப்படும். அதனால் handshake மட்டுமே திரும்பத் திரும்ப புதுப்பிக்கப்படும், பதில் ஒருபோதும் வெளியேறாத பரிச்சயமான முறை உருவாகிறது. இரு முனைகளையும் wg show wg0 allowed-ips உடன் ஒப்பிடுங்கள். ஒப்படைப்பு மாறும்போதெல்லாம் அந்தப் பட்டியலை மீண்டும் சரிபார்க்கவும்; பழைய /64 அமர்வை உயிர்ப்புடன் வைத்து புதிய முன்னொட்டை அடைய முடியாததாக்குகிறது.

முதலில் அனுப்புதல், ஃபயர்வால் மற்றும் MTU-ஐ விலக்குங்கள்

மற்றொரு பதிவு வரியைப் படிக்கும் முன் கேட்வேகள் உண்மையில் அனுப்புகின்றனவா என்பதை உறுதிப்படுத்துங்கள். sysctl net.ipv6.conf.all.forwarding இரண்டிலும் 1-ஐத் திருப்பித் தர வேண்டும், சுரங்கப்பாதை மற்றும் LAN இடைமுகங்களுக்கும் பயன்படுத்தப்பட வேண்டும். ஒரு பொறியும் உள்ளது: அனுப்புதல் இயக்கப்பட்டதும் accept_ra=1 உள்ள இடைமுகம் வழங்குநரின் ரவுட்டர் அறிவிப்புகளை ஏற்பதை நிறுத்துகிறது, எனவே சுரங்கப்பாதைக்குள் சரியாக வழித்தடம் செய்தாலும் இயந்திரம் அதன் மேல்நிலை இயல்புநிலை பாதையை இழக்கலாம். வழங்குநரின் RA இன்னும் தேவைப்படும் இடத்தில் accept_ra=2 அமைக்கவும்.

பின்னர் ஃபயர்வால் விதிகள் முன்னொட்டை இரு திசைகளிலும் அனுமதிக்க வேண்டும், ICMPv6 உயிர்பிழைக்க வேண்டும்: அண்டை கண்டறிதல், packet-too-big மற்றும் destination-unreachable விருப்பத்தேர்வல்ல. அவற்றை விட்டுவிட்டால் பாதையின் MTU கண்டறிதல் உடையும், திறந்து பின்னர் முதல் பெரிய பதிலில் நிற்கும் இணைப்புகள் கிடைக்கும். குறைந்தபட்ச விதி இணை இப்படி இருக்கும்:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU இதற்குப் பின்னால் உள்ளது. சுரங்கப்பாதை பயன்படுத்தக்கூடிய MTU-ஐ 1500-க்குக் கீழே குறைக்கிறது, IPv6 ஒவ்வொரு இணைப்பும் குறைந்தது 1280-ஐக் கொண்டு செல்ல வேண்டும் எனக் கோருகிறது. சிறிய பிங்குகள் கடக்கின்றன, SSH அமர்வு பெரிய வெடிப்பில் உறைகிறது, /proc/net/snmp6 ஒருபோதும் திரும்பாத packet-too-big செய்திகளைக் காட்டுகிறது. சுரங்கப்பாதையின் MTU-ஐ வெளிப்படையாக அமைக்கவும், அல்லது mangle அட்டவணையில் TCP MSS-ஐ வரம்பிடவும், சிறிய MTU-ஐத் தெரிவிக்கும் ICMPv6 திரும்ப வர அனுமதிக்கவும்.

சுரங்கப்பாதை முகவரியல்ல, திரும்பும் பாதையைச் சோதியுங்கள்

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

இரண்டு கட்டளைகள் பெரும்பாலானதைத் தீர்க்கின்றன. தளம் A-இல் ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 அந்த மூலத்திலிருந்து வரும் பதில் எந்த இடைமுகத்தைப் பயன்படுத்தும் எனக் காட்டுகிறது; தளம் B-இல் கண்ணாடி சரிபார்ப்பைச் செய்யுங்கள். பின்னர் கேட்வே அல்ல, ஹோஸ்ட்டிலிருந்து டிராஃபிக்கை உருவாக்கி இரு முனைகளின் கணக்குகளையும் ஒப்பிடுங்கள்.

தொலை முன்னொட்டிற்கான அண்டை கோரிக்கை சுரங்கப்பாதையில் தோன்றினால், அந்த முன்னொட்டு இருக்கக்கூடாத இடத்தில் on-link ஆக உள்ளது; வழித்தடங்களைச் சரிசெய்வதற்கு முன் அதைச் சரிசெய்யுங்கள். Proxy NDP பிரிட்ஜிங் உண்மையில் தேவைப்படும் நிகழ்வுகளை உள்ளடக்குகிறது, வழித்தடத்திற்கு மாற்று அல்ல.

முன்னொட்டு உங்கள் கீழ் மாறுவதைத் திட்டமிடுங்கள்

முன்னொட்டு ஒப்படைப்பு ஒப்படைக்கும் மற்றும் கோரும் ரவுட்டர்களுக்கு இடையிலான குத்தகை, மேலும் புதுப்பித்தல் வேறு தொகுதியைத் தரலாம்: வழங்குநர் இடம்பெயர்ந்த பிறகு வேறு /56, அல்லது சுரங்கப்பாதை இருந்த காலத்தை விடக் குறுகிய குத்தகை. பழைய முன்னொட்டைக் குறிப்பிடும் ஒவ்வொரு இடமும் ஒரே நேரத்தில் பழையதாகிறது: வழித்தடங்கள், தேர்விகள், AllowedIPs, ஃபயர்வால் விதிகள், DNS பதிவுகள் மற்றும் நேரடி முகவரிகளை hardcode செய்யும் எந்தக் கண்காணிப்பும். செய்தி ஓட்டம் RFC 8415-இல் உள்ளது.

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

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