Linux-ൽ ഫോർവേഡിംഗ് ഓണാക്കിയതിന് ശേഷം IPv6 ഡിഫോൾട്ട് റൂട്ട് അപ്രത്യക്ഷമായി

IPv6 ഫോർവേഡിംഗ് ഓണാക്കുമ്പോൾ കെർണൽ അപ്ലിങ്കിൽ router announcements അവഗണിക്കുന്നു, പഠിച്ച ഡിഫോൾട്ട് റൂട്ട് കാലഹരണപ്പെടുന്നു. accept_ra ഉപയോഗിച്ച് ശരിയാക്കുക.

VPN ക്ലയന്റുകളുടെ ട്രാഫിക് കൈമാറാൻ ഞാൻ ഒരു Debian ഗേറ്റ്‌വേയിൽ net.ipv6.conf.all.forwarding=1 സജ്ജമാക്കി, ഏകദേശം അര മണിക്കൂർ കഴിഞ്ഞപ്പോൾ യന്ത്രത്തിന് ഒരു IPv6 ഡിഫോൾട്ട് റൂട്ടും ബാക്കിയില്ലായിരുന്നു. മുകളിലെ റൗട്ടർ പ്രവർത്തനക്ഷമമായിരുന്നു, link-local അയൽക്കാർ ഇപ്പോഴും മറുപടി നൽകിയിരുന്നു, അപ്ലിങ്കിന് ഇപ്പോഴും അതിന്റെ ആഗോള വിലാസം ഉണ്ടായിരുന്നു. നിന്നത് ആ ഇന്റർഫേസിൽ റൗട്ടർ പ്രഖ്യാപനങ്ങൾ സ്വീകരിച്ചുകൊണ്ടിരിക്കാനുള്ള കെർണലിന്റെ സന്നദ്ധതയാണ്. sysctl എഴുതിയ നിമിഷത്തിൽ റൂട്ട് അപ്രത്യക്ഷമായില്ല; RA-യിൽ നിന്ന് പഠിച്ച ഡിഫോൾട്ട് റൂട്ടിന്റെ ആയുസ്സ് തീർന്നപ്പോൾ അപ്രത്യക്ഷമായി, ഒന്നും അത് പുതുക്കിയില്ല.

ഒറ്റനോട്ടത്തിൽ ഒന്നും തകർന്നതായി തോന്നിയില്ല. ഫോർവേഡിംഗ് പ്രവർത്തിച്ചിരുന്നു, പഴയ റൂട്ട് കാഷെയിൽ ഉള്ളിടത്തോളം ക്ലയന്റുകൾ കടന്നുപോയിരുന്നു, പരാജയം അതിന് കാരണമായ മാറ്റത്തിന് ശേഷം വൈകിയാണ് വന്നത്. ആ കാലതാമസം കൊണ്ടാണ് കുറ്റം മുകളിലെ ഭാഗത്തോ ഒരിക്കലും ഉൾപ്പെടാത്ത ഒരു ഫയർവാൾ നിയമത്തിലോ ചാർത്തുന്നത്.

ഏതെങ്കിലും sysctl തൊടുന്നതിന് മുൻപ് റൂട്ട് പട്ടിക വായിക്കുക

ip -6 route show default ൽ തുടങ്ങി ഗേറ്റ്‌വേ മാത്രമല്ല, ഗുണവിശേഷതകളും വായിക്കുക. RA-യിൽ നിന്ന് പഠിച്ച ഡിഫോൾട്ട് റൂട്ട് proto ra കൊണ്ട് അടയാളപ്പെടുത്തിയിരിക്കും, മുൻഗണന വഹിക്കും, expires ന്റെ എണ്ണൽ പിന്നോട്ട് കാണിക്കും. കൈകൊണ്ട് ചേർത്ത റൂട്ടിൽ ഇവയൊന്നും ഉണ്ടാകില്ല, ആ വ്യത്യാസമാണ് ഏത് സംവിധാനമാണ് റൂട്ടിന്റെ ഉടമ എന്ന് പറയുന്നത്.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

പിന്നെ വിലാസം നോക്കുക: ip -6 addr show dev eth0. മണിക്കൂറുകളിൽ അളക്കുന്ന മുൻഗണനയും സാധുതയുമുള്ള ആഗോള വിലാസം, റൗട്ടർ ആയുസ്സ് മിനിറ്റുകളിൽ അളക്കുന്ന ഡിഫോൾട്ട് റൂട്ടിനെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കും. വിലാസമുണ്ട് പക്ഷേ ഡിഫോൾട്ട് റൂട്ടില്ല എന്നത് പ്രഖ്യാപന പ്രശ്നത്തിന്റെ അടയാളമാണ്. വിലാസവുമില്ലെങ്കിൽ ആദ്യം ലിങ്ക്, പ്രിഫിക്സ് വിവരം അല്ലെങ്കിൽ തനിപ്പകർപ്പ് വിലാസ കണ്ടെത്തൽ എന്നിവയെ പിന്തുടരണം.

ഫോർവേഡിംഗ് RA പ്രോസസ്സിംഗ് എന്തുകൊണ്ട് ഓഫാക്കുന്നു

RA എന്നത് 134 തരം ICMPv6 പാക്കറ്റാണ്, link-local ഉറവിടത്തിൽ നിന്ന് 255 ഹോപ്പ് പരിധിയോടെ അയക്കുന്നു. കെർണൽ അത് ഉപയോഗിക്കുന്നതിന് മുൻപ് ഇന്റർഫേസിന്റെ accept_ra പരിശോധിക്കുന്നു. ഡിഫോൾട്ട് മൂല്യം 1 ആണ്, 1 എന്നാൽ അതെ എന്നല്ല. അതിന്റെ അർഥം: ഈ ഹോസ്റ്റ് ഫോർവേഡ് ചെയ്യാത്തിടത്തോളം മാത്രം സ്വീകരിക്കുക. forwarding=1 സജ്ജമാക്കുക, ആ വ്യവസ്ഥ പാലിക്കപ്പെടില്ല, അതിനാൽ അതിലെ ഏതെങ്കിലും പ്രിഫിക്സോ ഡിഫോൾട്ട് റൗട്ടറോ പരിഗണിക്കുന്നതിന് മുൻപ് പ്രഖ്യാപനം ഉപേക്ഷിക്കപ്പെടുന്നു.

മൂന്ന് മൂല്യങ്ങളുണ്ട്, ഫോർവേഡിംഗിൽ നിന്ന് മൂന്നാമത്തേത് മാത്രം അതിജീവിക്കുന്നു:

accept_raforwarding=0forwarding=1
0ignoredignored
1 (default)acceptedignored
2acceptedaccepted

മറ്റ് രണ്ട് ഫ്ലാഗുകൾ യഥാർഥത്തിൽ എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്ന് തീരുമാനിക്കുന്നു. accept_ra_defrtr പ്രഖ്യാപനത്തിലെ ഡിഫോൾട്ട് റൗട്ടർ റൂട്ട് ആകുന്നുണ്ടോ എന്ന് നിയന്ത്രിക്കുന്നു, accept_ra_pinfo പ്രിഫിക്സ് വിവരം വിലാസ സംരചനയ്ക്ക് ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് നിയന്ത്രിക്കുന്നു. accept_ra_defrtr ഓഫാക്കുന്നത് ഫോർവേഡിംഗ് ഹോസ്റ്റിൽ ഡിഫോൾട്ട് റൂട്ട് പഠിക്കാതെ SLAAC വിലാസങ്ങൾ നിലനിർത്താനുള്ള സാധാരണ മാർഗമാണ്. ഇത് accept_ra ൽ നിന്ന് വ്യത്യസ്തമായ ലിവറാണ്, വിലാസം വേണം പക്ഷേ റൂട്ട് വേണ്ട എന്ന സന്ദർഭത്തിൽ ഇതാണ് ഉപയോഗിക്കുന്നത്. കെർണലിന്റെ IP sysctl പരാമർശം മൂന്നും പട്ടികപ്പെടുത്തുന്നു.

മൂന്ന് കമാൻഡുകൾ കൊണ്ട് സ്ഥിരീകരിക്കുക

ആദ്യം, ലോഡ് ചെയ്തതെന്ന് കരുതുന്ന ഫയലിന് പകരം നിലവിലുള്ള മൂല്യങ്ങൾ വായിക്കുക:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

രണ്ടാമതായി, പ്രഖ്യാപനങ്ങൾ ഇപ്പോഴും വരുന്നുണ്ടെന്ന് തെളിയിക്കുക. ICMPv6 തരം ബൈറ്റിൽ ഫിൽട്ടർ ചെയ്താൽ മതി, അത് അയൽക്കാർ കണ്ടെത്തൽ ട്രാഫിക്കിന്റെ ഭിത്തി വായിക്കുന്നതിൽ നിന്ന് ഒഴിവാക്കുന്നു:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

കുറച്ച് മിനിറ്റുകളിൽ ഒന്നും കാണാത്തെങ്കിൽ accept_ra നിങ്ങളുടെ പ്രശ്നമല്ല. മുകളിലെ ഭാഗം പ്രഖ്യാപനം നിർത്തി, വഴിയിൽ എന്തോ ICMPv6 ഫിൽട്ടർ ചെയ്യുന്നു, അല്ലെങ്കിൽ ആ ഇന്റർഫേസ് നിങ്ങൾ കരുതുന്ന സെഗ്മെന്റിൽ യഥാർഥത്തിൽ ഇല്ല. മൂന്നാമതായി, നിങ്ങൾ തന്നെ ഒരു പ്രഖ്യാപനം ആവശ്യപ്പെട്ട് അതിന്റെ ഫീൽഡുകൾ വായിക്കുക:

rdisc6 eth0

rdisc6 Debian, Ubuntu എന്നിവയിൽ ndisc6 പാക്കേജിൽ വരുന്നു. ഔട്ട്പുട്ടിൽ മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് റൗട്ടർ ആയുസ്സും മുൻഗണനയും നോക്കുക. റൗട്ടർ ആയുസ്സ് 0 ആയ പ്രഖ്യാപനം ഡിഫോൾട്ട് റൗട്ടർ നീക്കം ചെയ്യാനുള്ള നിർദ്ദേശമാണ്, accept_ra ന്റെ ഒരു മൂല്യവും അതിനെ ഉപയോഗയോഗ്യമായ റൂട്ടാക്കുന്നില്ല. ഇതേ രീതിയിൽ ബ്രിഡ്ജ് മോഡിലുള്ള മുകളിലെ CPE യും പിടികൂടാം, അത് പ്രിഫിക്സുകൾ വിതരണം ചെയ്യുന്നു പക്ഷേ സ്വയം ഒരിക്കലും റൗട്ടറായി അവതരിപ്പിക്കുന്നില്ല.

അപ്ലിങ്കിനെ ഏക അനുവദനീയ ഇന്റർഫേസാക്കുക

മുകളിലെ ഭാഗമാണ് ഡിഫോൾട്ട് റൗട്ടർ ആകേണ്ടതെങ്കിൽ, ഫോർവേഡിംഗ് ഉണ്ടായിരുന്നിട്ടും അവിടെ പ്രഖ്യാപനങ്ങൾ സ്വീകരിക്കുക, മറ്റെവിടെയും അല്ല:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

പരിധി നിർണ്ണയം പ്രധാനമാണ് കാരണം Linux-ൽ IPv6 ഫോർവേഡിംഗ് ഒരു ആഗോള സ്വിച്ചാണ്, ഓരോ ലിങ്കിനും ഒന്നല്ല. net.ipv6.conf.wg0.forwarding ൽ 1 എഴുതി പിന്നെ net.ipv6.conf.all.forwarding വായിക്കുക: ആഗോള മൂല്യം തിരിയുന്നു, ഓരോ ഇന്റർഫേസും ഫോർവേഡ് ചെയ്യാൻ തുടങ്ങുന്നു. നിങ്ങൾക്ക് ടണലിൽ റൗട്ടറും LAN-ൽ സാധാരണ ഹോസ്റ്റും ഒരുമിച്ച് ആകാൻ കഴിയില്ല. പരിമിതപ്പെടുത്താനാകുന്നത് സ്വീകരണമാണ്. accept_ra=2 അപ്ലിങ്കിൽ നിലനിർത്തി ടണൽ, LAN ഇന്റർഫേസുകൾ 1 അല്ലെങ്കിൽ 0 ൽ വിടുക, ടണലിലൂടെ വന്ന വഴിതെറ്റിയ പ്രഖ്യാപനത്തിന് അതിലേക്ക് ചൂണ്ടുന്ന ഡിഫോൾട്ട് റൂട്ട് സ്ഥാപിക്കാൻ കഴിയാതിരിക്കാൻ.

താൽക്കാലിക sysctl -w അടുത്ത ബൂട്ട് വരെ നിലനിൽക്കില്ല, systemd-networkd ഉം NetworkManager ഉം ഈ മൂല്യങ്ങൾ അവരുടെ സ്വന്തം കോൺഫിഗറേഷനിൽ നിന്നാണ് എഴുതുന്നത്. networkd-ൽ അപ്ലിങ്കിന്റെ .network ഫയലിൽ IPv6Forwarding=yes ഉം IPv6AcceptRA=yes ഉം സജ്ജമാക്കുക; കെർണലിലെ അതേ കാരണത്താൽ networkd IPv6Forwarding-നെ ആഗോളമായി വിവരിക്കുന്നു. NetworkManager-ൽ അപ്ലിങ്കിലെ ipv6.method=auto ആണ് accept_ra മൂല്യം നയിക്കുന്നത്, അതിനാൽ ആദ്യ പരിശോധനയിൽ വിശ്വസിക്കുന്നതിന് പകരം nmcli connection up ന് ശേഷം sysctl വീണ്ടും വായിക്കുക.

സ്ഥിരമായ ബദൽ ip -6 route add default via fe80::1 dev eth0 ശരിക്കും പ്രവർത്തിക്കുന്നു, മുകളിലെ റൗട്ടറിന് സ്ഥിരമായ link-local വിലാസമുണ്ടെങ്കിൽ അത് ന്യായമായ ഉത്തരമാണ്. നിങ്ങൾ എന്താണ് ഉപേക്ഷിക്കുന്നതെന്ന് വ്യക്തമായിരിക്കുക. സ്ഥിരമായ ഡിഫോൾട്ട് റൂട്ട് ഒരിക്കലും പുതുക്കപ്പെടുന്നില്ല, ഒരിക്കലും പിൻവലിക്കപ്പെടുന്നുമില്ല, അതിനാൽ മുകളിലെ ഭാഗം മാറ്റിയതിന് ശേഷവും അത് മരിച്ച അയൽക്കാരനെ ചൂണ്ടിക്കൊണ്ടിരിക്കുന്നു. RA റൂട്ട് സുരക്ഷിതമായി പരാജയപ്പെടുന്നു; സ്ഥിരമായത് നിശബ്ദമായി പരാജയപ്പെടുന്നു.

ഫോർവേഡ് ചെയ്ത പാക്കറ്റ് പരിശോധിക്കുക, ഗേറ്റ്‌വേയുടേതല്ല

ഗേറ്റ്‌വേയുടെ സ്വന്തം പിംഗുകൾ ഒരു ക്ലയന്റും ഉപയോഗിക്കാനാകാത്ത റൂട്ടിൽ വിജയിച്ചേക്കാം, ഗേറ്റ്‌വേ ഉറവിടമായതിനാലും വിജയിച്ചേക്കാം. ബന്ധിപ്പിച്ച ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, പിന്നെ ആ ക്ലയന്റിന്റെ വിലാസത്തിനായി എന്ത് ചെയ്യുമെന്ന് ഗേറ്റ്‌വേയോട് ചോദിക്കുക:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

പിന്നെ ഒരു റൗട്ടർ ആയുസ്സ് കാത്തിരുന്ന് വീണ്ടും നോക്കുക. നിങ്ങൾ ആഗ്രഹിക്കുന്ന സ്ഥിരതയുള്ള അവസ്ഥ proto ra കൊണ്ട് അടയാളപ്പെടുത്തിയ ഡിഫോൾട്ട് റൂട്ടാണ്, അതിന്റെ expires മൂല്യം പലതവണ പുനഃസജ്ജമാക്കുന്നു, കൂടെ all.forwarding=1. expires എണ്ണൽ മാത്രം പിന്നോട്ട് പോകുന്നുവെങ്കിൽ, പ്രഖ്യാപനങ്ങൾ ഇപ്പോഴും എവിടെയോ ഉപേക്ഷിക്കപ്പെടുന്നു, സാധാരണ കുറ്റവാളി ബൂട്ട് സമയത്തെ sysctl ഇതിനകം പ്രവർത്തിച്ചതിന് ശേഷം accept_ra വീണ്ടും എഴുതുന്ന ഒരു നെറ്റ്‌വർക്ക് മാനേജറാണ്.

ഇത് അടയ്ക്കുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: ഡിഫോൾട്ട് റൂട്ട് proto ra ആണ്, പുതുക്കപ്പെടുന്നു, accept_ra=2 അപ്ലിങ്കിന് മാത്രം ബാധകമാണ്, റീബൂട്ടിന് ശേഷവും മാനേജർ റീസ്റ്റാർട്ടിന് ശേഷവും ഫോർവേഡിംഗ് 1 ആണ്, IPv6 പിംഗ് പൂർത്തിയാക്കുന്നത് ക്ലയന്റാണ്, ഗേറ്റ്‌വേയല്ല. ആരോഗ്യകരമായ റൂട്ട് ഉണ്ടായിട്ടും ക്ലയന്റ് പരാജയപ്പെടുന്നെങ്കിൽ അടുത്ത സംശയം തിരിച്ചുള്ള വഴി അല്ലെങ്കിൽ മുകളിലെ ഫയർവാൾ ആണ്, പ്രഖ്യാപനമല്ല.

അനുബന്ധ ലേഖനങ്ങൾ