உங்கள் IPv6 சுரங்கப்பாதையின் மறுமுனைக்கு ping தோல்வியா? :: முகவரியைச் சரிபார்க்கவும்

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

முகவரியைச் சுட்டிக்காட்டும் அறிகுறி

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

பூஜ்ஜிய அடையாளங்காட்டி anycast ஆக ஒதுக்கப்பட்டுள்ளது

RFC 4291 பூஜ்ஜிய இடைமுக அடையாளங்காட்டியை subnet-router anycast முகவரியாக வைத்திருக்கிறது, எனவே 2001:db8:4a::/64 போன்ற /64 ஒன்றில் 2001:db8:4a:: இல் பயன்படுத்தக்கூடிய முனை எதுவும் இல்லை. இந்த ஒதுக்கீட்டிற்கு அதன் இடம் உண்டு: router advertisements மற்றும் neighbour discovery அந்த வடிவத்தை அழைக்கின்றன, வழிமாற்றி தான் வழங்கும் முன்னொட்டிற்குப் பதிலளிக்கிறது. அந்த மதிப்பை சுரங்கப்பாதை முனைக்கு வழங்குவது வழிமாற்றி பாத்திரத்தை ஒரு இலையிடம் ஒப்படைக்கிறது, அதனால்தான் எதுவும் திரும்பி வரவில்லை. முன்னொட்டில் உள்ள வேறு எந்த அடையாளங்காட்டியும் முனையாகச் செயல்படுகிறது, எனவே சரிசெய்தல் பொதுவாக ஒரு இலக்கம்.

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

முனை முகவரிகளை வழங்கி முன்னொட்டை வழிமாற்றுங்கள்

இரண்டு முனைகளுக்கும் ::1 மற்றும் ::2 தேர்ந்தெடுத்து, ip -6 addr add 2001:db8:4a::2/64 dev tun0 மூலம் ஒன்றைச் சேர்த்து, பின்னர் அதை முகவரியிட முயல்வதற்குப் பதிலாக தொலை முன்னொட்டை வழிமாற்றுங்கள். சுரங்கப்பாதையிலிருந்து வெளியே 2001:db8:4a::/64 க்கான வழி தொலைப் பக்கத்தை அணுகக்கூடியதாக்குகிறது; முகவரி மட்டும் உள்ளூர் இடைமுகத்தை அமைக்கிறது.

முழு சுரங்கப்பாதைக்கு மூன்றாவது படி உள்ளது, சாதனம் வழியாக உலகளாவிய unicast க்கான இயல்புநிலை வழி, அது எல்லாவற்றையும் சுரங்கப்பாதைக்குள் அனுப்புவதற்கான IPv6 சமனாகும். அதைத் தவிர்த்தால், IPv4 சுரங்கப்பாதைக்குள் பயணிக்கும்போது IPv6 இயற்பியல் இணைப்பைத் தொடர்ந்து பயன்படுத்துகிறது, எனவே முனை மூடப்பட்டதாக நீங்கள் நம்பிய போக்குவரத்தையே வெளியேற்றுகிறது. ip -6 route get 2001:4860:4860::8888 மூலம் உறுதிப்படுத்தி, பதிலை ஊகிப்பதற்குப் பதிலாக அது குறிப்பிடும் சாதனத்தைப் படியுங்கள்.

Multicast வழிமாற்றத்திற்கு முன்பே மறுக்கப்படுகிறது

Android VpnService.Builder க்கான முகவரிகள் மற்றும் வழிகளை LinkAddress வழியாகச் சரிபார்க்கிறது, அந்தக் கட்டுப்படுத்தி multicast ஐ முற்றிலும் மறுக்கிறது. அதற்கு வழியாக multicast முன்னொட்டைக் கொடுத்தால் முடிவு ஒரு வழிக்குப் பதிலாக bad LinkAddress parameters தோல்வியாகும், அது பிணையப் பதிலல்ல, சரிபார்ப்புப் பதில். மறுப்பு ஊடகத்திற்குப் பொருந்துகிறது: புள்ளி-முதல்-புள்ளி tun சாதனத்திற்கு link-layer multicast இல்லை, எனவே அதில் குழு வழிக்கு நிறுவ எந்த விநியோக மாதிரியும் இல்லை. குழு முகவரிகள் stack ஆல் உருவாக்கப்பட்டு நுகரப்படுகின்றன, கையால் அமைக்கப்படுவதில்லை.

IPv6 all-nodes மற்றும் solicited-node முகவரிகள் அதே விதியின் கீழ் வருகின்றன. stack அவற்றை அங்கு வைத்ததால் இடைமுகம் அவற்றைத் தாங்குகிறது, ஏதேனும் கொள்கை அவற்றை நோக்கியதால் அல்ல.

அதற்குப் பதிலாக சுரங்கப்பாதை எதைக் கொண்டு செல்ல முடியும்

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

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

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

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

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