Docker പോർട്ട് പ്രസിദ്ധീകരണവും VPN-ഉം: മറുപടി എങ്ങോട്ട് പോകുന്നു

പൂർണ്ണ ടണൽ VPN ഉയർന്നതിന് ശേഷവും ഹോസ്റ്റ് SSH-ന് മറുപടി നൽകുന്നു, എന്നാൽ അതേ യന്ത്രത്തിൽ Docker വഴി പ്രസിദ്ധീകരിച്ച ഒരു സേവനം നിശ്ശബ്ദമാകുന്നു. കേൾക്കുന്നവനിൽ ഒരു കുഴപ്പവുമില്ല: കണ്ടെയ്നർ പ്രവർത്തിക്കുന്നു, പോർട്ട് മാപ്പിംഗ് നിലവിലുണ്ട്, പാക്കറ്റ് എത്തുന്നു. കണ്ടെയ്നർ ആരോഗ്യവാനാണ്, അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ അതിൽ എത്തുന്നു. വ്യത്യാസം എന്നത് Linux അതിന്റെ റൂട്ട് തിരഞ്ഞെടുക്കുമ്പോൾ മറുപടി എവിടെ നിന്ന് ആരംഭിക്കുന്നു എന്നതാണ്, ആ വ്യത്യാസമാണ് താഴെയുള്ള രണ്ട് രൂപകൽപ്പനകളിൽ ഏതാണ് നിങ്ങൾക്ക് വേണ്ടതെന്ന് തീരുമാനിക്കുന്നത്.

ലക്ഷ്യ NAT-ലൂടെ ട്യൂപ്പിൾ പിന്തുടരുക

ഒരു ഹോസ്റ്റ് എടുക്കുക 192.0.2.10 ൽ, അത് TCP 2222 172.30.240.5:22 ലെ കണ്ടെയ്നറിലേക്ക് പ്രസിദ്ധീകരിക്കുന്നു. 198.51.100.25 ൽ നിന്നുള്ള അഭ്യർത്ഥന കണ്ടെയ്നറിൽ എത്തുന്നതിന് മുമ്പ് വിവർത്തനം ചെയ്യപ്പെടുന്നു, കണ്ടെയ്നർ സ്വയം എന്ന നിലയിൽ മറുപടി നൽകുന്നു.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

ഹോസ്റ്റിന്റെ റൂട്ട് തീരുമാനത്തിൽ മറുപടി ഇപ്പോഴും കണ്ടെയ്നറിന്റെ ഉറവിട വിലാസം വഹിക്കുന്നു. റിവേഴ്സ് വിവർത്തനം പിന്നീട് പ്രസിദ്ധീകരിച്ച ട്യൂപ്പിൾ പുനഃസ്ഥാപിക്കുന്നു, അതുകൊണ്ടാണ് റൂട്ട് തിരഞ്ഞെടുക്കുന്ന അതേ നിമിഷത്തിൽ പാക്കറ്റ് തെറ്റായി കാണപ്പെടുന്നത്.

ഹോസ്റ്റിന് മാത്രമുള്ള നിയമം അത് എന്തുകൊണ്ട് നഷ്ടപ്പെടുത്തുന്നു

WAN പട്ടിക 192.0.2.10 ൽ നിന്നുള്ള പാക്കറ്റുകൾക്ക് മാത്രം തിരഞ്ഞെടുക്കുന്ന നിയമം ഹോസ്റ്റിന്റെ സ്വന്തം ഡീമണുകളെ ഉൾക്കൊള്ളുന്നു, ഈ ഫോർവേഡ് ചെയ്ത മറുപടി പൂർണ്ണമായി നഷ്ടപ്പെടുത്തുന്നു. മറുപടിയിലെ ഉറവിട വിലാസം 172.30.240.5 ആണ്, ഹോസ്റ്റല്ല.

അമിതമായ തിരുത്തൽ കണ്ടെയ്നറിൽ നിന്നുള്ള എല്ലാം WAN വഴി റൂട്ട് ചെയ്യുന്നതാണ്, ഇത് കണ്ടെയ്നറിന്റെ ബന്ധമില്ലാത്ത ഔട്ട്ബൗണ്ട് കണക്ഷനുകളെയും VPN-ൽ നിന്ന് ഒഴിവാക്കുന്നു. അത് ആവശ്യപ്പെട്ട നയത്തിൽ നിന്ന് വ്യത്യസ്തമാണ്, സാധാരണയായി പിന്നീട് ആരെയെങ്കിലും അമ്പരപ്പിക്കുന്നു.

DNAT-ന് ശേഷമുള്ള പൊരുത്തം മറ്റൊരു ഹുക്കാണ്

Docker-ന്റെ ഫയർവാൾ ഡോക്യുമെന്റേഷൻ ഇങ്ങനെ പറയുന്നു: സാധാരണ ഉപയോക്തൃ ഫിൽട്ടറിംഗ് DNAT-ന് ശേഷമുള്ള ലക്ഷ്യം കാണുന്നു, അതിനാൽ സാധാരണ നിയമത്തിൽ പ്രസിദ്ധീകരിച്ച പോർട്ട് 2222 പൊരുത്തപ്പെടുത്തുന്നത് കണ്ടെയ്നർ പോർട്ട് 22 പൊരുത്തപ്പെടുത്തുന്നതിന് തുല്യമല്ല. യഥാർത്ഥ ട്യൂപ്പിൾ പ്രധാനമാണെങ്കിൽ, ഏത് പോർട്ട് ദൃശ്യമാണെന്ന് ഊഹിക്കുന്നതിന് പകരം പിന്തുണയുള്ള യഥാർത്ഥ-ലക്ഷ്യ സംവിധാനം ഉപയോഗിക്കുക.

ഈ ഹുക്ക് ആശയക്കുഴപ്പം ശരിയായി തോന്നുന്നതും ഒരിക്കലും പൊരുത്തപ്പെടാത്തതുമായ നിയമങ്ങൾ സൃഷ്ടിക്കുന്നു. നയം വീണ്ടും എഴുതുന്നതിന് മുമ്പ് നിയമത്തിലെ കൗണ്ടറുകൾ പരിശോധിക്കുക. ഹിറ്റുകളില്ലാത്ത ഒരു നിയമം, പാക്കറ്റ് ഒരിക്കലും എത്താത്ത ഇടത്ത് അത് വിലയിരുത്തപ്പെടുന്നു എന്ന് നിങ്ങളോട് പറയുന്നു.

രൂപകൽപ്പന A: തീരുമാനം കണക്ഷൻ അവസ്ഥയായി കൊണ്ടുപോകുക

ഒരു കണക്ഷൻ മാർക്കിന് ഇൻഗ്രെസ് തീരുമാനം വിവർത്തനത്തിലൂടെ കൊണ്ടുപോകാം, പക്ഷേ പ്രധാന റൂട്ട് ലുക്കപ്പിന് മുമ്പ് അത് പാക്കറ്റിലേക്ക് പുനഃസ്ഥാപിക്കണം. ഘട്ടങ്ങൾ ഇവയാണ്:

1. Docker, VPN അല്ലെങ്കിൽ മറ്റൊരു നയ ഉടമയുമായി കൂട്ടിമുട്ടാത്ത ഒരു മാർക്ക് ഫീൽഡും നിയമ മുൻഗണനയും നീക്കിവയ്ക്കുക.
2. കണക്ഷൻ ട്രാക്കിംഗ് ലഭ്യമായ DNAT-ന് മുമ്പുള്ള ഒരു ബിന്ദുവിൽ ഉദ്ദേശിച്ച പുതിയ WAN കണക്ഷൻ മാത്രം തിരിച്ചറിയുക.
3. യഥാർത്ഥ അഭ്യർത്ഥന തന്നെ WAN പട്ടികയിലേക്ക് നിർബന്ധിക്കാതെ തീരുമാനം കണക്ഷൻ മാർക്കിൽ രേഖപ്പെടുത്തുക.
4. മറുപടി ദിശയിൽ, റൂട്ടിംഗിന് മുമ്പ് നിങ്ങളുടെ സ്വന്തം മാർക്ക് ബിറ്റുകൾ മാത്രം പാക്കറ്റിലേക്ക് പുനഃസ്ഥാപിക്കുക.
5. VPN നിയമത്തിന് ആദ്യം ജയിക്കാൻ കഴിയാത്ത വിധം ഒരു പൂർണ്ണ WAN പട്ടിക മതിയായ നേരത്തേ തിരഞ്ഞെടുക്കുക.

ആ പട്ടികയ്ക്ക് യഥാർത്ഥ കണക്ടഡ് റൂട്ടുകളും ഗേറ്റ്വേയും വേണം. റൂട്ട് ഇല്ലാത്തപ്പോൾ നിർവചിച്ച പെരുമാറ്റവും വേണം. ടണലിലേക്ക് നിശ്ശബ്ദമായി വീഴുന്നതാണ് ഏറ്റവും മോശം ഫലം, കാരണം കോൺഫിഗറേഷൻ ഇപ്പോഴും പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു. പകരം അടച്ച് പരാജയപ്പെടുകയും അത് ലോഗ് ചെയ്യുകയും ചെയ്യുക.

രൂപകൽപ്പന B: ഹോസ്റ്റിൽ അവസാനിപ്പിക്കുക

കണ്ടെയ്നറിന് മുന്നിൽ TCP പ്രോക്സി അല്ലെങ്കിൽ റിവേഴ്സ് പ്രോക്സി പോലെ ബോധപൂർവം ക്രമീകരിച്ച ഹോസ്റ്റ്-സൈഡ് ഫ്രണ്ടെൻഡ്, മറുപടി ഹോസ്റ്റിന്റെ വിലാസത്തിൽ നിന്ന് ഉത്ഭവിക്കുന്നതായി നിലനിർത്തുന്നു. അപ്പോൾ ഹോസ്റ്റിനായി എഴുതിയ നിയമങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെ പ്രവർത്തിക്കുന്നു, കണ്ടെയ്നർ അതിന്റെ സ്വകാര്യ നെറ്റ്വർക്കിൽ തുടരുന്നു.

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

മാറ്റം പരിശോധിക്കുക, ഉദ്ദേശ്യമല്ല

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

ഒരു നിയമം പരീക്ഷിക്കാൻ യന്ത്രത്തിന്റെ കണക്ഷൻ പട്ടിക ഫ്ലഷ് ചെയ്യരുത്: നിലവിലുള്ള എൻട്രികൾ അവയുടെ മുൻ മാപ്പിംഗ് നിലനിർത്തുന്നു, ഫ്ലഷ് ഹോസ്റ്റിലെ മറ്റെല്ലാം തകർക്കുന്നു. ഒരു പോർട്ട് പ്രസിദ്ധീകരിക്കുന്നത് എത്തിച്ചേരാനുള്ള കഴിവ് നിർവചിക്കുന്നു. അത് മറുപടിയുടെ പാത നിർവചിക്കുന്നില്ല. തിരഞ്ഞെടുത്ത രൂപകൽപ്പന അതിന്റെ പട്ടിക നാമങ്ങളോടെ എഴുതിവയ്ക്കുക, ഒരു സംഭവത്തിൽ അടുത്തയാൾ അത് വീണ്ടും കണ്ടെത്തേണ്ടിവരാതിരിക്കാൻ.