VPN-ൽ IPv6 link-local പ്രവർത്തിക്കുന്നില്ല: fe80 ലിങ്കിൽ എത്തി നിൽക്കുന്നതെന്തുകൊണ്ട്
fe80:: വിലാസത്തിന് ഒരു ലിങ്കിൽ മാത്രമാണ് അർത്ഥം. റൂട്ട് ചെയ്ത VPN അത് എത്തിക്കാൻ കഴിയാത്തതെന്തുകൊണ്ട്, പരാജയം എങ്ങനെ കാണപ്പെടുന്നു, പകരം ഏത് വിലാസം ഉപയോഗിക്കണം എന്ന് കാണുക.
നിങ്ങൾ ടണൽ ഉയർത്തി, ടണൽ ഉറവിട ഇന്റർഫേസായി ഉപയോഗിച്ച് fe80::1-ലേക്ക് ping ചെയ്യുന്നു, പക്ഷേ ഒന്നും തിരികെ വരുന്നില്ല. ഇത് നിങ്ങൾ മറന്ന firewall നിയമമല്ല. Link-local വിലാസത്തിന് അത് രൂപപ്പെട്ട ഒരൊറ്റ ലിങ്കിൽ മാത്രമാണ് അർത്ഥം, റൂട്ട് ചെയ്ത VPN ആ ലിങ്കല്ല. ദൂരെയുള്ള റൗട്ടറിന്റെ fe80::1 ദൂരെയുള്ള LAN സെഗ്മെന്റിലാണ്; നിങ്ങൾ മറ്റൊരു സെഗ്മെന്റിൽ ഒരു ഹോപ്പ് അകലെയാണ്, കൂടാതെ റൗട്ടർ link-local പാക്കറ്റുകൾ കൈമാറാൻ IPv6-ൽ ഒരു സംവിധാനവുമില്ല.
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 വിലാസ ആർക്കിടെക്ചർ.