Docker പോർട്ട് പ്രസിദ്ധീകരണവും VPN ഉറവിടങ്ങളും: നിങ്ങൾ വിട്ടുപോകുന്ന രണ്ട് പൊരുത്തങ്ങൾ

നിയമം പറയുന്നു VPN സെർവറിന്റെ വിലാസം പ്രസിദ്ധീകരിച്ച സേവനത്തിലേക്ക് അനുവദിക്കുക, എന്നിട്ടും കണക്ഷൻ വീഴുന്നു. ഈ ഫലം സാധാരണമാണ്, അത് Docker-ന്റെ തകരാറല്ല. രണ്ട് വെവ്വേറെ പൊരുത്തങ്ങൾ തെറ്റാണ്: നിങ്ങൾ എഴുതിയ ഉറവിടം ഹോസ്റ്റ് സ്വീകരിക്കുന്ന ഉറവിടമല്ലായിരിക്കാം, നിങ്ങൾ എഴുതിയ പോർട്ട് ഫിൽട്ടർ കാണുന്ന പോർട്ടല്ലായിരിക്കാം. രണ്ടും ശരിയാക്കാൻ സേവന രേഖാചിത്രത്തിനു പകരം പാക്കറ്റിന്റെ പാത നോക്കണം.

കെട്ടുകഥ: VPN സെർവർ അനുവദിച്ചാൽ കഴിഞ്ഞു

റൂട്ട് ചെയ്ത VPN ക്ലയന്റിന്റെ ടണൽ വിലാസം Docker ഹോസ്റ്റ് വരെ നിലനിർത്താൻ കഴിയും. ഉറവിട പരിഭാഷ ചെയ്യുന്ന ഗേറ്റ്‌വേ ആ വിലാസം സ്വന്തം വിലാസം കൊണ്ട് മാറ്റാം. രണ്ട് രൂപകൽപ്പനകളും ന്യായമാണ്, ഒരേ ഉപയോക്തൃ പ്രവർത്തനത്തിന് അവ വ്യത്യസ്ത ഉറവിടങ്ങൾ നൽകുന്നു.

അതിനാൽ VPN സെർവർ IP എന്ന പദപ്രയോഗം ഒരു അനുമാനത്തെ വിവരിക്കുന്നു, നിരീക്ഷണത്തെയല്ല. നിങ്ങളുടെ മുന്നിൽ ഏത് രൂപകൽപ്പനയാണെന്ന് അറിയുന്നതുവരെ നിയമം ഒരു ഊഹമാണ്.

ഉറവിടം: ക്ലയന്റ് പൂൾ അല്ലെങ്കിൽ പരിഭാഷിത ഗേറ്റ്‌വേ

നാല് കാര്യങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുക. ഒന്നാമത്, ക്ലയന്റ് വിലാസ പൂൾ, ഉദാഹരണത്തിന് 10.90.0.0/24. രണ്ടാമത്, ഗേറ്റ്‌വേ ആ പൂൾ ഹോസ്റ്റിലെത്തുന്നതിന് മുമ്പ് പരിഭാഷപ്പെടുത്തുന്നുണ്ടോ. മൂന്നാമത്, ഒരു പുതിയ കണക്ഷന് ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ നിരീക്ഷിക്കുന്ന ഉറവിടം. നാലാമത്, അപ്ലിക്കേഷൻ പ്രാമാണീകരണം വ്യക്തിഗത ഉപയോക്താക്കളെ വേർതിരിക്കുന്നുണ്ടോ, കാരണം പങ്കിട്ട പരിഭാഷിത വിലാസത്തിന് അത് സാധ്യമല്ല.

പൂൾ നിലനിർത്തിയാൽ, ഗേറ്റ്‌വേയുടെ പൊതു വിലാസവുമായി മാത്രം പൊരുത്തപ്പെടുന്ന നിയമം ഓരോ ക്ലയന്റിനെയും വിട്ടുപോകും. ഗേറ്റ്‌വേ ബോധപൂർവം പരിഭാഷപ്പെടുത്തിയാൽ, പരിഭാഷിത വിലാസം അനുവദിക്കുന്നത് അതിന് പിന്നിലുള്ള ഓരോ ഉപയോക്താവിനെയും അകത്തേക്ക് വിടും, അത് സ്വന്തം ലോഗിൻ ഉള്ള സേവനത്തിന് സ്വീകാര്യവും മറ്റെല്ലാത്തിനും അസ്വീകാര്യവുമാകാം.

പോർട്ട്: DNAT നിങ്ങൾ പൊരുത്തപ്പെടുത്തുന്ന സംഖ്യ മാറ്റുന്നു

Docker iptables-നൊപ്പം സാധാരണ Linux ബ്രിഡ്ജ് പ്രസിദ്ധീകരണത്തിൽ, 8443-ൽ നിന്ന് കണ്ടെയ്നർ പോർട്ട് 443-ലേക്കുള്ള ഹോസ്റ്റ് മാപ്പിംഗ് ഫോർവേഡിംഗ് ഫിൽട്ടർ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് പരിഭാഷപ്പെടുത്തുന്നു. പാക്കറ്റ് ഫിൽട്ടറിൽ എത്തുന്നത് ലക്ഷ്യ പോർട്ട് 443-നൊപ്പമാണ്. ആ ഘട്ടത്തിൽ 8443-മായി പൊരുത്തപ്പെടുന്ന നിയമം ഒരിക്കലും സജീവമാകുന്നില്ല, ക്ലയന്റ് ടൈപ്പ് ചെയ്തത് 8443 ആണെങ്കിലും.

പ്രസിദ്ധീകരിച്ച പോർട്ട് ഇപ്പോഴും കണക്ഷൻ ട്രാക്കിംഗിൽ ഉണ്ട്, അതിനാൽ യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളപ്പോൾ യഥാർത്ഥ ലക്ഷ്യം അവിടെ പൊരുത്തപ്പെടുത്താം.

ഏത് സംഖ്യയാണ് ഉദ്ദേശ്യം പ്രകടിപ്പിക്കുന്നതെന്ന് തീരുമാനിക്കുക. നിയമം കണ്ടെയ്നറിനുള്ളിലെ സേവനത്തെ സംരക്ഷിക്കുമ്പോൾ DNAT-ന് ശേഷമുള്ള കണ്ടെയ്നർ പോർട്ടുമായി പൊരുത്തപ്പെടുത്തുക. നിയമം ക്ലയന്റ് എന്താണ് ആവശ്യപ്പെട്ടതെന്ന് വിവരിക്കേണ്ടതുണ്ടെങ്കിൽ conntrack ഓപ്ഷൻ ഉപയോഗിച്ച് യഥാർത്ഥ ലക്ഷ്യവുമായി പൊരുത്തപ്പെടുത്തുക, അതിനൊപ്പം വരുന്ന അധിക പൊരുത്ത ചെലവും നിയമ ക്രമത്തിലെ ശ്രദ്ധയും സ്വീകരിക്കുക.

ചെയിൻ: DOCKER-USER, INPUT അല്ല

Docker-ന്റെ iptables ഗൈഡ് ഉപയോക്തൃ ഫോർവേഡിംഗ് നയം DOCKER-USER ചെയിനിൽ നിർത്തുന്നു, അത് Docker-ന്റെ സ്വന്തം ഫോർവേഡിംഗ് നിയമങ്ങൾക്ക് മുമ്പ് വിലയിരുത്തുന്നു. ഹോസ്റ്റ് സേവനത്തിൽ നിന്ന് INPUT ചെയിനിലേക്ക് പകർത്തിയ നിയമം ഹോസ്റ്റിലേക്ക് അഭിസംബോധന ചെയ്ത ട്രാഫിക്ക് ഫിൽട്ടർ ചെയ്യുന്നു, കണ്ടെയ്നറിലേക്ക് ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക്കല്ല. ആ തെറ്റ് ശരിയായി തോന്നുന്ന, എന്നാൽ കണ്ടെയ്നർ പാതയിൽ യാതൊരു ഫലവുമില്ലാത്ത നിയമം ഉണ്ടാക്കുന്നു.

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

പുതിയ കണക്ഷനുകൾ കൊണ്ട് പരിശോധിക്കുക

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

ഈ പരിശോധനകൾക്ക് പിന്നിലുള്ള ചെയിൻ ക്രമവും പോർട്ട് പരിഭാഷാ സ്വഭാവവും രേഖപ്പെടുത്തുന്നത് Docker-ന്റെ iptables ഗൈഡ് ആണ്. ഏതെങ്കിലും റെസിപ്പി പകർത്തുന്നതിന് മുമ്പ് അത് വായിക്കുക, ഇൻസ്റ്റാൾ ചെയ്ത Docker ഏത് ബാക്കെൻഡ് ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം nftables ബാക്കെൻഡ് നയം വ്യത്യസ്തമായി സംയോജിപ്പിക്കുന്നു.