ഭൂമിശാസ്ത്രപരമായ DNS-ഉം anycast-ഉം: നിങ്ങൾക്ക് ലഭിക്കുന്ന VPN പ്രവേശനം പരിശോധിക്കൽ

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

റിസോൾവർ യഥാർത്ഥത്തിൽ റിപ്പോർട്ട് ചെയ്യുന്നത് ആരുടെ സ്ഥാനമാണെന്ന് പരിശോധിക്കുക

ടോപ്പോളജി-സെൻസിറ്റീവ് ആയ ഒരു ക്വെറിക്ക് ഉത്തരം നൽകുന്ന അധികാരമുള്ള സെർവർ സാധാരണയായി ചോദിച്ച റികർസീവ് റിസോൾവറിന്റെ വിലാസമാണ് കാണുന്നത്, പേര് ടൈപ്പ് ചെയ്ത വ്യക്തിയുടെ വിലാസമല്ല. കേന്ദ്രീകൃത റിസോൾവർ അത് സേവിക്കുന്ന ക്ലയന്റുകളിൽ നിന്ന് വളരെ അകലെ ആകാം, ഉത്തരം അവരെയല്ല, റിസോൾവറിനെയാണ് പ്രതിഫലിപ്പിക്കുന്നത്. അത് ഒരു വീഴ്ചയല്ല; അധിക വിവരങ്ങൾ നൽകാത്തിടത്തോളം പ്രോട്ടോക്കോൾ അങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്. EDNS Client Subnet സ്പെസിഫിക്കേഷൻ ആ പരിമിതിയും ഓപ്ഷണൽ പരിഹാരവും വിവരിക്കുന്നു.

എല്ലാ പങ്കാളികളും അത് പിന്തുണയ്ക്കുകയും പ്രവർത്തനക്ഷമമാക്കുകയും ചെയ്യുമ്പോൾ EDNS Client Subnet ഉത്ഭവ-നെറ്റ്വർക്ക് വിവരങ്ങൾ വഹിക്കാം. ഇത് ഓപ്ഷണലാണ്, സ്വകാര്യതയ്ക്കും കാഷിംഗിനും പ്രത്യാഘാതങ്ങളുണ്ട്, ഏതെങ്കിലും പൊതു റിസോൾവർ കൃത്യമായ ഉപയോക്തൃ സ്ഥാനം റിപ്പോർട്ട് ചെയ്യുമെന്ന് അനുമാനിക്കാനുള്ള അനുവാദമല്ല ഇത്. അതിനെ അടിസ്ഥാനമാക്കി രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് റിസോൾവർ ഓപ്പറേറ്റർമാരോട് ചോദിക്കുക.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

anycast റൗട്ടിംഗ് എന്താണ് തീരുമാനിച്ചതെന്ന് പരിശോധിക്കുക

anycast-ൽ, നിരവധി ലൊക്കേഷനുകൾ ഒരു സേവന വിലാസത്തിന് എത്താനാകുന്നതായി പ്രഖ്യാപിക്കുന്നു, അതിന്റെ റൗട്ടിംഗ് ഇഷ്ടപ്പെടുന്ന നോഡിലേക്ക് നെറ്റ്വർക്ക് ഓരോ ക്ലയന്റിനെയും എത്തിക്കുന്നു. ആ തിരഞ്ഞെടുപ്പ് മാപ്പിലെ ദൂരത്തല്ല, BGP-യും ചുറ്റുമുള്ള പോളിസിയുമാണ് നടത്തുന്നത്. ടോപ്പോളജിക്കൽ അടുപ്പം സാധാരണയായി മികച്ച റൗണ്ട്-ട്രിപ്പ് പ്രകടനത്തിന് തുല്യമല്ല, കാരണം ചെറുതായി തോന്നുന്ന പാത തിരക്കുള്ളതോ അസമമായതോ ആകാം. നിങ്ങൾക്ക് നൽകിയ വിലാസം ഏത് നോഡാണ് ഉത്തരം നൽകിയതെന്ന് ഒന്നും പറയുന്നില്ല.

സേവന വശത്തുനിന്നോ, അത് പേരിടുന്ന ഒരു പ്രതികരണത്തിൽ നിന്നോ സേവനം നൽകുന്ന ലൊക്കേഷൻ സ്ഥിരീകരിക്കുക, DNS ഉത്തരത്തിൽ നിന്ന് മാത്രമല്ല. traceroute -n 198.51.100.20 നിങ്ങൾ സഞ്ചരിച്ച പാത കാണിക്കുന്നു, അതിന്റെ അവസാനത്തിലുള്ള ഹോസ്റ്റിന് പേര് നൽകുന്നുമില്ല, അതിനാൽ അത് ഉത്തരമായി വായിക്കാതെ പാതയായി വായിക്കുക.

നോഡ് മാറ്റത്തെ സെഷൻ അതിജീവിക്കുന്നുവെന്ന് പരിശോധിക്കുക

DNS ക്വെറി ചെറുതാണ്, VPN സെഷൻ ദൈർഘ്യമുള്ളതാണ്, രണ്ടിനും തികച്ചും വ്യത്യസ്തമായ സ്റ്റേറ്റ് ആവശ്യകതകളുണ്ട്. സെഷനിനിടയിൽ റൗട്ടിംഗ് മാറാം, അങ്ങനെ സംഭവിക്കുമ്പോൾ പിന്നീടുള്ള പാക്കറ്റുകൾ നിങ്ങളുടെ ടണൽ ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത ഒരു നോഡിൽ എത്താം. അത് അതിജീവിക്കാവുന്നതാണോ എന്നത് നടപ്പാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു: പങ്കിട്ട സ്റ്റേറ്റ്, മനഃപൂർവമുള്ള വീണ്ടും കണക്ഷൻ, അല്ലെങ്കിൽ രേഖപ്പെടുത്തിയ പരാജയം. വിലാസം മാത്രം അവയൊന്നും നൽകുന്നില്ല.

മാറ്റം അനുമാനിക്കാതെ നിരീക്ഷിക്കുക. പാത മാറുമ്പോൾ sudo tcpdump -ni any -c 20 esp പുറം പാക്കറ്റുകൾ കാണിക്കുന്നു, പിയർ വിലാസത്തിലെ പെട്ടെന്നുള്ള മാറ്റമാണ് സംഭവിക്കുന്ന മാറ്റം. നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന നടപ്പാക്കലിനായി ഉദ്ദേശിച്ച പെരുമാറ്റം വ്യക്തമായി നിർവചിച്ച്, ഒരു പാത മാറ്റം നിർബന്ധിച്ച് അത് പരിശോധിക്കുക. ഡിസൈൻ സെഷൻ റെപ്ലിക്കേഷൻ അനുമാനിക്കുന്നുവെങ്കിൽ, മെക്കാനിസം പേരിടുകയും അത് ഉൾക്കൊള്ളാത്ത പരാജയം പേരിടുകയും ചെയ്യുക.

ഐഡന്റിറ്റി ഇപ്പോഴും പൊരുത്തപ്പെടുന്നുവെന്ന് പരിശോധിക്കുക

ഓരോ എൻട്രി പോയിന്റും നിങ്ങളുടെ ക്ലയന്റ് പ്രൊഫൈൽ പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റി അവതരിപ്പിക്കണം. സേവന നാമത്തിന് നൽകുന്ന സർട്ടിഫിക്കറ്റ് നോഡുകളിലുടനീളം പ്രവർത്തിക്കുന്നു, എന്നാൽ നോഡ് അനുസരിച്ചുള്ള സർട്ടിഫിക്കറ്റുകൾ ക്ലയന്റിനെ പുതിയത് സ്വീകരിക്കാൻ നിർബന്ധിക്കുന്നു, അവിടെയാണ് ഉപയോക്താക്കൾ മുന്നറിയിപ്പുകൾ വായിക്കാതെ കടന്നുപോകാൻ പഠിക്കുന്നത്. പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റിയും പ്രൊഫൈലും എൻട്രി മോഡലുമായി സ്ഥിരതയുള്ളതായി സൂക്ഷിക്കുക.

അസാധാരണമായ ഒരു നോഡിൽ എത്തിയ ക്ലയന്റിൽ നിന്ന് ഇത് പരിശോധിക്കുക, കാരണം നോഡ് അനുസരിച്ചുള്ള സർട്ടിഫിക്കറ്റ് ദൃശ്യമാകുന്നത് അവിടെയാണ്. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ചെയിനും പേരുകളും പ്രിന്റ് ചെയ്യുന്നു, ക്ലയന്റ് താരതമ്യം ചെയ്യുന്നത് കൃത്യമായി അതാണ്. തുടർന്ന് പ്രൊഫൈൽ ചുരുക്കണോ സർട്ടിഫിക്കറ്റ് മോഡൽ മാറ്റണോ എന്ന് തീരുമാനിക്കുക.

ആദ്യ ഉത്തരം മാത്രമല്ല, റെക്കോർഡ് പരിശോധിക്കുക

മൂന്ന് സാഹചര്യങ്ങൾ വിലയിരുത്തി ഓരോന്നിനും നാല് വസ്തുതകൾ എഴുതുക: സാധാരണ എൻട്രി, ഒരു ലൊക്കേഷൻ ലഭ്യമല്ലാത്തത്, ഏകീകരിച്ച വീണ്ടെടുപ്പ് കേസ്. ഉപയോഗിച്ച റിസോൾവർ, തിരികെ നൽകിയ വിലാസം, അത് സേവിച്ച ലൊക്കേഷൻ, പുതിയ അപ്ലിക്കേഷൻ ഫലം എന്നിവയാണ് നാല് വസ്തുതകൾ. ആ റെക്കോർഡ് DNS തിരഞ്ഞെടുപ്പ് പ്രശ്നത്തെ ഗേറ്റ്വേ പ്രശ്നത്തിൽ നിന്നും റൗട്ടിംഗ് പ്രശ്നത്തിൽ നിന്നും സെഷൻ സ്റ്റേറ്റ് പ്രശ്നത്തിൽ നിന്നും വേർതിരിക്കുന്നു. അതില്ലാതെ, നാലും ക്ലയന്റിൽ നിന്ന് ഒരുപോലെ കാണപ്പെടുന്നു.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

ഓഫീസിൽ നിന്ന് മാത്രമല്ല, പ്രതിനിധികളായ ആക്സസ് നെറ്റ്വർക്കുകളിൽ നിന്നും സാഹചര്യങ്ങൾ പ്രവർത്തിപ്പിക്കുക, കാരണം വ്യത്യസ്ത ക്ലയന്റുകൾ യഥാർത്ഥത്തിൽ ഏത് എൻട്രി പോയിന്റിലാണ് എത്തുന്നത് എന്നതാണ് മുഴുവൻ ചോദ്യം. ഒരു നെറ്റ്വർക്ക് ഒരു മാതൃക മാത്രമാണ്.