Wi-Fi-ൽ നിന്ന് സെല്ലുലാറിലേക്ക് മാറിയ ശേഷം കിൽ സ്വിച്ച്: എന്താണ് തകരുന്നത്

ഒരു നിമിഷം ലാപ്ടോപ്പ് ഓഫീസിലെ Wi-Fi-ലുണ്ട്, അടുത്ത നിമിഷം അത് ഒരു ഫോണിലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു, നിങ്ങൾ ജാലകങ്ങൾ മാറ്റി തീരുന്നതിന് മുൻപ് തന്നെ ടണൽ സൂചകം വീണ്ടും പച്ചയാണ്. പച്ച വെളിച്ചം ടണൽ വീണ്ടും ബന്ധിപ്പിച്ചു എന്ന് മാത്രം അറിയിക്കുന്നു; ആ ഇടവേളയിൽ റൂട്ടിംഗും ബ്ലോക്കിംഗ് നയവും എന്ത് ചെയ്തു എന്നത് വേറെ ചോദ്യമാണ്. ആ നയം അവസാനം ഇൻസ്റ്റാൾ ചെയ്തപ്പോൾ സമാഹരിച്ച പൊരുത്ത ഷർത്തുകളുടെ ഒരു കൂട്ടമാണ്, കൈമാറ്റം ഇപ്പോൾ നീക്കിയ ഇന്റർഫേസും വിലാസവും വിലാസ കുടുംബവും അത് പേരെടുത്ത് പറയുന്നു. അതിനാൽ അതേ മാറ്റം ഒരേപോലെ കാണപ്പെടുന്ന മൂന്ന് ഫലങ്ങൾ നൽകുന്നു: ബ്ലോക്കിംഗ് തുടരുന്നു, നയം സ്വന്തം വീണ്ടെടുപ്പിനെ തടയുന്നു, അല്ലെങ്കിൽ ഒന്നും മൂടാത്ത ഒരു പാത തുറക്കുന്നു.

സ്ക്രീനിൽ ആ മൂന്ന് അവസ്ഥകളെ വേർതിരിക്കുന്നത് ഒന്നുമില്ല, അതിനാൽ സൂചകം ഏത് നിറം കാണിക്കുന്നു എന്ന് ചോദിക്കുന്നതിന് പകരം നിയമങ്ങൾ ഏത് ഐഡന്റിഫയറുകളിൽ പിന്നിട്ടിരുന്നു എന്ന് ചോദിക്കുക. Linux-ൽ ഒരു നിയമം ഒരു ഇന്റർഫേസോ അതിൽ നിന്ന് നിറച്ച ipset-ഓ പേരെടുത്ത് പറയാം; Android-ൽ setUnderlyingNetworks വഴി ഏത് അടിസ്ഥാന നെറ്റ്വർക്കുകൾ പിന്തുടരണം എന്ന് VpnService-നോട് പറയാം. ഓരോ ബന്ധവും മാറ്റിസ്ഥാപിക്കാൻ പോകുന്ന ഒരു കണ്ണിയിലേക്ക് ചൂണ്ടുന്നു, ഓരോന്നും പിന്നീട് വീണ്ടും വിലയിരുത്തണം.

കൈമാറ്റം യഥാർത്ഥത്തിൽ എന്താണ് പുനരെഴുതുന്നത്

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

പ്രശ്നം എന്നത് ഒരു നിയമം അതിന്റെ പിന്നിലെ ഉദ്ദേശ്യത്തിന് പകരം ഒരു നിർദ്ദിഷ്ട ഐഡന്റിഫയർ എൻകോഡ് ചെയ്യുന്നു എന്നതാണ്. ടണൽ ഇന്റർഫേസിലൂടെ പുറത്തുപോകാത്തതെല്ലാം ഉപേക്ഷിക്കുന്ന നിയമം ഒരു ഇന്റർഫേസ് നാമം എൻകോഡ് ചെയ്യുന്നു; അന്തിമ ബിന്ദുവിന് അനുമതി നൽകുന്ന നിയമം പുതിയ നെറ്റ്വർക്കിന് മറ്റെവിടെയോ റൂട്ട് ചെയ്യാവുന്ന ഒരു വിലാസം എൻകോഡ് ചെയ്യുന്നു. ഐഡന്റിഫയർ അപ്രത്യക്ഷമാകുമ്പോൾ നിയമം കണ്ണിൽ തെറ്റായി മാറുന്നില്ല: അത് ഒന്നുമായും പൊരുത്തപ്പെടാതാകുന്നു അല്ലെങ്കിൽ തെറ്റായതുമായി പൊരുത്തപ്പെടാൻ തുടങ്ങുന്നു.

ദ്വാരം ഉണ്ടാക്കാതെ പുറം ടണൽ വീണ്ടും നിർമ്മിക്കൽ

പുറം ഗതാഗതം പഴയ ഉറവിട വിലാസത്തോട് ബന്ധിച്ചിരുന്നു, അതിനാൽ അത് പുതിയതിൽ നിന്ന് പുതിയ സോക്കറ്റ് തുറക്കണം. അന്തിമ ബിന്ദു അക്ഷരാർത്ഥ വിലാസമല്ലാതെ ഹോസ്റ്റ്നെയിം ആകുമ്പോൾ, ബ്ലോക്ക് നിലവിലുള്ളപ്പോൾ തന്നെ തിരയൽ വിജയിക്കണം. ഇതാണ് ക്രമത്തിന്റെ കെണി: അന്തിമ ബിന്ദു ഒഴികെ എല്ലാം ഉപേക്ഷിക്കാൻ മതിയായ കർശനമായ നയം അത് കണ്ടെത്താൻ വേണ്ട തിരയലും ഉപേക്ഷിക്കും, ബ്ലോക്ക് ഉയർത്തുന്നതിന് മുൻപ് പരിഹാരം ഉണ്ടാകുന്നില്ലെങ്കിൽ അല്ലെങ്കിൽ ഇപ്പോഴും ജീവനുള്ള ടണലിലൂടെ കടത്തുന്നില്ലെങ്കിൽ. രണ്ട് ക്രമങ്ങൾക്കും പ്രവർത്തിക്കാം, പക്ഷേ ക്ലയന്റിന് താൻ ഏത് ക്രമത്തിലാണെന്ന് അറിയുമ്പോൾ മാത്രം.

രോഗനിർണ്ണയത്തിൽ പ്രധാനമാകുന്ന രീതിയിൽ ക്ലയന്റുകൾ ഇവിടെ വ്യത്യസ്തരാണ്. ചിലത് ആദ്യം പരിഹരിച്ച് പിന്നീട് നിയമങ്ങൾ സ്ഥാപിക്കുന്നു, അതിനാൽ കൈമാറ്റത്തിന് കാണാവുന്ന ഒരു തടസ്സം വരുത്തി പിന്നീട് സ്വയം കരകയറുന്നു; മറ്റുള്ളവ ബ്ലോക്ക് നിലനിർത്തി തിരയൽ കടത്താൻ അതിജീവിച്ച ടണലിനെ ആശ്രയിക്കുന്നു, കണ്ണിയോടൊപ്പം ടണൽ മരിച്ചാൽ അത് പൂർണ്ണമായി പരാജയപ്പെടുന്നു. ബന്ധം തിരികെ കൊണ്ടുവരാൻ വിശാലമായ നേരിട്ടുള്ള സ്ഥിര പാത ചേർക്കുന്നത് പരീക്ഷണം എപ്പോഴും വിജയിപ്പിക്കുകയും നിങ്ങൾ തടയുന്ന ചോർച്ച എപ്പോഴും അവശേഷിപ്പിക്കുകയും ചെയ്യുന്നു.

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

പുതിയ കണ്ണി IPv6 കൊണ്ടുവരുമ്പോൾ നിയമങ്ങൾ കൊണ്ടുവരാത്തപ്പോൾ

സെല്ലുലാർ, അതിഥി നെറ്റ്വർക്കുകൾ പലപ്പോഴും ആഗോള IPv6 പ്രിഫിക്സ് നൽകുന്നു, ഓഫീസിന്റെ വയർ LAN അത് ഒരിക്കലും ചെയ്തിട്ടില്ലെങ്കിൽ പോലും. IPv4 നിയമങ്ങളായി മാത്രം എഴുതിയ നയം — കൈകൊണ്ട് നിർമ്മിച്ച ഭൂരിഭാഗം iptables, nftables പാചകക്കുറിപ്പുകളുടെ സ്ഥിര രൂപം — അതിൽ ഒന്നും മൂടുന്നില്ല. ടണൽ ബന്ധിപ്പിച്ചിരിക്കും, IPv6 എത്തിച്ചേരാനാകുന്ന അപ്ലിക്കേഷനുകൾ അതിന് പുറത്തേക്ക് പോകും, ടണൽ യഥാർത്ഥത്തിൽ ഉള്ളതിനാൽ സൂചകം വ്യത്യാസം കാണിക്കാനാവില്ല. വിപരീത കേസും അത്രതന്നെ സാധാരണമാണ്: IPv6-ന് മാത്രമുള്ള നിയമക്കൂട്ടം v6 നൽകാത്ത നെറ്റ്വർക്കിൽ ഒന്നും ചെയ്യുന്നില്ല.

കൈമാറ്റത്തിന്റെ ഇരുവശത്തും കണ്ണി നൽകുന്നതും നയം പറയുന്നതും താരതമ്യം ചെയ്യുക. ഈ കമാൻഡുകൾ ക്ലയന്റ് പ്രവർത്തിക്കുന്ന അതേ വസ്തുതകൾ അച്ചടിക്കുന്നു:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

രണ്ടാമത്തെ കമാൻഡ് സ്ഥിര റൂട്ട് അച്ചടിച്ച് മൂന്നാമത്തേത് പൂജ്യം തിരികെ നൽകുന്നെങ്കിൽ, പുതിയ കണ്ണിക്ക് ഒരു നിയമവും നോക്കാതെ യന്ത്രത്തെ IPv6 വഴി പുറത്തെത്തിക്കാം. മാറ്റത്തിന് ശേഷം മൂന്നും വീണ്ടും പ്രവർത്തിപ്പിക്കുക, കാരണം രസകരമായ സംഖ്യ രണ്ട് പ്രവർത്തനങ്ങളുടെ വ്യത്യാസമാണ്. രണ്ടാമത്തേത് ഒന്നും അച്ചടിക്കുന്നില്ലെങ്കിൽ വിപരീത കേസ് ബാധകമാണ്, അവിടെ ഏതൊരു v6-ഭാരമുള്ള നയവും വെറും അലങ്കാരമാണ്.

റിസോൾവർ സെഷന് നടുവിൽ കൈ മാറുന്നു

ആധുനിക സിസ്റ്റങ്ങളിൽ റിസോൾവറുകൾ കണ്ണികളോട് ബന്ധിപ്പിച്ചിരിക്കുന്നു, അതിനാൽ പുതിയ കണ്ണി ഒരു പുതിയ റിസോൾവർ കൂട്ടവും ഒരുപക്ഷേ വേറെ split-DNS കാഴ്ചയുമായി വരുന്നു. systemd-resolved ഓരോ കണ്ണിക്കും ഒരു സ്കോപ്പ് സൂക്ഷിക്കുകയും റൂട്ട് അനുസരിച്ച് അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു, macOS ഡൈനാമിക് സ്റ്റോറിൽ നിന്ന് scoped റിസോൾവറുകൾ വായിച്ച് ഇന്റർഫേസ് ക്രമം മാനിക്കുന്നു. സ്വന്തം റിസോൾവർ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ക്ലയന്റ് കണ്ണിയുടേതുമായി മത്സരിക്കുന്നു, ആരും നോക്കാത്ത മുൻഗണനാ നിയമങ്ങളാണ് വിജയിയെ തീരുമാനിക്കുന്നത്. അപ്പോൾ പേര് പരിഹരിക്കൽ തകരാം, പാക്കറ്റ് ഫിൽട്ടറിംഗ് അതിനായി എഴുതിയത് കൃത്യമായി ചെയ്യുമ്പോൾ.

കോൺഫിഗർ ചെയ്ത റിസോൾവറല്ല, സജീവമായത് വായിക്കുക. systemd ഹോസ്റ്റിൽ status ഉപകമാൻഡ് ഓരോ സ്കോപ്പും ഏത് കണ്ണിയിൽ നിന്ന് വന്നു, private-DNS പേര് നിലവിലുണ്ടോ എന്ന് കാണിക്കുന്നു:

resolvectl status --no-pager
resolvectl query intranet.example.com

ചോദ്യം ടണലിലൂടെയല്ലാതെ ഭൗതിക കണ്ണിയിലൂടെ പുറത്തുപോകുന്നെങ്കിൽ, ക്ലയന്റ് മുൻഗണനാ മത്സരത്തിൽ തോറ്റു, ഒരു ഫയർവാൾ ക്രമീകരണവും നാമകരണം ശരിയാക്കില്ല. കൈമാറ്റത്തിന്റെ ഇരുവശത്തും ചോദ്യത്തിന്റെ പാത താരതമ്യം ചെയ്ത് ഏതാണ് നീങ്ങിയതെന്ന് നോക്കുക. പുതിയ നെറ്റ്വർക്കിന് റൂട്ട് ചെയ്യാനാവാത്ത സ്വകാര്യ വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന പേര് മൂന്നാമത്തെ കേസാണ്, അത് പിശകായല്ല, സമയപരിധിയായി കാണുന്നു.

കൈമാറ്റം പരിശീലിക്കുകയും രേഖ സൂക്ഷിക്കുകയും ചെയ്യുക

കാത്തിരിക്കുന്നതിന് പകരം മാറ്റം ബോധപൂർവ്വം വീണ്ടും സൃഷ്ടിക്കുക. ആദ്യ കണ്ണിയിൽ ടണൽ ഉയർത്തി, ദീർഘകാല കൈമാറ്റവും ആവർത്തിച്ചുള്ള തിരയലും തുടങ്ങി, പിന്നീട് കണ്ണി മാറ്റി ഏതാണ് അതിജീവിക്കുന്നതെന്ന് നോക്കുക. പഴയ കണ്ണി അപ്രത്യക്ഷമായതും ടണൽ ബന്ധിപ്പിച്ചു എന്ന് റിപ്പോർട്ട് ചെയ്തതും തമ്മിലുള്ള ഇടവേള രേഖപ്പെടുത്തുക, കാരണം ആ ജാലകത്തിലാണ് നയം നിന്നതോ നിന്നില്ലയോ എന്നത്. ഫലം ഏകപക്ഷീയമാകാതിരിക്കാൻ ക്രമം മറ്റേ ദിശയിലും പ്രവർത്തിപ്പിക്കുക.

ഒഴിവുകൾക്ക് സ്വന്തം പരിശോധന വേണം, കാരണം പഴയ നെറ്റ്വർക്കിൽ ന്യായീകരിച്ച ഒഴിവാക്കൽ പുതിയതിൽ സ്വയമേവ ന്യായീകരിക്കപ്പെടുന്നില്ല. വീട്ടിലെ LAN-ൽ ഒരു പ്രിന്റർ, NAS അല്ലെങ്കിൽ captive portal എന്നിവയ്ക്ക് സെല്ലുലാറിൽ തുല്യമില്ല, അവയിലേക്ക് എത്തിയിരുന്ന ഒഴിവ് തുല്യമില്ലാത്ത നിയമമായി മാറുന്നു.

ഓരോ ദിശയ്ക്കും ഇന്റർഫേസ് നാമങ്ങൾ, നൽകുന്ന കുടുംബങ്ങൾ, നിലവിലുള്ള റിസോൾവർ, തടസ്സത്തിന്റെ ദൈർഘ്യം എന്നിവ എഴുതുക. വീണ്ടും ബന്ധിപ്പിക്കുന്നത് ഗതാഗതം വീണ്ടെടുത്തു എന്ന് തെളിയിക്കുന്നു, ഇടവേളയിൽ ബ്ലോക്ക് നിന്നു എന്നല്ല, അവ ടിക്കറ്റിൽ ചേർക്കാനുള്ള വേറിട്ട അവകാശവാദങ്ങളാണ്. ആ രേഖയുണ്ടെങ്കിൽ അടുത്ത കൈമാറ്റം ഓർമ്മയോടല്ല, അറിയപ്പെടുന്ന അവസ്ഥയോട് താരതമ്യം ചെയ്യാം.