VPN-ൽ Docker കണ്ടെയ്നർ എത്തിച്ചേരാനാവുന്നില്ലേ? സബ്നെറ്റുകൾ താരതമ്യം ചെയ്യുക
Docker നൽകുന്ന സബ്നെറ്റ് VPN-ഉം അവകാശപ്പെടുന്നു. രണ്ട് വിലാസ പ്ലാനുകളും താരതമ്യം ചെയ്ത്, വീണ്ടും കണക്റ്റ് ചെയ്യുമ്പോഴും നിലനിൽക്കുന്ന ഒരു പരിഹാരം തിരഞ്ഞെടുക്കുക.
ഓഫീസ് LAN-ൽ കണ്ടെയ്നറുകൾ പ്രതികരിക്കും, പക്ഷേ കമ്പനി VPN കണക്റ്റ് ചെയ്യുന്ന നിമിഷം അവ പ്രതികരിക്കുന്നത് നിർത്തും. കണ്ടെയ്നറിൽ ഒന്നും മാറിയിട്ടില്ല: റീസ്റ്റാർട്ടില്ല, ഇമേജ് അപ്ഡേറ്റില്ല, കോൺഫിഗറേഷൻ മാറ്റമില്ല. മാറിയത് ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടികയാണ്; ടണൽ ചേർത്ത ഒരു റൂട്ട് ഇപ്പോൾ Docker നൽകിയ വിലാസം ഉൾക്കൊള്ളുന്നു. ഒരു സബ്നെറ്റ് മാറ്റുന്നതിനോ VPN ഒഴിവാക്കൽ ആവശ്യപ്പെടുന്നതിനോ മുൻപ് രണ്ട് വിലാസ പ്ലാനുകളും അരികിൽ വയ്ക്കുക, കാരണം ഓരോ പരിഹാരവും വളരെ വ്യത്യസ്ത സമയം എടുക്കുന്നു.
കോൺഫിഗർ മാറ്റുന്നതിന് മുൻപ് റൂട്ട് വായിക്കുക
Docker യഥാർത്ഥത്തിൽ നിർമ്മിച്ച നെറ്റ്വർക്കിൽ നിന്ന് തുടങ്ങുക. IPAM ബ്ലോക്കാണ് വിലാസ പ്ലാൻ, സബ്നെറ്റാണ് പ്രധാനമായ വരി:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]സ്വതവേ ഓരോ പുതിയ പ്രോജക്റ്റിനും Compose /16 അനുവദിക്കുന്നു, അതിനാൽ രണ്ട് സേവനങ്ങൾക്ക് 65,536 വിലാസങ്ങളുള്ള ഒരു പരിധിക്കുള്ളിൽ ഇരിക്കാം. ഈ വീതിയാണ് ഓവർലാപ്പുകൾ സാധാരണമാകാനുള്ള കാരണം: ക്രമരഹിതമായി തിരഞ്ഞെടുത്ത ഒരു /16, ടണലിലൂടെ നിങ്ങൾ എത്തുന്ന ഒരു സൈറ്റ് വിഴുങ്ങാൻ മതിയാകും, ടണൽ വരുന്നതുവരെ ആരും അത് ശ്രദ്ധിക്കുകയുമില്ല.
തുടർന്ന് ഒരു കണ്ടെയ്നർ വിലാസത്തിനുള്ള റൂട്ട് തിരഞ്ഞെടുപ്പ് താരതമ്യം ചെയ്യുക — ഒരിക്കൽ ടണൽ ഓഫ് ആയിരിക്കുമ്പോൾ, ഒരിക്കൽ അത് ഓണായിരിക്കുമ്പോൾ:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1രണ്ട് തരം ഉത്തരങ്ങൾ വ്യത്യസ്ത സ്ഥലങ്ങളിലേക്ക് നയിക്കുന്നു. ഔട്ട്പുട്ടിൽ tun0, wg0 അല്ലെങ്കിൽ മറ്റൊരു ടണൽ ഉപകരണം പേരിട്ടാൽ, ഒരു VPN പ്രിഫിക്സ് ബ്രിഡ്ജ് റൂട്ടിനേക്കാൾ കുറഞ്ഞത് അത്രതന്നെ സ്പെസിഫിക് ആണ്, കൂടാതെ പാക്കറ്റ് ഒരിക്കലും കണ്ടെയ്നറിൽ എത്തുന്നില്ല. അത് ഇപ്പോഴും ബ്രിഡ്ജിനെ പേരിട്ടാൽ, ഹോസ്റ്റിന് കണ്ടെയ്നറിൽ എത്താം, നിങ്ങളുടെ തകരാർ ഫിൽട്ടറിംഗ്, DNS, അല്ലെങ്കിൽ ഒരു ദിശയിൽ മാത്രം പരാജയപ്പെടുന്ന ഒരു റിട്ടേൺ പാത്ത് എന്നിവയാണ്.
/16 കൂട്ടിയിടി എളുപ്പത്തിൽ സംഭവിക്കുന്നത് എന്തുകൊണ്ട്
Docker സ്വകാര്യ പൂളുകളിൽ നിന്നാണ് ബ്രിഡ്ജ് നെറ്റ്വർക്കുകൾ എടുക്കുന്നത്, സ്വതവേയുള്ള പൂൾ 172.16.0.0/12 ബ്ലോക്കിൽ നിന്ന് /16 കഷണങ്ങളായി വരുന്നു. കോർപ്പറേറ്റ് നെറ്റ്വർക്കുകൾ പലപ്പോഴും അതേ സ്വകാര്യ സ്ഥലം ഉപയോഗിക്കുന്നു, റിമോട്ട് ആക്സസ് VPN ആ പ്രിഫിക്സുകൾ കണക്റ്റ് ചെയ്യുന്ന ഓരോ ക്ലയന്റിലേക്കും തള്ളുന്നു. ഇരു വശവും 172.18.0.0/16 തങ്ങളുടേതാണെന്ന് വിശ്വസിക്കുമ്പോൾ, ഒരു റൂട്ടിംഗ് പട്ടികയിൽ രണ്ട് വിരുദ്ധ അവകാശവാദങ്ങൾ ഉണ്ടാകും.
പ്രിഫിക്സ് നീളമാണ് വിജയിയെ തീരുമാനിക്കുന്നത്, റൂട്ടുകളുടെ ക്രമമല്ല. 10.0.0.0/8 തള്ളുന്ന ഒരു ടണൽ 172.18.0.0/16 എന്ന ബ്രിഡ്ജ് റൂട്ടിനെ തോൽപ്പിക്കുന്നില്ല, കാരണം /8 കുറച്ചുകൂടി വിശാലമാണ്. 172.18.0.0/16, അല്ലെങ്കിൽ അതിനുള്ളിലെ 172.18.5.0/24 തള്ളുന്ന ടണൽ തോൽപ്പിക്കുന്നു. അതുകൊണ്ടാണ് ഒരു ലാപ്ടോപ്പ് ഓഫീസ് നെറ്റ്വർക്കിൽ പ്രവർത്തിക്കുകയും അതേ VPN-ൽ ഹോട്ടൽ Wi-Fi-ൽ പരാജയപ്പെടുകയും ചെയ്യുന്നത്: ക്ലയന്റിന് വ്യത്യസ്ത പ്രിഫിക്സുകൾ ലഭിക്കുന്നു.
അതേ പട്ടിക മറുവശം നിയന്ത്രിക്കുന്നു. 10.8.4.20 എന്ന വിലാസത്തിലുള്ള ഒരു ആന്തരിക ഹോസ്റ്റ് വേണ്ട കണ്ടെയ്നർ, പാക്കറ്റ് അതിന്റെ ബ്രിഡ്ജ് ഗേറ്റ്വേയിലേക്ക് അയക്കുന്നു, തുടർന്ന് ഹോസ്റ്റ് അതിനെ ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്നു. ഹോസ്റ്റ് NAT നിർവഹിക്കുന്നതിനാൽ ഈ പാത്ത് സാധാരണയായി പ്രവർത്തിക്കുന്നു, പക്ഷേ കോർപ്പറേറ്റ് വശം ലാപ്ടോപ്പിന്റെ VPN വിലാസം മാത്രം സ്വീകരിക്കുമ്പോൾ, അല്ലെങ്കിൽ റിവേഴ്സ് പാത്ത് ഫിൽട്ടറിംഗ് അസമമായ മറുപടി ഉപേക്ഷിക്കുമ്പോൾ അത് പരാജയപ്പെടുന്നു.
മൂന്ന് പരിഹാരങ്ങൾ താരതമ്യം ചെയ്യുക
മൂന്ന് മാർഗങ്ങൾ മാത്രമേയുള്ളൂ, അവ ആര് അനുവദിക്കണം, ഒന്ന് പ്രയോഗിക്കുമ്പോൾ എന്ത് തകരും എന്നതിൽ അവ വ്യത്യാസപ്പെടുന്നു.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
ടിക്കറ്റില്ലാതെ പൂർത്തിയാക്കാവുന്ന ഏക പരിഹാരം പുനർനമ്പറിംഗ് മാത്രമാണ്, അതുകൊണ്ടാണ് മിക്ക ലേഖനങ്ങളും അവിടെ നിർത്തുന്നത്. പുതിയ പ്രോജക്റ്റിൽ ഇത് വിലകുറഞ്ഞതാണ്, പക്ഷേ ഒരു മൈഗ്രേഷൻ ടൂൾ അല്ലെങ്കിൽ സംഭരിച്ച കണക്ഷൻ സ്ട്രിംഗ് ഒരു നേരിട്ടുള്ള വിലാസത്തിലേക്ക് ചൂണ്ടിയാൽ അത് ചെലവേറിയതാകും. YAML തിരുത്തുന്നതിന് മുൻപ് ആ റഫറൻസുകൾ എണ്ണുക, അതിനു ശേഷമല്ല.
നിങ്ങളുടെ കമ്പനിക്ക് യഥാർത്ഥത്തിൽ ഉടമസ്ഥതയുള്ള ഒരു പരിധിയിലാണ് ഓവർലാപ്പ് എങ്കിൽ ടണലിൽ നിന്നുള്ള ഒഴിവാക്കലാണ് ഏറ്റവും വ്യക്തമായ ഉത്തരം. അതേ സമയം അത് ഏറ്റവും സാവധാനവുമാണ്, ക്ലയന്റ് പ്രൊഫൈൽ മാറ്റാൻ കഴിയാത്ത ഒരു കരാറുകാരന് അത് ഉപകാരപ്രദമല്ല. പ്രസിദ്ധീകരിച്ച ഒരു പോർട്ട് അല്ലെങ്കിൽ ചെറിയൊരു റിവേഴ്സ് പ്രോക്സി ഈ തർക്കം ഒഴിവാക്കുന്നു: ടണൽ ഇതിനകം ശരിയായി റൂട്ട് ചെയ്യുന്ന ഒരു വിലാസവുമായാണ് ക്ലയന്റ് സംസാരിക്കുന്നത്, ആ പോർട്ട് മാത്രമേ എത്തിച്ചേരാവുന്നതാകേണ്ടതുള്ളൂ.
ബോധപൂർവം ഒരു പരിധി ഉറപ്പിക്കുക
ഒരു പ്രോജക്റ്റിന്, പങ്കിട്ട പൂളിൽ നിന്ന് എടുക്കുന്നത് നിർത്താൻ compose ഫയലിൽ സബ്നെറ്റ് പ്രഖ്യാപിക്കുക:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24ആ പരിധി, തിരയുമ്പോൾ കണ്ട ഒരു ഉദാഹരണത്തിൽ നിന്നല്ല, നിങ്ങളുടെ ടീം സൂക്ഷിക്കുന്ന ഒരു രജിസ്ട്രിയിൽ നിന്ന് എടുക്കുക. VPN തള്ളുന്ന പ്രിഫിക്സുകൾ, ആളുകൾ ജോലി ചെയ്യുന്ന വീട്ടിലെ LAN-കൾ, അതേ ഹോസ്റ്റിലെ മറ്റ് കണ്ടെയ്നർ നെറ്റ്വർക്കുകൾ എന്നിവയുമായി അത് പരിശോധിക്കുക. തുടർന്ന് പുനർനിർമ്മാണം ആസൂത്രണം ചെയ്യുക, കാരണം നിലവിലുള്ള ഒരു നെറ്റ്വർക്ക് അതിന്റെ പഴയ സബ്നെറ്റ് നിലനിർത്തുന്നു: docker compose down, തുടർന്ന് up -d. എൻഡ്പോയിന്റുകൾ ഘടിപ്പിച്ചിരിക്കുമ്പോൾ docker network rm വിസമ്മതിക്കുന്നു, ഫയലിലെ ഏതെങ്കിലും ipv4_address എൻട്രി പുതിയ പരിധിക്കുള്ളിൽ വരണം.
Docker സ്വയം സൃഷ്ടിക്കുന്ന നെറ്റ്വർക്കുകൾക്ക്, /etc/docker/daemon.json എന്നതിൽ ഒരു daemon പൂൾ സജ്ജമാക്കുക:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}daemon പുനരാരംഭിച്ചതിന് ശേഷം സൃഷ്ടിക്കുന്ന നെറ്റ്വർക്കുകൾക്കാണ് ഈ പൂൾ ബാധകമാകുന്നത്, ഇതിനകം നിലവിലുള്ള ബ്രിഡ്ജുകൾ അവയുടെ വിലാസങ്ങൾ നിലനിർത്തുന്നു. അത് സൗകര്യപ്രദവും മറക്കാൻ എളുപ്പവുമാണ്, അതിനാൽ ആരെങ്കിലും അതിന്റെ നെറ്റ്വർക്ക് പുനർനിർമ്മിക്കുന്നതുവരെ പഴയ പ്രോജക്റ്റിനെ ഇപ്പോഴും ഓവർലാപ്പ് ചെയ്യുന്നതായി കണക്കാക്കുക. Docker-ന്റെ എൻജിൻ നെറ്റ്വർക്കിംഗ് ഡോക്യുമെന്റേഷൻ അനുവദനീയമായ നിയമങ്ങൾ വിവരിക്കുന്നു, അവലോകനത്തിൽ പൂളിനെ ന്യായീകരിക്കേണ്ടി വന്നാൽ.
Linux ബ്രിഡ്ജും Docker Desktop-ും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു
Linux ഹോസ്റ്റിൽ, കണ്ടെയ്നറുകൾ ഹോസ്റ്റ് നെയിംസ്പേസിലെ ബ്രിഡ്ജുകളിൽ ഇരിക്കുന്നു. ഒരു പട്ടികയാണ് എല്ലാം തീരുമാനിക്കുന്നത്, അതിനാൽ മുകളിലെ താരതമ്യമാണ് മുഴുവൻ കഥ: ബ്രിഡ്ജ് റൂട്ട് വായിക്കുക, ടണൽ റൂട്ട് വായിക്കുക, ഒരു യഥാർത്ഥ കണ്ടെയ്നർ വിലാസത്തിന് ഏതാണ് ജയിക്കുന്നതെന്ന് നോക്കുക.
Docker Desktop കണ്ടെയ്നറുകളെ സ്വന്തം NAT ഉള്ള ഒരു VM-ന് പിന്നിലാക്കുന്നു. ഹോസ്റ്റിന് കണ്ടെയ്നർ വിലാസത്തിലേക്ക് ഒരു റൂട്ടും ഇല്ല; പ്രസിദ്ധീകരിച്ച ഒരു പോർട്ടിലൂടെയാണ് അത് സേവനത്തിൽ എത്തുന്നത്, സാധാരണയായി 127.0.0.1 എന്നതിലേക്ക് ബന്ധിച്ചിരിക്കുന്നു. അതിനാൽ ഒരു VPN ക്ലയന്റിന് ഒരു സബ്നെറ്റ് ഓവർലാപ്പും ഇല്ലാതെ സേവനം തകർക്കാം: VM-ന്റെ ആന്തരിക പരിധിക്ക് ഒരു റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തുകൊണ്ടോ, ടണൽ കണക്റ്റ് ചെയ്തിരിക്കുമ്പോൾ loopback ട്രാഫിക് തടയുന്നതിലൂടെയോ. ഹോസ്റ്റിലെ ip route get കണ്ടെയ്നർ വിലാസത്തിന് റൂട്ട് ഇല്ലെന്ന് റിപ്പോർട്ട് ചെയ്താൽ, അത് പ്രതീക്ഷിതമാണ്, ബഗ് അല്ല.
പ്രായോഗിക പരിണാമം നിങ്ങൾ ആദ്യം എവിടെ നോക്കുന്നു എന്നതിലാണ്. Linux-ൽ, റൂട്ടിംഗ് പട്ടികയിൽ നിന്ന് തുടങ്ങുക. Desktop-ൽ, പ്രസിദ്ധീകരിച്ച പോർട്ടിൽ നിന്നും VPN ക്ലയന്റിന്റെ ഫയർവാൾ നിയമങ്ങളിൽ നിന്നും തുടങ്ങുക, തുടർന്ന് VM-ന്റെ ആന്തരിക സബ്നെറ്റ് ടണൽ തള്ളുന്ന എന്തെങ്കിലുമായി കൂട്ടിയിടിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
ടണൽ ഓണാക്കി പരിശോധിക്കുക
ഇത് ശരിയായി എന്ന് പറയുന്നതിന് മുൻപ് VPN രണ്ടുതവണ വീണ്ടും കണക്റ്റ് ചെയ്യുക, കാരണം കണക്റ്റ് ചെയ്യുമ്പോൾ റൂട്ടുകൾ തള്ളുകയും ഡിസ്കണക്റ്റ് ചെയ്യുമ്പോൾ അവ പിൻവലിക്കുകയും ചെയ്യുന്ന ഒരു പ്രൊഫൈൽ ആദ്യ ശ്രമത്തിന് ശേഷം ശരിയെന്ന് തോന്നിപ്പിക്കാം. തുടർന്ന് ക്ലയന്റ് യഥാർത്ഥത്തിൽ നടത്തുന്ന പരിശോധനകൾ നടത്തുക:
- കണ്ടെയ്നറിന്റെ യഥാർത്ഥ വിലാസം ഉപയോഗിച്ച് ഹോസ്റ്റിൽ നിന്ന്
ip route get. - സേവനം തന്നെ ആരോഗ്യകരമാണെന്ന് തെളിയിക്കാൻ മറ്റൊരു കണ്ടെയ്നറിൽ നിന്നുള്ള ഒരു അഭ്യർത്ഥന.
- ടണൽ ഓണായിരിക്കുമ്പോൾ ക്ലയന്റിൽ നിന്ന്
curl -sv http://127.0.0.1:8080/, തുടർന്ന് LAN-ലെ ഒരു മെഷീനിൽ നിന്ന് കണ്ടെയ്നർ വിലാസത്തിലേക്ക്traceroute -n. - അഭ്യർത്ഥന ഹോസ്റ്റിൽ എത്തിയിട്ട് മറുപടി അപ്രത്യക്ഷമാകുകയാണെങ്കിൽ
sysctl net.ipv4.conf.all.rp_filter.
അവസാനം, തിരഞ്ഞെടുത്ത പരിധി അത് തിരഞ്ഞെടുക്കാൻ ഉപയോഗിച്ച അതേ രജിസ്ട്രിയിൽ തീയതിയും അതിന്റെ ഉടമസ്ഥതയിലുള്ള പ്രോജക്റ്റും സഹിതം എഴുതുക. അടുത്ത ഓവർലാപ്പ് ആരും രേഖപ്പെടുത്താത്ത ഒരു പ്രോജക്റ്റിൽ നിന്നായിരിക്കും വരിക, ഒരേയൊരു പ്രതിരോധം പരിധി ക്രമരഹിതമായി എടുക്കുന്നതിന് പകരം ബോധപൂർവം മാറ്റിവയ്ക്കുക എന്നതാണ്.