VPN കണ്ടെയ്നറിലെ DNAT: INPUT അല്ല, ഫോർവേഡിംഗ്

DNAT-ന് ശേഷം ടണൽ വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥന ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കായി മാറുന്നു. ഫോർവേഡ് നിയമം ചുരുക്കുക, Docker ചെയിൻ വായിക്കുക, തിരിച്ചുവരവ് പാത ബോധപൂർവ്വം തിരഞ്ഞെടുക്കുക.

അഭ്യർത്ഥന ടണൽ IP വിലാസത്തിലേക്ക് എത്തി അതേ കണ്ടെയ്നറിൽ നിന്ന് അയൽ സേവനത്തിന്റെ വിലാസത്തിലേക്ക് പുറപ്പെടുന്നു. ഈ രണ്ട് നിമിഷങ്ങൾക്കിടയിൽ DNAT ലക്ഷ്യം വീണ്ടും എഴുതി, പാക്കറ്റ് VPN കണ്ടെയ്നറിനുള്ള ഇൻപുട്ട് ആയിരിക്കുന്നത് നിർത്തി. ഇപ്പോൾ അത് ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കാണ്, മറ്റൊരു നിയമം വിലയിരുത്തുന്നത്. ഈ മാറ്റമാണ് ടണൽ വിലാസത്തിന് ശരിയായി തോന്നുന്ന ഫയർവാൾ നിയമം വിവർത്തനം ചെയ്ത കണക്ഷനിൽ എന്തുകൊണ്ട് ഫലിക്കുന്നില്ല എന്ന് വിശദീകരിക്കുന്നത്.

വിവർത്തനത്തിന് ശേഷം പാക്കറ്റ് പിന്തുടരുക

10.90.0.0/24 ക്ലയന്റ് പൂളും 10.90.0.1 ടണൽ വിലാസവും എടുക്കുക. ഒരു ബ്രിഡ്ജിൽ രണ്ട് കണ്ടെയ്നറുകളുണ്ട്: 192.0.2.2 VPN ഉം 192.0.2.3 ആപ്ലിക്കേഷനും പ്രവർത്തിപ്പിക്കുന്നു. ഒരു ക്ലയന്റ് 10.90.0.1:8080 ലേക്ക് ബന്ധിപ്പിക്കുന്നു, VPN കണ്ടെയ്നറിന്റെ നെയിംസ്പേസിലെ DNAT നിയമം അത് ആപ്ലിക്കേഷന്റെ യഥാർത്ഥ വിലാസത്തിലേക്കും പോർട്ടിലേക്കും വീണ്ടും എഴുതുന്നു. പിന്നീട് ഒരു റൂട്ട് പാക്കറ്റ് ബ്രിഡ്ജിലൂടെ അയയ്ക്കുന്നു. ഈ വിലാസങ്ങൾ ഉദാഹരണമാണ്, വിന്യാസ പാചകക്കുറിപ്പല്ല.

ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ കേൾക്കുന്ന പോർട്ട് ഹോസ്റ്റിൽ പ്രസിദ്ധീകരിച്ച ഏത് പോർട്ടിൽ നിന്നും വ്യത്യസ്തമായിരിക്കാം. രണ്ട് സംഖ്യകളും ഒത്തുപോകുമെന്ന് കരുതുന്നതിന് പകരം കണ്ടെയ്നറിനുള്ളിലെ ശ്രോതാവ് വായിക്കുക.

അനുമതി ഫോർവേഡ് പാതയിലാണ്

VPN കണ്ടെയ്നറിന് IP ഫോർവേഡിംഗും ക്ലയന്റ് പൂൾ, ആപ്ലിക്കേഷൻ വിലാസം, ഉദ്ദേശിച്ച പോർട്ട് എന്നിവയിൽ ചുരുക്കിയ ഫോർവേഡിംഗ് തീരുമാനവും വേണം. സ്ഥാപിത മറുപടികൾക്ക് സ്വന്തം അനുമതി വേണം. യഥാർത്ഥ ടണൽ വിലാസവുമായി പൊരുത്തപ്പെടുന്ന നിയമം DNAT-ന് ശേഷം പൊരുത്തപ്പെടില്ല, കാരണം ലക്ഷ്യം ഇതിനകം മാറി. INPUT അനുമതി ഇനി ഈ ഹോസ്റ്റിനെ അഭിസംബോധന ചെയ്യാത്ത ട്രാഫിക്കിന് തെറ്റായ ഹുക്കാണ്.

പരിധി ഇടുങ്ങിയതായി സൂക്ഷിക്കുക: ഒരു ഉറവിട ശ്രേണി, ഒരു ലക്ഷ്യം, ഒരു സേവനം. അയഞ്ഞ ഫോർവേഡിംഗ് നിയമം എഴുതാൻ എളുപ്പവും പിന്നീട് സംരക്ഷിക്കാൻ വളരെ ബുദ്ധിമുട്ടും ആണ്.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker-ന്റെ ചെയിനുകൾ നിങ്ങളുടെ കണ്ടെയ്നറിന്റെ ചെയിനുകളല്ല

കണ്ടെയ്നർ നെയിംസ്പേസിനുള്ളിലെ നിയമങ്ങൾ Docker ഹോസ്റ്റിന്റെ നിയമങ്ങളല്ല. ട്രാഫിക് ടണൽ ഇന്റർഫേസിൽ നിന്ന് ബ്രിഡ്ജിലേക്ക് കടക്കുമ്പോൾ, ഹോസ്റ്റിലെ ബ്രിഡ്ജ് ഫയർവാൾ മറ്റൊരു തീരുമാനം എടുത്തേക്കാം. Docker-ന്റെ iptables ബാക്കെൻഡിൽ, രേഖപ്പെടുത്തിയ ഫോർവേഡിംഗ് ചെയിനുകളും DNAT-ന് ശേഷമുള്ള പൊരുത്തപ്പെടുത്തൽ പോയിന്റുകളുമാണ് ആ തീരുമാനം പ്രത്യക്ഷപ്പെടുന്ന സ്ഥലം.

Docker ഫയർവാൾ റഫറൻസ് ആ ചെയിനുകളും DNAT-ന് ശേഷമുള്ള പൊരുത്തപ്പെടുത്തലും വിവരിക്കുന്നു. Docker-ന്റെ ഫയർവാൾ മാനേജ്മെന്റ് ഓഫാക്കിയോ ഓരോ ചെയിനും അയഞ്ഞതാക്കിയോ നഷ്ടമായ അനുമതി ശരിയാക്കരുത്, കാരണം അത് നിങ്ങൾ ഉപയോഗിക്കാൻ ശ്രമിക്കുന്ന അതിർത്തി നീക്കം ചെയ്യുന്നു.

തിരിച്ചുവരവ് പാതയെ ബോധപൂർവ്വ തിരഞ്ഞെടുപ്പാക്കുക

ഉറവിട വിലാസം സംരക്ഷിക്കപ്പെട്ടാൽ, ആപ്ലിക്കേഷൻ 10.90.0.x കാണുന്നു, മറുപടികൾ VPN കണ്ടെയ്നറിലൂടെ തിരികെ അയയ്ക്കണം. അല്ലെങ്കിൽ അതിന്റെ സാധാരണ Docker ഗേറ്റ്വേ അവ ടണൽ സ്വന്തമല്ലാത്ത ഹോസ്റ്റിലേക്ക് അയയ്ക്കും. ബദൽ, VPN കണ്ടെയ്നറിൽ ഇടുങ്ങിയ ഉറവിട വിവർത്തനമാണ്, അത് മറുപടി ലളിതമാക്കുന്നു പക്ഷേ ആപ്ലിക്കേഷനിൽ നിന്ന് ക്ലയന്റിനെ മറയ്ക്കുന്നു. ബോധപൂർവ്വം തിരഞ്ഞെടുത്ത് ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് എഴുതിവയ്ക്കുക.

സാധാരണ ക്ലയന്റിൽ നിന്ന് പുതിയ അനുവദനീയ കണക്ഷൻ പരീക്ഷിച്ച്, ബന്ധമില്ലാത്ത പോർട്ടുകൾ അടഞ്ഞു നിൽക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. പാക്കറ്റ് അപ്രത്യക്ഷമാകുമ്പോൾ, VPN നെയിംസ്പേസ്, ആപ്ലിക്കേഷൻ നെയിംസ്പേസ്, ആപ്ലിക്കേഷന്റെ സ്വന്തം ലോഗ് എന്നിവ പരിശോധിക്കുക. ബ്രിഡ്ജ് ഗേറ്റ്വേയിലേക്കുള്ള ping സേവനത്തിനുള്ള സ്വീകാര്യതാ പരീക്ഷയല്ല.

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

അനുബന്ധ ലേഖനങ്ങൾ