VPN-ന്റെ DNS എല്ലാ ലുക്ക്അപ്പും എടുക്കുന്നു: NetworkManager-ൽ dns-priority ശരിയാക്കുക

ഓഫീസ് VPN-ലേക്ക് കണക്റ്റ് ചെയ്യുക, പെട്ടെന്ന് എല്ലാ പേര് ലുക്ക്അപ്പും കോർപ്പറേറ്റ് റിസോൾവറിലേക്ക് പോകുന്നു. പൊതു നാമങ്ങൾ ഇപ്പോഴും പരിഹരിക്കപ്പെടുന്നു, അതിനാൽ പ്രാദേശിക പ്രിന്ററിന്റെ പേര് പരാജയപ്പെടുന്നതുവരെയോ split-horizon റെക്കോർഡ് ഓഫീസ് വിലാസം തിരികെ നൽകുന്നതുവരെയോ ഒന്നും തകർന്നതായി തോന്നുന്നില്ല. ചില Fedora സെറ്റപ്പുകളിൽ നേരെ വിപരീതം സംഭവിക്കുന്നു: ടണൽ ഉയർന്നതിനുശേഷവും ISP റിസോൾവർ ഉത്തരം നൽകുന്നു. രണ്ടും ഒരേ ചോദ്യമാണ് — ഈ ക്വറിയുടെ ഉടമ ഏത് റിസോൾവറാണ് — NetworkManager സിസ്റ്റങ്ങളിൽ ഉത്തരം ഓരോ കണക്ഷന്റെയും DNS ഗുണങ്ങളിൽ കഴിയുന്നു.

രണ്ട് കണക്ഷനുകൾ, ഒരു വിജയിക്കുന്ന റിസോൾവർ

ഓരോ കണക്ഷനും ഒരു DNS മുൻഗണന പ്രഖ്യാപിക്കുന്നു. സാധാരണ കണക്ഷനുകൾ സ്വതേ 50-ഉം VPN കണക്ഷനുകൾ 0-ഉം ആണ്, കുറഞ്ഞ മൂല്യം വിജയിക്കുന്നു. ഈ സ്വതേയുള്ള മൂല്യം കാരണമാണ് VPN കണക്ഷൻ അത് ക്ലെയിം ചെയ്യുന്ന ഓരോ ഡൊമെയ്നിനും വയർ ലിങ്കിനെ നിശബ്ദമായി മറികടക്കുന്നത്: ആരും തിരഞ്ഞെടുക്കാതെ തന്നെ പൂജ്യം അമ്പതിനെ തോൽപ്പിക്കുന്നു.

മുൻഗണന സ്ഥാനാർത്ഥികളെ ക്രമത്തിലാക്കുന്നു. വിജയിയോട് എന്ത് ചോദിക്കണം എന്നത് അത് പരിമിതപ്പെടുത്തുന്നില്ല. സെർച്ച് ഡൊമെയ്ൻ ഇല്ലാത്ത VPN കണക്ഷൻ എല്ലാം ക്ലെയിം ചെയ്യുന്നു, അതിനാൽ അതിന് മുൻഗണന നൽകുന്നത് പൊതു ക്വറികളെയും ടണലിലേക്ക്, സ്പ്ലിറ്റ്-ടണൽ രൂപകൽപ്പനയിൽ കോർപ്പറേറ്റ് റിസോൾവർ ഫോർവേഡ് ചെയ്യുന്നിടത്തേക്കും അയയ്ക്കുന്നു.

മുൻഗണന ക്രമം തീരുമാനിക്കുന്നു, സെർച്ച് പട്ടിക ഉടമസ്ഥത തീരുമാനിക്കുന്നു

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

സെർച്ച് പട്ടിക ഉടമസ്ഥതയുടെ പ്രഖ്യാപനമാണ്. corp.example പോലുള്ള നഗ്നമായ ഡൊമെയ്ൻ ഒരു സെർച്ച് പ്രത്യയവും റൂട്ടിംഗ് ഡൊമെയ്നും ആകുന്നു. റൂട്ടിംഗിന് മാത്രമുള്ള രൂപം ~corp.example ആ പ്രത്യയത്തിന് കീഴിലുള്ള ലുക്ക്അപ്പുകൾ ഡൊമെയ്ൻ ചെറിയ പേരുകളിൽ ചേർക്കാതെ ഈ കണക്ഷനിലേക്ക് അയയ്ക്കുന്നു. ആ ടിൽഡയാണ് «ഈ സെർവറിനോട് ചോദിക്കുക», «ഈ സെർവറിനോട് ചോദിക്കുകയും എന്റെ ടൈപ്പിംഗ് പൂർത്തിയാക്കുകയും ചെയ്യുക» എന്നിവ തമ്മിലുള്ള വ്യത്യാസം.

ഉപയോക്താക്കൾ ചെറിയ ഹോസ്റ്റ് നാമങ്ങൾ ടൈപ്പ് ചെയ്യുകയും റെക്കോർഡുകൾ പൂർണ്ണമായി യോഗ്യതയുള്ള പേരുകളാലും അഭിസംബോധന ചെയ്യപ്പെടുകയും ചെയ്യുമ്പോൾ രണ്ട് രൂപങ്ങളും ഉപയോഗിക്കുക. റിസോൾവർ നഗ്നമായ പേര് എങ്ങനെ പൂർത്തിയാക്കുന്നു എന്നത് മാറ്റാതെ വിഭജനം വേണമെങ്കിൽ റൂട്ടിംഗ് രൂപം മാത്രം ഉപയോഗിക്കുക.

പിന്നീട് മുൻഗണന വ്യക്തമാക്കി വീണ്ടും സജീവമാക്കുക:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

നെഗറ്റീവ് മുൻഗണന «ഈ കണക്ഷന് മുൻഗണന നൽകുക» എന്ന് പറയാനുള്ള രേഖപ്പെടുത്തിയ വഴിയാണ്, രണ്ട് വിലാസ കുടുംബങ്ങളും സജ്ജമാക്കുന്നത് IPv6 കണക്റ്റിവിറ്റിയുള്ള ഹോസ്റ്റിൽ പെരുമാറ്റം സ്ഥിരമായി നിലനിർത്തുന്നു. കണക്ഷൻ വീണ്ടും സജീവമാക്കാതെ ഗുണം മാറ്റുന്നത് ഇപ്പോൾ പ്രവർത്തിക്കുന്ന ഒന്നിനെയും മാറ്റുന്നില്ല, അതിനാൽ ക്രമം വ്യക്തമായ up-ൽ അവസാനിക്കുന്നു.

വിഭജനം systemd-resolved കൈവശം വയ്ക്കട്ടെ

സ്വതേയുള്ള dnsmasq പ്ലഗിൻ ക്വറികൾ ഒരു പ്രാദേശിക റിസോൾവറിലേക്ക് ഒഴുക്കുന്നു, അതിനാൽ ലിങ്ക് തോറുമുള്ള വേർതിരിവ് പരുക്കനായി തുടരുന്നു. systemd-resolved വിഭജനം ഓരോ ലിങ്കിനും വെളിപ്പെടുത്തുന്നു, resolvectl query ഉത്തരം നൽകിയ ലിങ്ക് പേരെടുത്ത് പറയുന്നു.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

അതിനുശേഷം കോർപ്പറേറ്റ് ലിങ്ക് corp.example വഹിക്കുന്നു, പൊതു റിസോൾവർ ബാക്കി സേവിക്കുന്നു. ക്വറി തെറ്റായ ലിങ്കിൽ എത്തുമ്പോൾ, കമാൻഡ് അതിന് ഉത്തരം നൽകിയ ലിങ്ക് പേരെടുത്ത് പറയുന്നു, അത് അറിയുന്നത് വിലാസം മാത്രം അറിയുന്നതിനേക്കാൾ നല്ലതാണ്.

DNS രൂപകൽപ്പന ടണൽ തരവുമായി യോജിപ്പിക്കുക

എല്ലാം ടണലിലൂടെ അയയ്ക്കുന്ന സ്വകാര്യതാ രൂപകൽപ്പനകൾ വിഭജന പട്ടിക വഹിക്കരുത്, കാരണം അത് പൊതു നാമങ്ങൾ പ്രാദേശിക റിസോൾവറിന് തിരികെ നൽകി ഉദ്ദേശ്യം ഇല്ലാതാക്കും. സ്പ്ലിറ്റ്-ടണൽ രൂപകൽപ്പനകൾക്ക് അത് ആവശ്യമാണ്: അതില്ലാതെ കോർപ്പറേറ്റ് റിസോൾവർ എല്ലാ പൊതു ക്വറിയും കാണുന്നു, ടണൽ വീഴുന്ന നിമിഷം ക്രമീകരണം തകരുന്നു.

പിന്നെ ടണലിന് പുറത്തുള്ള DNS തടയുന്ന kill switch ഉണ്ട്. ടണലിന്റെ സോണുകൾക്ക് പേരുകൾ പരിഹരിക്കപ്പെടുന്നു, ബാക്കിയെല്ലായിടത്തും പരാജയപ്പെടുന്നു, കണക്ഷൻ പൂർണ്ണമായി ആരോഗ്യകരമായിരിക്കെ. പ്രായോഗിക ഉത്തരങ്ങൾ LAN റിസോൾവറിനുള്ള വ്യക്തമായ അനുമതിയോ കോർപ്പറേറ്റ് സോൺ മാത്രം ഫോർവേഡ് ചെയ്യുന്ന പ്രാദേശിക കാഷെയോ ആണ്, രണ്ടും ടണലിലെ തകരാറല്ല, ഉടമയുള്ള ഒഴിവാക്കലാണ്.

ഇന്റർഫേസ് ആരംഭിക്കുമ്പോൾ റിസോൾവർ കോൺഫിഗറേഷൻ വീണ്ടും എഴുതുന്ന പ്രൊഫൈലും ഏതാണ്ട് അതേപോലെ പ്രവർത്തിക്കുന്നു: പ്രാദേശിക റിസോൾവർ എത്തിച്ചേരാനാകാത്തതാകുമ്പോൾ ടണലിന് അറിയാവുന്ന പേരുകൾ മാത്രം പരിഹരിക്കപ്പെടും. ഏത് സംവിധാനം ബാധകമായാലും, ഓരോ അവസ്ഥയിലും ഏത് പേരുകൾ പ്രവർത്തിക്കണം എന്ന് എഴുതിവയ്ക്കുക, ആ പട്ടിക റിപ്പോർട്ടുകൾ കൈകാര്യം ചെയ്യുന്നയാൾക്ക് നൽകുക.

ഓരോ ലിങ്കിലും പരിശോധിക്കുക, വീണ്ടും കണക്റ്റ് ചെയ്തതിനുശേഷം വീണ്ടും

ഒരു ആന്തരികവും ഒരു പൊതു നാമവും ചോദിക്കുക, ക്വറി യഥാർത്ഥത്തിൽ എവിടേക്ക് പോകുന്നു എന്ന് നോക്കുക. ലീക്ക് പരിശോധനാ പേജ് ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് പറയുന്നു, സിസ്റ്റം ഏത് ലിങ്ക് തിരഞ്ഞെടുത്തു എന്നല്ല, അതിനാൽ നിങ്ങൾ ഇപ്പോൾ ക്രമീകരിച്ച ക്രമത്തെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

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