VPN കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് പങ്കിടൽ: DNS-ന് എന്ത് സംഭവിക്കുന്നു

VPN കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസ് പങ്കിടുന്നത് നിങ്ങളുടെ ആപ്ലിക്കേഷന് ടണലിന്റെ ഇന്റർഫേസുകളും റൂട്ടുകളും നൽകുന്നു. അത് അതിന് ടണലിന്റെ റിസോൾവർ നൽകുന്നില്ല, അല്ലെങ്കിൽ ഹോസ്റ്റിലുള്ള മറ്റെന്തിന്റെയും ലയിപ്പിച്ച പകർപ്പും നൽകുന്നില്ല. ഈ വിടവ് വളരെ നിർദ്ദിഷ്ടമായ ഒരു പരാജയം ഉണ്ടാക്കുന്നു: പൊതു നാമങ്ങൾ പരിഹരിക്കപ്പെടുന്നു, ആന്തരിക നാമങ്ങൾ പരിഹരിക്കപ്പെടുന്നില്ല, പരാജയപ്പെടുന്ന ആപ്പ് തെറ്റായ DNS സെർവർ ഉപയോഗിക്കുന്നതായി തോന്നുന്നു, കാരണം അത് യഥാർത്ഥത്തിൽ അങ്ങനെ ചെയ്യുന്നു. പരിഹാരം സാധാരണയായി രോഗനിർണയം സൂചിപ്പിക്കുന്നതിനേക്കാൾ ചെറുതാണ്.

ഘട്ടം 1: ഹോസ്റ്റിൽ നിന്നല്ല, ആപ്പിൽ നിന്ന് പരിശോധിക്കുക

പ്രശ്നമുള്ള കണ്ടെയ്നറിനുള്ളിൽ ലുക്കപ്പ് പ്രവർത്തിപ്പിക്കുക, ഹോസ്റ്റിലും ബ്രൗസറിലും അല്ല. docker exec app-container getent hosts db.internal പ്രധാനമായ ഏക ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ പ്രോസസിന്റെ റിസോൾവർ എന്ത് തിരികെ നൽകുന്നു.

ഹോസ്റ്റ് നാമം പരിഹരിക്കുകയും കണ്ടെയ്നർ പരിഹരിക്കാതിരിക്കുകയും ചെയ്താൽ, നിങ്ങൾ തകരാറ് കണ്ടെത്തി. ഇതിനുശേഷമുള്ളതെല്ലാം അത് ശരിയാക്കാനുള്ള പിന്തുണയുള്ള മാർഗം തിരഞ്ഞെടുക്കലാണ്.

ഘട്ടം 2: റൺടൈമിന്റെ പിന്തുണയുള്ള മാതൃക വായിക്കുക

Docker-ന്റെ നെറ്റ്വർക്ക് ഡോക്യുമെന്റേഷൻ മറ്റൊരു കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് മോഡ് പങ്കിടുന്ന കണ്ടെയ്നറുകൾക്കുള്ള DNS ഫ്ലാഗുകളിലെ നിയന്ത്രണങ്ങൾ രേഖപ്പെടുത്തുന്നു. Compose-ൽ network_mode: service:vpn ആപ്പിനെ VPN കണ്ടെയ്നറിന്റെ നെയിംസ്പേസുമായി ബന്ധിപ്പിക്കുന്നു, ഓരോ സേവനത്തിനും dns ക്രമീകരണങ്ങൾ സാധാരണ സേവനത്തിലെന്നപോലെ പ്രവർത്തിക്കുന്നില്ല. നിങ്ങൾക്ക് ലഭിക്കുന്ന പരിഹാരം പങ്കിട്ട നെയിംസ്പേസിനുള്ളതാണ്.

ഉപയോക്തൃ-നിർവചിത ബ്രിഡ്ജ് നെറ്റ്വർക്കുകളും Docker-ന്റെ ഉൾച്ചേർത്ത DNS ഡിഫോൾട്ട് ബ്രിഡ്ജിൽ നിന്ന് വ്യത്യസ്തമായി ഉപയോഗിക്കുന്നു. അതുകൊണ്ടാണ് dns പ്രവർത്തിക്കുന്ന ബ്രിഡ്ജ് ഉദാഹരണത്തിൽ നിന്ന് പകർത്തിയ ഒരു ഖണ്ഡിക പങ്കിട്ട സ്റ്റാക്കിൽ ഒന്നും ചെയ്യാതിരിക്കാം. ഖണ്ഡിക പകർത്തുന്നതിന് മുമ്പ് ക്രമീകരണം പരിശോധിക്കുക.

ലൂപ്പ്ബാക്ക് വിലാസം എപ്പോഴും ബന്ധപ്പെട്ട നെറ്റ്വർക്ക് സന്ദർഭത്തെ സൂചിപ്പിക്കുന്നു. പങ്കിട്ട നെയിംസ്പേസിനുള്ളിൽ, 127.0.0.1 ഹോസ്റ്റിന്റെ റിസോൾവർ അല്ല.

ഘട്ടം 3: ക്വറിയെ അതിന്റെ സ്വീകർത്താവിലേക്ക് പിന്തുടരുക

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

ബ്രൗസറിലെ IP-പരിശോധന പേജിന് നാമ ക്വറികൾ എവിടെ പോയി എന്ന് പറയാനാകില്ല. ഒരു HTTP കണക്ഷൻ എവിടെ പോയി എന്ന് മാത്രം പറയുന്നു.

ഘട്ടം 4: രണ്ട് പരാജയ വിഭാഗങ്ങൾ വെവ്വേറെ ശരിയാക്കുക

പൊതു നാമങ്ങൾ പ്രവർത്തിക്കുമ്പോൾ സേവന നാമങ്ങൾ പരാജയപ്പെട്ടാൽ, പ്രശ്നം കണ്ടെയ്നർ നെറ്റ്വർക്കിനുള്ളിലെ സേവന കണ്ടെത്തലാണ്, പൊതു റിസോൾവർ പട്ടികയല്ല. എല്ലാ പൊതു DNS വിലാസവും മാറ്റുന്നത് നെറ്റ്വർക്കിന്റെ കണ്ടെത്തൽ സംവിധാനത്തോട് ഒരിക്കലും ആവശ്യപ്പെടാത്ത റെക്കോർഡുകൾ സൃഷ്ടിക്കില്ല.

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

ഘട്ടം 5: പുനഃസൃഷ്ടിക്ക് ശേഷം വീണ്ടും പരിശോധിക്കുക

റൺടൈമിന്റെ പിന്തുണയുള്ള സംവിധാനത്തിലൂടെ കോൺഫിഗറേഷൻ മാറ്റുക, തുടർന്ന് പ്രവർത്തിക്കുന്ന കണ്ടെയ്നറിനുള്ളിൽ ഫയലുകൾ എഡിറ്റ് ചെയ്യുന്നതിനുപകരം കണ്ടെയ്നറുകൾ പുനഃസൃഷ്ടിക്കുക. പുതിയ സ്വകാര്യ നാമം, പുതിയ പൊതു നാമം, ലുക്കപ്പിനെ തുടർന്നുള്ള ആപ്ലിക്കേഷൻ അഭ്യർത്ഥന എന്നിവ പരിശോധിക്കുക. /etc/resolv.conf കണ്ടെയ്നറിനുള്ളിലെ എഡിറ്റ് പുനഃസൃഷ്ടിയിൽ അപ്രത്യക്ഷമാകും, ശരിയാക്കാത്തപ്പോഴും ശരിയായി എന്ന് നിങ്ങളെ വിശ്വസിപ്പിക്കും.

പങ്കിട്ട നെറ്റ്വർക്ക് നിർവചനത്തിന് അടുത്ത് റിസോൾവറിന്റെ ഉടമയും പ്രതീക്ഷിത നെയിംസ്പേസും രേഖപ്പെടുത്തുക. അടുത്ത വ്യക്തിക്ക് രണ്ടും ആവശ്യമാണ്.