ഹോസ്റ്റ് IPsec പങ്കാളിയിലെത്തുന്നു, Docker കണ്ടെയ്നർ എത്തുന്നില്ല

നിങ്ങൾ Linux യന്ത്രത്തിൽ നിന്ന് വിദൂര ഹോസ്റ്റിലേക്ക് ping അയയ്ക്കുന്നു, അത് മറുപടി നൽകുന്നു, അതായത് ടണൽ പ്രവർത്തിക്കുന്നു. നിങ്ങളുടെ അടുത്തുള്ള കണ്ടെയ്നർ ഇപ്പോഴും സമയപരിധി കഴിയുന്നു, അടുത്ത സ്വാഭാവിക ഘട്ടം Docker വീണ്ടും ആരംഭിക്കുകയാണ്. ബ്രിഡ്ജ് നെറ്റ്വർക്കിലെ കണ്ടെയ്നർ സാധാരണയായി മറ്റൊരു ഉറവിട വിലാസത്തോടെ ആരംഭിച്ച്, ആപ്ലിക്കേഷന്റെ സ്വന്തം പുറത്തുകടക്കൽ പാതയ്ക്ക് പകരം ഫോർവേഡിംഗ് വഴി ഹോസ്റ്റിലേക്ക് പ്രവേശിക്കുന്നു, അതിനാൽ വിജയകരമായ പരീക്ഷണം മറ്റൊരു പാക്കറ്റ് അളന്നു. നയാധിഷ്ഠിത strongSwan ടണലിന്, ഫോർവേഡ് ചെയ്ത പാക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്ത IPsec നയവുമായി പൊരുത്തപ്പെടാത്തപ്പോൾ വിദൂര സബ്നെറ്റിലേക്കുള്ള സാധാരണ വഴി മതിയാകില്ല.

താഴെയുള്ള ഗൈഡ് ഒരു ലക്ഷ്യസ്ഥാനത്തെ രണ്ട് ഉറവിടങ്ങളിലൂടെ പിന്തുടർന്ന്, എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് അവസ്ഥ വായിക്കുന്നു.

ഒരു ലക്ഷ്യസ്ഥാനവും രണ്ട് ഉറവിടങ്ങളും കൊണ്ട് തുടങ്ങുക

ആദ്യം IP അനുസരിച്ച് അറിയപ്പെടുന്ന ഒരു സേവനം തിരഞ്ഞെടുക്കുക, ഒരേ സമയം DNS കൂടി പരിഹരിക്കേണ്ടതില്ല. മൂന്ന് വസ്തുതകൾ രേഖപ്പെടുത്തുക: കണ്ടെയ്നറിന്റെ ബ്രിഡ്ജ് പ്രിഫിക്സ്, വിജയിച്ച ഹോസ്റ്റ് അഭ്യർത്ഥനയുടെ ഉറവിട വിലാസം, ടണലിനായി സമ്മതിച്ച പ്രാദേശിക, വിദൂര ട്രാഫിക് സെലക്ടറുകൾ. ആ മൂന്ന് സംഖ്യകൾ ഈ ലക്ഷണത്തിന്റെ ഏതാണ്ടെല്ലാ കേസുകളും വിശദീകരിക്കുന്നു.

തുടർന്ന് പരാജയപ്പെട്ട അഭ്യർത്ഥന കണ്ടെയ്നറിനുള്ളിൽ നിന്ന് ആവർത്തിച്ച്, അത് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഉറവിടം പിടിക്കുക. ആ വിലാസം പ്രാദേശിക സെലക്ടർ ഉൾക്കൊള്ളുന്നില്ലെങ്കിൽ, ഫലം നിങ്ങൾക്ക് ഇപ്പോൾ അറിയാം, കണ്ടെയ്നർ വീണ്ടും സൃഷ്ടിക്കുന്നത് അത് മാറ്റില്ല.

Docker സ്പർശിക്കുന്നതിന് മുൻപ് നയങ്ങൾ വായിക്കുക

വായന-മാത്രം ഹോസ്റ്റ് പരിശോധനകൾ റൂട്ടിംഗ് തീരുമാനങ്ങൾ, നയ ഡാറ്റാബേസ്, അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുന്ന നിയമങ്ങൾ എന്നിവ ഉൾക്കൊള്ളുന്നു:

ip rule show
ip route show table all
ip xfrm policy

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

കണ്ടെയ്നർ പ്രിഫിക്സ് ഇല്ലെങ്കിൽ, നിർത്തി, മറ്റെന്തെങ്കിലും തിരുത്തുന്നതിന് മുൻപ് ആർക്കിടെക്ചർ തീരുമാനിക്കുക. ബാക്കി ഗൈഡ്, ഏത് ഉറവിട വിലാസം നെറ്റ്വർക്കിൽ കാണേണ്ടതെന്ന് നിങ്ങൾ യോജിച്ചുവെന്ന് അനുമാനിക്കുന്നു.

ഫിൽട്ടറിംഗും വിവർത്തനവും ക്രമത്തിൽ പരിശോധിക്കുക

Docker-ന്റെ Linux ബ്രിഡ്ജ് ഫയർവാൾ ഫോർവേഡിംഗ് IPsec-ൽ നിന്ന് സ്വതന്ത്രമായി തടയാം. iptables backend-നൊപ്പം FORWARD പാതയും DOCKER-USER തീരുമാനങ്ങളും പരിശോധിക്കുക, മുൻപത്തെ വിധിക്ക് ശേഷം ചേർത്ത നിയമം ഒരിക്കലും പ്രവർത്തിച്ചെന്ന് വരില്ല എന്ന് ഓർക്കുക. nftables backend വ്യത്യസ്തമായി സംയോജിക്കുന്നു, അതിനാൽ ഏതോ iptables ഉദാഹരണം അതിനെ അങ്ങനെ വിളിച്ചതിനാൽ മാത്രം DOCKER-USER ശൃംഖല സൃഷ്ടിക്കരുത്; നിങ്ങളുടെ daemon യഥാർത്ഥത്തിൽ ഏത് backend ഉപയോഗിക്കുന്നു എന്ന് പരിശോധിക്കുക.

തുടർന്ന് ഉറവിട വിവർത്തനം പരിശോധിക്കുക. വിശാലമായ MASQUERADE നിയമം മുൻപ് IPsec സെലക്ടറുമായി പൊരുത്തപ്പെട്ട പാക്കറ്റിനെ ഇനി പൊരുത്തപ്പെടാത്ത ഒന്നാക്കി മാറ്റാം, പരാജയം കൃത്യമായി റൂട്ടിംഗ് പ്രശ്നം പോലെ തോന്നുന്നു. strongSwan ഫോർവേഡിംഗ് ഗൈഡ് ഇപ്പോൾത്തന്നെ നയവുമായി പൊരുത്തപ്പെടുന്ന ട്രാഫിക്കിന് അത്തരം വിവർത്തനത്തിന് മുൻപ് ആവശ്യമായ NAT ഒഴിവാക്കൽ രേഖപ്പെടുത്തുന്നു.

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

തുടർന്ന് റൂട്ട് ചെയ്തതോ വിവർത്തനം ചെയ്തതോ എന്ന് തീരുമാനിക്കുക

റൂട്ട് ചെയ്ത കണ്ടെയ്നർ സബ്നെറ്റിന് ഇരു പങ്കാളികളും ആ സബ്നെറ്റ് സ്വീകരിക്കണം, അങ്ങോട്ട് വിദൂര തിരിച്ചുവരവ് പാത ഉണ്ടാകണം, ഇത് സാധാരണയായി ഇരു അറ്റങ്ങളിലും സെലക്ടർ മാറ്റവും വിദൂര വശത്തിന്റെ ഉടമയുമായി സംഭാഷണവും അർത്ഥമാക്കുന്നു. ബോധപൂർവം വിവർത്തനം ചെയ്ത രൂപകൽപ്പനയാകട്ടെ, പ്രസക്തമായ തിരച്ചിൽ ഘട്ടത്തിൽ നയം മൂടുന്ന വിലാസം അവതരിപ്പിക്കണം, ഇത് സാധാരണയായി സ്ഥിരസ്ഥിതി MASQUERADE-ന് പകരം ഇടുങ്ങിയ, രേഖപ്പെടുത്തിയ നിയമം അർത്ഥമാക്കുന്നു.

ഈ രണ്ട് ക്രമീകരണങ്ങളിൽ ഒന്നും ഹോസ്റ്റിന്റെ പ്രവർത്തിക്കുന്ന ടണലിൽ നിന്ന് സ്വയമേവ വരുന്നില്ല, അവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ് ഉടമയുള്ള രൂപകൽപ്പന തീരുമാനമാണ്. ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് എഴുതുക, അല്ലെങ്കിൽ അടുത്ത എൻജിനീയർ അത് ഫയർവാൾ കൗണ്ടറുകളിൽ നിന്ന് വീണ്ടും കണ്ടെത്തും.

സങ്കര പരാജയവും ശ്രദ്ധിക്കുക: നിയമക്കൂട്ടത്തിന്റെ പകുതി വിവർത്തനം ചെയ്തു, പകുതി ഇല്ല, ഇത് ലക്ഷ്യ പോർട്ടിനെ ആശ്രയിക്കുന്ന, നെറ്റ്വർക്കിലെ ഒന്നിനെയും ആശ്രയിക്കാത്ത ഇടവിട്ട വിജയം ഉണ്ടാക്കുന്നു.

പുതിയ കണക്ഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക, പുനരാരംഭത്താൽ അല്ല

പുതിയ ആപ്ലിക്കേഷൻ കണക്ഷൻ ഉപയോഗിച്ച്, ഇടുങ്ങിയ ഫയർവാൾ കൗണ്ടറുകളും വിദൂര സ്വീകർത്താവും നിരീക്ഷിക്കുക, ഓരോ നിരീക്ഷണത്തിനും ഉറവിടം ഉണ്ടാകണം. Docker പുനരാരംഭിക്കുന്നത് നിയമങ്ങളുടെ അവസ്ഥ മാറ്റാം, ജോലിഭാരവും തടസ്സപ്പെടുത്തും, ഇത് നിങ്ങൾ നേടാൻ ശ്രമിച്ച വ്യക്തമായ സിഗ്നൽ നഷ്ടപ്പെടുത്തുന്നു.

നിലനിൽക്കുന്ന ഫലം നിങ്ങൾക്ക് കാണിക്കാവുന്ന നാല് പ്രസ്താവനകളാണ്: കണ്ടെയ്നറിന്റെ ഉറവിടം, യോജിക്കുന്ന സംരക്ഷിത പാത, അനുവദിച്ച ഫോർവേഡിംഗ്, തിരികെ വരുന്ന മറുപടി. നാലും ശരിയാകുമ്പോൾ, കണ്ടെയ്നർ ഹോസ്റ്റ് എത്തുന്ന അതേ കാരണത്താൽ പങ്കാളിയിലെത്തുന്നു.