VPN மூலம் IPv6 link-local வேலை செய்யவில்லை: fe80 இணைப்பில் நிற்பது ஏன்
fe80:: முகவரிக்கு ஒரே இணைப்பில் மட்டுமே பொருள். ரூட் செய்யப்பட்ட VPN அதை ஏன் எடுத்துச் செல்ல முடியாது, தோல்வி எப்படித் தோன்றும், அதற்குப் பதிலாக எந்த முகவரியைப் பயன்படுத்த வேண்டும் என்பதைப் பாருங்கள்.
நீங்கள் சுரங்கப்பாதையை உயர்த்தி, சுரங்கப்பாதையை மூல இடைமுகமாகப் பயன்படுத்தி fe80::1-ஐ ping செய்கிறீர்கள், எதுவும் திரும்பி வரவில்லை. இது நீங்கள் மறந்த firewall விதி அல்ல. Link-local முகவரி அது உருவான அந்த ஒரே இணைப்பில் மட்டுமே பொருள் கொள்ளும், ரூட் செய்யப்பட்ட VPN அந்த இணைப்பு அல்ல. தொலை ரவுட்டரின் fe80::1 தொலை LAN பிரிவில் உள்ளது; நீங்கள் வேறொரு பிரிவில் ஒரு ஹாப் தொலைவில் இருக்கிறீர்கள், மேலும் IPv6-ல் ரவுட்டர் link-local பாக்கெட்டுகளை அனுப்புவதற்கான எந்த வழிமுறையும் இல்லை.
fe80 முன்னொட்டு ஒரு வரம்பை விவரிக்கிறது, ஒரு எல்லையை அல்ல
Link-local unicast என்பது fe80::/10, வரையறுக்கும் பண்பு எண் அல்ல, வரம்பு. முகவரி ஒரு இணைப்பில் மட்டுமே செல்லுபடியாகும், ஒவ்வொரு இடைமுகமும் தன் அடையாளத்திலிருந்து ஒன்றை உருவாக்குகிறது, அதனால் தொடர்பில்லாத இரு வலையமைப்புகளில் உள்ள தொடர்பில்லாத இரு இயந்திரங்கள் எந்த மோதலும் இல்லாமல் இரண்டும் fe80::1-க்கு பதிலளிக்க முடியும். முன்னொட்டு அடிப்படையில் “ஏதோ ஒரு இணைப்பில்” என்று கூறுகிறது; இணைப்பு தானே சூழலில் இருந்து வருகிறது.
ஒரு ஹோஸ்ட்டில் அந்த சூழல், சதவீதக் குறியின் பின் நீங்கள் சேர்க்கும் மண்டலம் அல்லது scope ID: Linux-ல் fe80::1%eth0, Windows-ல் மற்றும் இடைமுக குறியீடுகளைக் காட்டும் கருவிகளில் fe80::1%3 அல்லது fe80::1%12. கர்னல் முகவரியை இடைமுக குறியீட்டுடன் சேர்த்துத் தீர்த்து பிறகு அனுப்புகிறது. மண்டலத்தை நீக்கினால் இலக்கு தெளிவற்றதாகும், எனவே ஸ்டாக்கிற்கு ஒரு பிரிவைத் தேர்ந்தெடுக்க வழியில்லை.
ரூட் செய்யப்பட்ட சுரங்கப்பாதை அதை ஏன் வழங்க முடியாது
ரூட் செய்யப்பட்ட VPN என்பது தன் சொந்த முகவரிகளைச் சுமக்கும் புள்ளி-க்கு-புள்ளி இடைமுகம், பொதுவாக சுரங்கப்பாதைக்குள் unique-local அல்லது தனிப்பட்ட IPv6 இடத்தின் /64. தொலை LAN ஒரு தனி இணைப்பு, சுரங்கப்பாதையின் முனை உங்கள் சார்பாக ரூட் செய்து அனுப்புவதன் மூலம் அதை அடைகிறது. இவை இரு வெவ்வேறு பிரிவுகள், எனவே ஒன்றின் முகவரி மற்றொன்றில் செல்லுபடியாகும் இலக்கு அல்ல.
அனுப்பும் விதி தரத்தில் வெளிப்படையாக உள்ளது, இது உங்கள் கிளையண்டின் விசித்திரம் அல்ல: ரவுட்டர்கள் link-local மூலம் அல்லது இலக்கு கொண்ட பாக்கெட்டுகளை அனுப்புவதில்லை. அதனால்தான் ரூட் அட்டவணை சரியாகத் தோன்றினாலும் பாக்கெட் இறக்கிறது. fe80::/64-க்கு சுரங்கப்பாதை நோக்கி ஒரு ரூட்டைச் சேர்த்தால், தரத்திற்கு இணங்கும் ஸ்டாக் அதை நிராகரிக்கும் அல்லது ஏற்றுக்கொண்டு பொருந்தும் ஒவ்வொரு பாக்கெட்டையும் விட்டுவிடும்: இலக்கின் வரம்பு “இந்த இணைப்பு மட்டும்” என்கிறது, வெளிச்செல்லும் இடைமுகம் அந்த இணைப்பு அல்ல.
அண்டை கண்டறிதல் அதே எல்லையை வலுப்படுத்துகிறது. ஹோஸ்ட்கள் link-local அடுத்த ஹாப்களை 255 ஹாப் வரம்புடன் இணைப்பு வரம்பு multicast-க்கு அனுப்பப்படும் அண்டை கோரிக்கையால் தீர்க்கின்றன, எனவே ரவுட்டர்கள் அனுப்பப்படும் எதையும் நிராகரிக்க முடியும். இதை சுரங்கப்பாதை வழியாக வேலை செய்யவைப்பது தொலை பிரிவுக்கான கண்டறிதலை ப்ராக்ஸி செய்வதாகும், அது வேறு தொப்பி அணிந்த Layer 2 பாலம்.
இரண்டாவது, அமைதியான தோல்வி உள்ளது, அது ரூட்டை வலுக்கட்டாயமாகச் செலுத்த முயல்பவர்களைப் பிடிக்கிறது: மண்டலம். நீங்கள் உள்ளூரில் தட்டச்சு செய்யும் எந்த மண்டலமும் சுரங்கப்பாதை இடைமுகத்தைப் பெயரிடுகிறது, ஆனால் நீங்கள் விரும்பும் முகவரி தொலை LAN இடைமுகத்துடன் பிணைக்கப்பட்டுள்ளது. இரண்டும் ஒருபோதும் பொருந்தாது, எனவே பாக்கெட்டை தொலை முனையில் சரியான இடைமுகத்திற்குத் திருப்ப முடியாது.
நடைமுறையில் தோல்வி எப்படித் தோன்றும்
வரம்பு தவறுக்கான கருவி வெளியீடு ரூட்டிங் அல்லது firewall பிழை போலப் படிக்கப்படுகிறது, அதனால்தான் மக்கள் தவறான அடுக்கில் அரை நாள் கழிக்கிறார்கள்.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
மூன்றாவது வரி அதிக நேரத்தை வீணாக்குகிறது, ஏனெனில் வெளியீடு இல்லாத ssh கிளையண்ட் கேட்கும் சேவையின் சிக்கலாகத் தோன்றுகிறது. உள்ளே வர ஏதேனும் வழி இருந்தால், தொலைப் பக்கத்தைச் சரிபார்த்து sshd எல்லா முகவரிகளுடனும் பிணைந்துள்ளதா அல்லது ஒன்றுடன் மட்டுமா என்பதை உறுதிப்படுத்துங்கள்.
ரூட் செய்யவே உருவாக்கப்பட்ட முகவரியைப் பயன்படுத்துங்கள்
சுரங்கப்பாதை வழியாக அடைய வேண்டிய எல்லாவற்றுக்கும், சேவைக்கு அதே நோக்கத்திற்காகக் கொடுக்கப்பட்ட முகவரியைப் பயன்படுத்துங்கள்: உலகளாவிய unicast முகவரி, அல்லது fc00::/7-இலிருந்து unique-local முகவரி, இந்த உள் நிலைக்காகவே ஒதுக்கப்பட்ட வரம்பு. கேட்பவர் அதை உண்மையில் பிணைக்கிறாரா என்பதை உறுதிப்படுத்தி, திரும்பும் பாதை மற்றும் ஹோஸ்ட்டின் எந்த firewall விதியையும் சரிபார்க்கவும்.
யூகிப்பதற்குப் பதிலாக தொலை ஹோஸ்ட்டைப் பாருங்கள். ip -6 addr show உள்ள முகவரிகளைப் பட்டியலிடுகிறது, ss -6 -ltn டீமன் எதைக் கேட்கிறது என்பதைப் பட்டியலிடுகிறது. fe80:: உடன் மட்டும் பிணைந்த சேவை அதன் சொந்தப் பிரிவிலிருந்து மட்டுமே அணுகக்கூடியது, இது பொதுவாக யாரும் வேண்டுமென்றே தேர்ந்தெடுக்காத இயல்புநிலை மற்றும் நிர்வாகியின் ஒப்புதலுடன் மாற்றலாம்.
சேவையை உண்மையில் மீண்டும் பிணைக்க முடியாவிட்டால், பாலத்தை பிணைய அடுக்கிற்குப் பதிலாக பயன்பாட்டு அடுக்கிற்கு உயர்த்துங்கள். தொலை ஹோஸ்ட்டில் ரூட் செய்யக்கூடிய முகவரியில் கேட்டு link-local-உடன் இணைக்கும் ரிலே எந்தப் பிரிவையும் விரிவாக்காமல் சிக்கலைத் தீர்க்கிறது:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80இங்கே மண்டலம் சரியான பக்கத்தில், அந்த இணைப்பில் உண்மையில் eth0 உள்ள ஹோஸ்ட்டில் உள்ளது. உங்கள் கிளையண்ட் fd00:1:2::10-உடன் பேசுகிறது, அது சாதாரணமாக ரூட் செய்யப்படுகிறது, ரிலே link-local ஹாப்பை உள்ளூரில் செய்கிறது. அதே தந்திரம் ஒரு சாதனத்தின் வலை UI அல்லது link-local முகவரியை மட்டும் விளம்பரப்படுத்தும் பழைய BMC-க்கும் வேலை செய்கிறது.
பாலமிடுதல் உண்மையில் பதிலாக இருக்கும்போது, எதைச் சரிபார்க்க வேண்டும்
சில பயன்பாடுகளுக்கு உண்மையில் ஒரு பகிரப்பட்ட பிரிவு தேவை: link-local கண்டறிதலை மட்டும் பேசும் சாதனம், multicast-ஐச் சார்ந்த உபகரணம், தட்டையான LAN-ஐ மீண்டும் உருவாக்கும் ஆய்வகம். இது Layer 2 சிக்கல், அதற்கு Layer 2 பதில் தேவை, எடுத்துக்காட்டாக தொலை இடைமுகத்துடன் பாலமிடப்பட்ட tap சாதனம் அல்லது வெளிப்படையான பாலம் பயன்முறை கொண்ட கிளையண்ட் தயாரிப்பு. இதற்கு சுரங்கப்பாதையைக் கடக்கும் broadcast மற்றும் multicast போக்குவரத்து மற்றும் முனையிலிருந்து முனை வரை வேலை செய்ய வேண்டிய அண்டை கண்டறிதல் செலவாகும்.
ரூட் செய்யப்பட்ட சுயவிவரத்தில் fe80::/64 சேர்த்து இதை அணுக வேண்டாம். அது மிக மோசமான நிலையை உருவாக்குகிறது: கட்டமைப்பு முடிந்ததுபோல் தெரிகிறது, ரூட் அட்டவணை ஒரு உள்ளீட்டைக் காட்டுகிறது, ஒவ்வொரு பாக்கெட்டும் சரியாக நடந்துகொள்ளும் இரு ஸ்டாக்குகளுக்கு இடையே எங்கோ வீசப்படுகிறது.
ping-க்குப் பதிலாக இடைமுகத்துடன் சரிபார்க்கவும். ip -6 addr show tun0 சுரங்கப்பாதை இணைப்பு தன் சொந்த link-local முகவரியை உருவாக்கியதா என்பதைச் சொல்கிறது, ip -6 route get fe80::1%tun0 வரம்புள்ள இலக்குடன் கர்னல் உண்மையில் என்ன செய்யும் என்பதைச் சொல்கிறது. அந்த இடைமுகத்தில் இலக்கை அடைய முடியாது என்று கர்னல் சொன்னால், எந்த சுரங்கப்பாதை அமைப்பும் அதை மாற்றாது, சுயவிவரத்தைத் திருத்துவதை நிறுத்த வேண்டிய நேரம்.
கேள்வியைத் தீர்க்கும் சிறு வரிசை:
- தொலை ஹோஸ்ட்டில் முகவரியைப் படித்து அது fe80:: ஆகவோ அல்லது ரூட் செய்யக்கூடிய முன்னொட்டாகவோ இருக்கிறதா என்பதைக் கவனியுங்கள்.
- அது fe80:: என்றால், சேவையை மீண்டும் பிணையுங்கள், அந்த ஹோஸ்ட்டில் ரிலே செய்யுங்கள், அல்லது பிரிவைப் பாலமிடுங்கள்; ரூட் செய்யக்கூடியது என்றால், ரூட், firewall அல்லது பிணைப்பு முகவரியைச் சரிசெய்யுங்கள்.
- மீண்டும் சோதிக்கும் ஒவ்வொரு முறையும் மண்டலத்தை மீண்டும் சரிபார்க்கவும், ஏனெனில் நகலெடுக்கப்பட்ட கட்டளை பொதுவாக தவறான இடைமுகத்தை வைத்திருக்கும்.
மூலங்கள்: RFC 4291, IPv6 முகவரி கட்டமைப்பு.