രണ്ട് അപ്ലിങ്ക് fe80::1 പങ്കിടുമ്പോൾ IPv6 പോളിസി റൂട്ടിംഗ്

നിങ്ങൾക്ക് രണ്ട് അപ്ലിങ്ക് ഉണ്ട്, കൂടാതെ ip -6 route show രണ്ടിലും ഒരേ അടുത്ത ഹോപ്പ് പ്രിന്റ് ചെയ്യുന്നു: default via fe80::1 dev uplink0 കൂടാതെ default via fe80::1 dev uplink1. ഇത് വിലാസ ആവർത്തന സംഘർഷമല്ല, കൂടാതെ വെറും അടുത്ത ഹോപ്പ് fe80::1 ഒരു പോളിസി പട്ടികയിലേക്ക് പകർത്തുന്നത് ഏത് ലിങ്കാണ് നിങ്ങൾ ഉദ്ദേശിച്ചതെന്ന് കേർണലിനോട് പറയുന്നില്ല. യഥാർത്ഥ ചോദ്യം ലക്ഷണം സൂചിപ്പിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്: രണ്ടാമത്തെ പട്ടികയ്ക്ക് ഒരു ലിങ്കോ രണ്ടോ വേണം, ഒരു റീബൂട്ടിന് ശേഷം ആ റൂട്ടുകളെ ജീവനോടെ നിർത്തുന്നത് എന്താണ്. ക്രമത്തിൽ പരിശോധിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ മിക്കതും തീർക്കുന്നു.

അതേ fe80::1 രണ്ട് വ്യത്യസ്ത അയൽക്കാർ

ലിങ്ക്-ലോക്കൽ വിലാസങ്ങൾ ഒരു ലിങ്കിലേക്ക് മാത്രം പരിമിതപ്പെടുന്നു, അതിനാൽ fe80::1 രണ്ടുതവണ പ്രിന്റ് ചെയ്ത ഒരു വിലാസമല്ല; ഒരേ അനുബന്ധം പങ്കിടുന്ന രണ്ട് അയൽക്കാരാണ്. സോൺ ഇൻഡക്സ് ഏതാണ് ഉദ്ദേശിച്ചതെന്ന് ഹോസ്റ്റ് പറയുന്ന രീതിയാണ്, അതിനാൽ fe80::1%uplink0 കൂടാതെ fe80::1%uplink1 കേർണലിന് വ്യത്യസ്ത ലക്ഷ്യങ്ങളാണ്, ആ അനുബന്ധം ഒരിക്കലും റിമോട്ട് റൗട്ടറിലേക്ക് പോകുന്നില്ല. RFC 4007 ഇതിന് പിന്നിലെ സോൺ മോഡൽ വിവരിക്കുന്നു, അതുകൊണ്ടാണ് ഒരു പോളിസി പട്ടികയിൽ ഓരോ ലിങ്ക്-ലോക്കൽ അടുത്ത ഹോപ്പിനൊപ്പവും ഒരു ഉപകരണം വേണ്ടത്.

ഒരു ഹോസ്റ്റിലെ സംഖ്യാ സോൺ ID ഒരു ടെംപ്ലേറ്റിലേക്ക് പകർത്തുന്ന VPN കോൺഫിഗറേഷൻ ജനറേറ്റർ ലോക്കൽ സന്ദർഭത്തെ വിലാസത്തിന്റെ ഭാഗമായി കണക്കാക്കുന്നു, അത് എഴുതുന്ന ഫയൽ ഇന്റർഫേസ് നാമങ്ങളോ ഇൻഡക്സുകളോ വ്യത്യസ്തമായ എല്ലാ യന്ത്രത്തിലും തെറ്റാണ്. ഒരു പോളിസി പട്ടിക രണ്ട് ലിങ്കുകളെ ഒന്നാക്കി ചേർക്കുന്നുമില്ല: റൂട്ടഡ് VPN നെറ്റ്വർക്കുകൾക്കിടയിൽ പാക്കറ്റുകൾ കൈമാറുന്നു, പക്ഷേ റിമോട്ട് ഈഥർനെറ്റ് അയൽക്കാരന്റെ ലിങ്ക്-ലോക്കൽ ഐഡന്റിറ്റി ടണലിലൂടെ കൊണ്ടുപോകുന്നില്ല, അതിനാൽ ലിങ്ക്-ലോക്കൽ ട്രാഫിക് സ്വന്തം ലിങ്കിൽത്തന്നെ തുടരുന്നു.

ഉപകരണം നീക്കിയാൽ റൂട്ട് എഴുതാനാകാത്തതാകും. ip -6 route add default via fe80::1 table 200 ഗേറ്റ്വേ പരിഹരിക്കാനാകില്ല, iproute2 അത് Error: Nexthop has invalid gateway. പിശകോടെ നിരസിക്കുന്നു. dev uplink0 ചേർത്താൽ കമാൻഡ് വിജയിക്കും, കാരണം അടുത്ത ഹോപ്പിനെ ആ രണ്ട് അയൽക്കാരിൽ ഒരാളിലേക്ക് പിടിച്ചുനിർത്തുന്നത് ഉപകരണമാണ്. ഉപകരണം പറയാനാകാത്തത് uplink0 ഈ പട്ടികയ്ക്ക് ശരിയായ ലിങ്കാണോ എന്നതാണ്, മറ്റൊരു ഹോസ്റ്റിൽ നിന്ന് പകർത്തിയ റൂട്ട് ആ ഹോസ്റ്റിന്റെ ഇന്റർഫേസ് നാമങ്ങളും കൂടെ കൊണ്ടുവരും, യഥാർത്ഥ തെറ്റുകൾ അവിടെനിന്നാണ് വരുന്നത്.

വ്യവസ്ഥ ഒന്ന്: പട്ടികയിൽ ഒരു ലിങ്കോ രണ്ടോ

രണ്ടാമത്തെ അപ്ലിങ്ക് എന്തിനാണെന്നതിൽ നിന്ന് തുടങ്ങുക. രണ്ട് ലിങ്കുകളും ഒരേ ട്രാഫിക് വഹിക്കുകയും ഒന്ന് കരുതൽ ആയിരിക്കുകയുമാണെങ്കിൽ, ബദൽ പട്ടികയിൽ രണ്ട് ഗേറ്റ്വേകളും വ്യത്യസ്ത മെട്രിക്കുകളോടെ വേണം: അതേ ലക്ഷ്യങ്ങൾ, ഒരു മുൻഗണനാ പാത, ഒരു വ്യക്തമായ രണ്ടാം തിരഞ്ഞെടുപ്പ്. വ്യത്യസ്ത ട്രാഫിക് വ്യത്യസ്ത പ്രൊവൈഡർമാരിലൂടെ പോകേണ്ടതുകൊണ്ടോ, അല്ലെങ്കിൽ ഇത് ഒരു സ്പ്ലിറ്റ് ടണൽ ആയതുകൊണ്ടോ — ചില ട്രാഫിക് VPN ഒഴിവാക്കി പോകുകയും ബാക്കി അകത്ത് നിൽക്കുകയും ചെയ്യുന്നു — ആ അപ്ലിങ്കുകൾ ഉള്ളതാണെങ്കിൽ, ആ രണ്ട് ലിങ്കുകളും ഒരു പട്ടികയിൽ വരുന്നതേയില്ല. അവ രണ്ട് പട്ടികകളിൽ വരുന്നു, ഒരു നിയമം അവ തിരഞ്ഞെടുക്കുന്നു, ആ നിയമം ടണലിനെയല്ല, പട്ടികയെയാണ് തിരഞ്ഞെടുക്കുന്നത്: ഒഴിവാക്കുന്ന ട്രാഫിക് റൂട്ട് ചെയ്യുന്നതിന് മുൻപ് അടയാളപ്പെടുത്തുന്നു, ആ അടയാളമാണ് അതിനെ രണ്ടാം പട്ടികയിലേക്ക് അയക്കുന്നത്.

ആ രണ്ടാം സാഹചര്യത്തിൽ ഒരു പട്ടിക എപ്പോൾ നോക്കണം എന്ന് നിയമം തീരുമാനിക്കുന്നു, പാക്കറ്റ് എവിടെ പോകണം എന്ന് റൂട്ട് തീരുമാനിക്കുന്നു:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

ഒരു വസ്തുവും മറ്റൊന്നിന് പകരമാകുന്നില്ല, ഡിഫോൾട്ട് മാത്രമുള്ള ഒരു പട്ടികയ്ക്കും സ്വന്തം ഗേറ്റ്വേ പരിഹരിക്കാനാകാതെ വരാം. ചേർക്കൽ നിരസിക്കപ്പെട്ടാലോ, റൂട്ട് ഉണ്ടെങ്കിലും ഉപയോഗിക്കാനാകാത്തതാണെങ്കിലോ, ആ ഇന്റർഫേസിന്റെ കണക്ടഡ് പ്രിഫിക്സ് അതേ പട്ടികയിൽ ചേർക്കുക, അല്ലെങ്കിൽ ഹോപ്പിനെ onlink എന്ന് അടയാളപ്പെടുത്തുക (ആ പ്രിഫിക്സ് മറ്റെവിടെയോ റൂട്ട് ചെയ്യുമ്പോൾ). മുകളിലെ ബ്ലോക്കിൽ 2001:db8:100::/48 uplink1-ലെ ആ കണക്ടഡ് പ്രിഫിക്സിനെ സൂചിപ്പിക്കുന്നു, ഏതെങ്കിലും ലക്ഷ്യത്തെയല്ല. fwmark നിയമം മറ്റെന്തെങ്കിലും സജ്ജമാക്കേണ്ട ഒരു അടയാളം മാത്രമാണ് ഉപയോഗിക്കുന്നത്: ഫോർവേഡിംഗ് പാതയിലെ nftables അല്ലെങ്കിൽ iptables നിയമത്തിൽ നിന്നോ, അല്ലെങ്കിൽ SO_MARK സോക്കറ്റിൽ നിന്നോ, അതിനാൽ അടയാള സ്രോതസ്സില്ലാതെ പകർത്തിയ ബ്ലോക്ക് ഒന്നിനോടും ഒത്തുപോകുന്നില്ല.

വ്യവസ്ഥ രണ്ട്: മെട്രിക്കുകൾ ചത്ത പ്രൊവൈഡറെ കണ്ടെത്തുന്നില്ല

മെട്രിക് നിലവിലുള്ള റൂട്ടുകൾക്കിടയിലെ മുൻഗണനയാണ്, ആരോഗ്യ പരിശോധനയല്ല. ഓപ്പറേറ്റർ വീണാൽ കേർണൽ ആ ഉപകരണത്തിലെ റൂട്ടുകൾ നീക്കുന്നു, രണ്ടാമത്തെ ഡിഫോൾട്ട് ഏറ്റെടുക്കുന്നു. കേബിൾ ഓണായി നിൽക്കുകയും അതിന് പിന്നിലെ പ്രൊവൈഡർ ചാകുകയും ചെയ്താൽ, പട്ടികയിൽ ഒന്നും മാറുന്നില്ല: മുൻഗണനാ റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നു, അയൽക്കാരൻ പാളി 2-ൽ എത്താവുന്നതാണ്, പാക്കറ്റുകൾ ഒരു കറുത്ത ദ്വാരത്തിലേക്ക് പോകുന്നു. ഈ വ്യത്യാസം നിങ്ങളുടെ ക്രമീകരണത്തിന് പ്രധാനമാണെങ്കിൽ, ഫെയിൽഓവർ പാത പരിശോധിച്ച് റൂട്ട് നീക്കം ചെയ്യുന്ന എന്തിൽ നിന്നെങ്കിലും വരണം: അത് ഒരു റൂട്ടിംഗ് ഡീമണ് ആകാം, അല്ലെങ്കിൽ എൻട്രി ഇല്ലാതാക്കി വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഒരു ചെറിയ സ്ക്രിപ്റ്റ് ആകാം.

പട്ടിക നിർമ്മിച്ചതിന് ശേഷം തിരഞ്ഞെടുപ്പ് പരിശോധിക്കുക, കേർണൽ കാണുന്ന രീതിയിൽ തന്നെ പരിശോധിക്കുക. ip -6 route get 2001:db8:100::1 ഉപയോഗിക്കുന്ന റൂട്ട് പ്രിന്റ് ചെയ്യുന്നു, അതിൽ ഉപകരണവും തിരഞ്ഞെടുത്ത സ്രോതസ്സ് വിലാസവും ഉൾപ്പെടുന്നു, അത് പോളിസി നിയമങ്ങളെ മാനിക്കുന്നു. തെറ്റായ അപ്ലിങ്കിലേക്കുള്ള സ്രോതസ്സ് വിലാസം സാധാരണയായി ഒരു നിയമം നിങ്ങൾ പ്രതീക്ഷിച്ചതിനേക്കാൾ നേരത്തെ ഒത്തുപോയതിന്റെ സൂചനയാണ്.

വ്യവസ്ഥ മൂന്ന്: നിലനിൽപ്പിന്റെ ഉടമസ്ഥത ആർക്കെന്ന് തീരുമാനിക്കുക

ഒരു റൂട്ട് ip -6 route add ഉപയോഗിച്ച് ചേർത്താൽ, റീബൂട്ട് വരെയോ എന്തെങ്കിലും അത് ഫ്ലഷ് ചെയ്യുന്നത് വരെയോ നിലനിൽക്കും. റൗട്ടർ പരസ്യങ്ങളിൽ നിന്ന് പഠിച്ച ഡിഫോൾട്ടിന് ഒരു ജീവിതകാലമുണ്ട്, റൗട്ടർ അത് പിൻവലിക്കാം, അതേസമയം കൈകൊണ്ട് ചേർത്ത ഡിഫോൾട്ട് ഒരിക്കലും സ്വയം കാലഹരണപ്പെടുന്നില്ല. രണ്ടും ഒരു പട്ടികയിൽ കലർത്തുന്നതാണ് പഴയ സ്ഥിരമായ റൂട്ട് പുതിയതായി പരസ്യപ്പെടുത്തിയതിനെ മറികടക്കാൻ ഇടയാക്കുന്നത്, അത് വിവരിച്ച അപ്ലിങ്ക് എപ്പോഴോ ഇല്ലാതായതിന് ശേഷവും.

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

മറ്റ് ഹോസ്റ്റുകൾക്കായി ഫോർവേഡ് ചെയ്യുന്ന ഒരു റൗട്ടറിൽ, പട്ടികയെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് net.ipv6.conf.all.forwarding പരിശോധിക്കുക. ഫോർവേഡിംഗ് ഓഫ് ആണെങ്കിൽ, 201 പട്ടിക എത്ര ശരിയായാലും മറ്റൊരു നെറ്റ്വർക്കിലേക്കുള്ള പാക്കറ്റുകൾ ഉപേക്ഷിക്കപ്പെടും.

അടുത്ത ആൾക്ക് ഓഡിറ്റ് ചെയ്യാൻ ഡിസൈൻ രേഖപ്പെടുത്തുക

വെറും fe80::1 മാത്രം സൂക്ഷിക്കുന്ന ഒരു ഇൻവെന്ററി പ്രധാന ഫീൽഡുകൾ വലിച്ചെറിയുന്നു. ലക്ഷ്യം, അടുത്ത ഹോപ്പ്, ഉപകരണം, പട്ടിക, മെട്രിക് എന്നിവ ഒരുമിച്ച് രേഖപ്പെടുത്തുക, ഓരോ റൂട്ടും എവിടെനിന്ന് വന്നു എന്നതും: പരസ്യപ്പെടുത്തിയതാണോ, മാനേജർ സൃഷ്ടിച്ചതാണോ, സ്റ്റാറ്റിക് ആണോ. പിന്നീട് ആരെങ്കിലും രണ്ടാമത്തെ അപ്ലിങ്ക് യഥാർത്ഥത്തിൽ ട്രാഫിക് വഹിക്കുന്നുണ്ടോ എന്ന് ചോദിച്ചാൽ, ആ രേഖ ഊഹമില്ലാതെ ഉത്തരം നൽകും.

പട്ടിക തീർന്നു എന്ന് പറയുന്നതിന് മുൻപ്, അയൽക്കാരനെ ip -6 neigh show dev uplink0 ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക, ip -6 rule show വീണ്ടും വായിക്കുക — ക്രമത്തിലെ അപകടങ്ങൾക്കായി, ഡിഫോൾട്ട് റൂട്ട് എടുക്കുന്ന ping-ന് പകരം നിയമവുമായി ഒത്തുപോകുന്ന ട്രാഫിക് ഉപയോഗിച്ച് പരിശോധിക്കുക. തുടർന്ന് ഒരു അപ്ലിങ്ക് ബോധപൂർവ്വം ഡൗൺ ചെയ്ത് കേർണൽ ഏത് റൂട്ടിലേക്ക് പിൻവാങ്ങുന്നു എന്ന് നിരീക്ഷിക്കുക; ഉത്തരം നിങ്ങൾ എഴുതിയതിന് ഒത്തുപോകണം.