kubectl-ന് OpenVPN വഴി സ്വകാര്യ ക്ലസ്റ്ററിന്റെ API പരിഹരിക്കാനാകില്ല

ടണൽ പ്രവർത്തിക്കുമ്പോൾ API-യുടെ സ്വകാര്യ വിലാസം ഇപ്പോഴും ping-ന് ഉത്തരം നൽകുമ്പോൾ kubectl നാമം തിരയുന്നതിൽ പരാജയപ്പെടുന്നു. റൂട്ട് ശരിയാണ്; ക്ലയന്റ് ക്ലസ്റ്ററിന്റെ സ്വകാര്യ സോണിനെക്കുറിച്ച് ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത ഒരു റിസോൾവറിനോട് ചോദിക്കുന്നു. രണ്ട് പരിഹാരങ്ങളാണ് കൂടുതൽ ഉപയോഗിക്കുന്നത്: വെർച്വൽ നെറ്റ്വർക്കിന്റെ റിസോൾവർ ഓരോ VPN ക്ലയന്റിനും അയയ്ക്കുക, അല്ലെങ്കിൽ പേര് പ്രാദേശികമായി hosts എൻട്രി അല്ലെങ്കിൽ സോപാധിക ഫോർവേഡർ ഉപയോഗിച്ച് പിൻ ചെയ്യുക. രണ്ടും ഒരേ ലക്ഷണം വ്യത്യസ്ത ഉത്തരവാദിത്തത്തോടെ പരിഹരിക്കുന്നു, അവ കൂട്ടിക്കലർത്തുന്നതാണ് ഓരോ തവണയും എൻഡ്പോയിന്റ് പുനർനിർമ്മിക്കുമ്പോൾ ടീമുകൾ hosts ഫയലുകൾ തിരുത്താൻ കാരണം.

പരിഹരണവും എത്തിച്ചേരലും വ്യത്യസ്ത പാളികളിൽ പരാജയപ്പെടുന്നു

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് തിരയൽ സ്വയം നടത്തുക. Linux-ൽ getent hosts അല്ലെങ്കിൽ Windows-ൽ nslookup ക്ലയന്റിന് ഉത്തരം ലഭിക്കുന്നുണ്ടോ എന്ന് പറയുന്നു; സമയം കഴിയുകയോ NXDOMAIN ആകുകയോ ചെയ്താൽ അത് റിസോൾവറിലേക്ക് ചൂണ്ടുന്നു, തെറ്റായ വിലാസത്തിലുള്ള ഉത്തരം പഴയ രേഖയിലേക്കോ പൊതു കവാടത്തിലേക്കോ ചൂണ്ടുന്നു.

തുടർന്ന് kubectl യഥാർത്ഥത്തിൽ ഏത് സെർവറിലേക്കാണ് ബന്ധിപ്പിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക. kubeconfig കോൺടെക്സ്റ്റ് URL സംഭരിക്കുന്നു, VPN റൂട്ട് അത് വീണ്ടും എഴുതുന്നില്ല: കോൺടെക്സ്റ്റ് പൊതു എൻഡ്പോയിന്റ് പേരിട്ടാൽ DNS തികഞ്ഞതാകാം, കമാൻഡ് എന്നിട്ടും പരാജയപ്പെടും.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

മൂന്നാമത്തെ സൂചന തിരയലിനു ശേഷമുള്ള പരാജയത്തിന്റെ രൂപമാണ്. സ്വകാര്യ വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെട്ട ശേഷം TCP സമയം കഴിയുന്ന പേര് ഫയർവാൾ അല്ലെങ്കിൽ അധികാരപ്പെടുത്തിയ നെറ്റ്വർക്ക് പ്രശ്നമാണ്. പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെടുന്ന പേര് എന്നാൽ ചോദ്യം സ്വകാര്യ സോണിൽ നിന്ന് പുറത്തുപോയി എന്നാണ്. ഈ മൂന്ന് ഫലങ്ങൾ വേർതിരിച്ച് വയ്ക്കുക; ഓരോന്നും നിങ്ങളെ വ്യത്യസ്ത ഉത്തരവാദിയിലേക്ക് എത്തിക്കുന്നു.

ഓപ്ഷൻ A: വെർച്വൽ നെറ്റ്വർക്കിന്റെ റിസോൾവർ ടണലിലേക്ക് അയയ്ക്കുക

VPN സെർവർ വെർച്വൽ നെറ്റ്വർക്കിനുള്ളിൽ പ്രവർത്തിക്കുമ്പോൾ, ക്ലയന്റുകൾക്ക് സെർവർ ഹോസ്റ്റ് ഉപയോഗിക്കുന്ന അതേ റിസോൾവർ ഉപയോഗിക്കാം. OpenVPN Community-യിൽ സെർവർ DNS ഓപ്ഷൻ അയയ്ക്കുന്നു; Access Server അതേ ക്രമീകരണം അഡ്മിൻ ഇന്റർഫേസിൽ കാണിക്കുന്നു, കൂടാതെ ക്ലയന്റുകൾ പ്രൊഫൈൽ വീണ്ടും ഡൗൺലോഡ് ചെയ്യണം കാരണം DNS നിർദ്ദേശം അതിനുള്ളിൽ യാത്ര ചെയ്യുന്നു.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

റൂട്ട് വരി split tunnel പ്രൊഫൈലുകളിൽ പ്രധാനമാണ്. റിസോൾവർ വിലാസം അയയ്ക്കുന്നത് അതിനെ എത്താവുന്നതാക്കുന്നതിന് തുല്യമല്ല: ടണലിലൂടെ ക്ലസ്റ്ററിന്റെ സബ്നെറ്റ് മാത്രം പോകുന്നുവെങ്കിൽ, 10.0.0.4-ലേക്കുള്ള ചോദ്യം പ്രാദേശിക LAN വഴി പുറത്തുപോയി മരിക്കുന്നു. റിസോൾവറിനായി ഹോസ്റ്റ് റൂട്ട് അയയ്ക്കുക, അല്ലെങ്കിൽ അതിന്റെ സബ്നെറ്റ് ടണലിൽ ഉൾപ്പെടുത്തുക.

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

ക്ലയന്റിൽ എന്താണ് പ്രയോഗിച്ചതെന്ന് പരിശോധിക്കുക: systemd-resolved Linux-ൽ resolvectl status, macOS-ൽ scutil --dns, Windows-ൽ ipconfig /all. അയച്ച DNS സെർവർ ഒരിക്കലും കാണാത്തതെങ്കിൽ പ്രൊഫൈൽ വീണ്ടും ലോഡ് ചെയ്തിട്ടില്ല എന്നാണ് അർത്ഥം.

ഓപ്ഷൻ B: hosts എൻട്രികളും സോപാധിക ഫോർവേഡിംഗും

hosts എൻട്രി ഏറ്റവും ചെറിയ സാധ്യമായ പരിഹാരവും ഏറ്റവും നാശക്ഷമവുമാണ്. ഒരു പേരിനെ ഒരു യന്ത്രത്തിലെ ഒരു വിലാസവുമായി ബന്ധിപ്പിക്കുന്നു, അതിനാൽ ഡെമോയ്ക്ക് പ്രവർത്തിക്കും, സ്വകാര്യ എൻഡ്പോയിന്റോ അതിന്റെ IP-യോ പുനർനിർമ്മിക്കുമ്പോൾ തകരും. യഥാർത്ഥ വിടവ് ബാക്കി ടീമിൽ നിന്ന് ഇത് മറയ്ക്കുന്നു.

സോപാധിക ഫോർവേഡർ ഓരോ ക്ലയന്റിനും DNS അയയ്ക്കാതെ മികച്ച രീതിയിൽ സ്കെയിൽ ചെയ്യുന്നു. dnsmasq-ന് ഒരു സോൺ VNet റിസോൾവറിലേക്ക് അയച്ച് ബാക്കിയെല്ലാം ശാന്തമായി വിടാം: server=/cluster.internal/10.0.0.4. Windows DNS-ൽ സോപാധിക ഫോർവേഡറുകളുണ്ട്, Windows ക്ലയന്റുകൾക്ക് അതേ വിഭജനത്തിന് NRPT നിയമം ഉപയോഗിക്കാം. ഫോർവേഡറിന് ഇപ്പോഴും VNet റിസോൾവറിലേക്ക് റൂട്ട് വേണം.

ഫോർവേഡിംഗ് സാധാരണ ബ്രൗസിംഗ് പ്രാദേശികമായി നിലനിർത്തുന്നു, അത് split tunnel-ൽ പ്രധാനമാണ്. സ്വകാര്യ സോണിന്റെ ചോദ്യങ്ങൾ ലോഗ് ചെയ്യാൻ ഒരു സ്ഥലവും ഫോർവേഡർ ഹോസ്റ്റ് മാറുമ്പോൾ തകരുന്ന ഒരു സ്ഥലവും ഇത് നൽകുന്നു.

ഉത്തരവാദിത്തം അനുസരിച്ച് തിരഞ്ഞെടുക്കുക, സൗകര്യം അനുസരിച്ചല്ല

VPN പ്രൊഫൈൽ നിയന്ത്രിക്കുന്നുവെങ്കിൽ, API മാത്രമല്ല ഓരോ സ്വകാര്യ പേരും പ്രവർത്തിക്കണമെന്ന് ആഗ്രഹിക്കുന്നുവെങ്കിൽ റിസോൾവർ അയയ്ക്കുക. ക്ലയന്റുകൾ ബാക്കിയെല്ലാത്തിനും പ്രാദേശിക DNS സൂക്ഷിക്കേണ്ടിവന്നാൽ, അല്ലെങ്കിൽ VPN ക്ലസ്റ്ററല്ലാത്ത മറ്റൊരു ടീം കൈകാര്യം ചെയ്യുന്നുവെങ്കിൽ ഫോർവേഡർ തിരഞ്ഞെടുക്കുക.

hosts എൻട്രികൾ രോഗനിർണ്ണയമാണ്, വിന്യാസമല്ല. API എത്താവുന്നതാണെന്ന് തെളിയിക്കാൻ ഒന്ന് ഉപയോഗിക്കുക, തുടർന്ന് അത് നീക്കി റിസോൾവറിന്റെ പാത ശരിയാക്കുക; അത് അവിടെ വിട്ടാൽ പിന്നീട് റൂട്ടിംഗ് ചോദ്യം നിധിവേട്ടയായി മാറും. ഏത് ഓപ്ഷൻ തിരഞ്ഞെടുത്താലും സോൺ, റിസോൾവർ വിലാസം, ചോദ്യം വഹിക്കുന്ന റൂട്ട് എന്നിവ എഴുതിവയ്ക്കുക.

API എൻഡ്പോയിന്റ് പരിശോധിക്കുക, പേര് മാത്രമല്ല

തിരയൽ വിജയിച്ചാൽ, ക്ലസ്റ്റർ CA ഉപയോഗിച്ച് API-യുടെ പതിപ്പ് എൻഡ്പോയിന്റ് എടുക്കുക. curl --cacert ca.crt https://api.internal.example:6443/version TLS, അധികാര പരാജയങ്ങളെ DNS-ൽ നിന്ന് വേർതിരിക്കുന്നു. 403 എന്നാൽ പേരും ബന്ധവും പ്രവർത്തിക്കുന്നു, ഐഡന്റിറ്റി പ്രവർത്തിക്കുന്നില്ല.

ക്ലയന്റിന്റെ വിലാസ ശ്രേണി ക്ലസ്റ്ററിന്റെ അധികാരപ്പെടുത്തിയ നെറ്റ്വർക്കുകളോ ഫയർവാളോ അനുവദിക്കുന്നുണ്ടോ എന്നും പരിശോധിക്കുക. സ്വകാര്യ ക്ലസ്റ്ററുകൾ പലപ്പോഴും API ട്രാഫിക് VNet അല്ലെങ്കിൽ peered ശ്രേണികളിൽ നിന്ന് മാത്രം സ്വീകരിക്കുന്നു, അതിനാൽ മറ്റൊരു പൂളിൽ നിന്ന് വിലാസങ്ങൾ നൽകുന്ന ടണൽ നെറ്റ്വർക്ക് പാളിയിൽ ബന്ധിപ്പിച്ച് API-യിൽ ഉപേക്ഷിക്കപ്പെടുന്നു.

എസ്കലേറ്റ് ചെയ്യുമ്പോൾ നാല് വസ്തുതകൾ എഴുതുക: ക്ലയന്റ് ഉപയോഗിച്ച റിസോൾവർ, അത് തിരികെ നൽകിയ വിലാസം, തിരഞ്ഞെടുത്ത kubeconfig കോൺടെക്സ്റ്റിലെ സെർവർ URL, പരാജയപ്പെട്ട ആദ്യ പ്രവർത്തനം. ആ രേഖ അടുത്ത എഞ്ചിനീയറോട് DNS, റൂട്ടിംഗ് അല്ലെങ്കിൽ ഫയർവാൾ നയം മാറ്റണമോ എന്ന് പറയുന്നു, അടുത്ത hosts ഫയൽ തിരുത്തൽ നിർത്തുന്നു.

തിരയലിൽ തുടങ്ങുക, സോണിന്റെ ഉടമയുമായി പൊരുത്തപ്പെടുന്ന റിസോൾവർ പാത തിരഞ്ഞെടുക്കുക, തുടർന്ന് എൻഡ്പോയിന്റ് സ്ഥിരീകരിക്കുക. മൂന്നും കടന്നാൽ ബാക്കിയുള്ള പ്രശ്നം അധികാരമാണ്, നാമപരിഹരണമല്ല.