Docker-ന്റെ pool ഓവർലാപ്പ് പിശക് VPN റൂട്ടിന്റെ പ്രശ്നമല്ല

Docker ഈ വിലാസ ഇടത്തിൽ pool മറ്റൊന്നുമായി ഓവർലാപ്പ് ചെയ്യുന്നു എന്ന സന്ദേശത്തോടെ നെറ്റ്വർക്ക് സൃഷ്ടിക്കാൻ വിസമ്മതിക്കുന്നു, ഒപ്പം VPN റൂട്ട് തന്നെ കാരണമായിരിക്കണം എന്ന് ആരോ തീരുമാനിക്കുന്നു. അത് ആകാൻ കഴിയില്ല. ആ പിശക് ഒരു pool അനുവദിക്കപ്പെടുമ്പോൾ, ഒരു പാക്കറ്റ് പോലും നിലവിലില്ലാത്തപ്പോൾ ഉണ്ടാകുന്നു, കൈകൊണ്ടുള്ള കെർണൽ റൂട്ടിന് അതിൽ യാതൊരു സ്വാധീനവുമില്ല. VPN ഒരു ഘട്ടം കഴിഞ്ഞാണ് പ്രധാനമാകുന്നത്, ഇതിനകം വിലാസമുള്ള ഒരു കണ്ടെയ്നർ ഒരു റൂട്ട് പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം എത്തിപ്പെടാനാകാത്തതാകുമ്പോൾ. രണ്ട് പ്രശ്നങ്ങൾ, രണ്ട് തെളിവ് കൂട്ടങ്ങൾ, അവ കൂട്ടിക്കലർത്തുന്നത് രണ്ടിനെയും ശരിയാക്കാത്ത ഒരു മാറ്റം ഉണ്ടാക്കുന്നു.

ഒരുപോലെ തോന്നുന്ന രണ്ട് പിശകുകൾ

അനുവദന പിശക് ഗണിതപരമാണ്. Docker നിങ്ങൾ ആവശ്യപ്പെട്ട സബ്നെറ്റിനെ അത് ഇതിനകം നിയന്ത്രിക്കുന്ന സബ്നെറ്റുകളുമായി താരതമ്യം ചെയ്ത്, ഒരു ഛേദനം കണ്ടെത്തി വിസമ്മതിക്കുന്നു. ഇനിയും ഒന്നും പ്രവർത്തിക്കുന്നില്ല, അതിനാൽ റൂട്ടില്ല, കണ്ടെയ്നറില്ല, പരിശോധിക്കാൻ ട്രാഫിക്കുമില്ല.

റൺടൈം ലക്ഷണം എത്തിപ്പെടാനുള്ള കഴിവിന്റെ ചോദ്യമാണ്. ഇന്നലെ ഉത്തരം നൽകിയ ഒരു കണ്ടെയ്നർ ഇപ്പോൾ ഉത്തരം നൽകുന്നില്ല, ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടികയിൽ എന്തോ മാറി. കണ്ടെയ്നർ ഇപ്പോഴും അതിന്റെ വിലാസം കൈവശം വയ്ക്കുന്നു; ചോദ്യം ആ വിലാസം ഏത് വഴിയാണ് എടുക്കുന്നത് എന്നതാണ്.

രണ്ടും വിലാസ പ്ലാനിന്റെ പ്രശ്നങ്ങളാണ്. അവയിൽ ഒന്ന് മാത്രമാണ് Docker-ന്റെ പ്രശ്നം.

ആദ്യം അനുവദിച്ച pool-കൾ വായിക്കുക

നെറ്റ്വർക്കുകൾ ലിസ്റ്റ് ചെയ്ത് ഛേദിക്കാൻ കഴിയുന്നവ പരിശോധിക്കുക. സബ്നെറ്റ് IPAM കോൺഫിഗറേഷനിലാണ്, ബന്ധിപ്പിച്ച കണ്ടെയ്നറുകൾ വെവ്വേറെ ലിസ്റ്റ് ചെയ്യുന്നു:

docker network ls
docker network inspect EXISTING_NETWORK

ആ സബ്നെറ്റിനെ പുതിയ നെറ്റ്വർക്ക് ആവശ്യപ്പെടുന്ന pool-മായി താരതമ്യം ചെയ്യുക, Compose ഓരോ പ്രോജക്റ്റിനും സ്വന്തം ഡിഫോൾട്ട് നെറ്റ്വർക്ക് സൃഷ്ടിക്കുന്നു എന്ന് ഓർക്കുക. മറന്നുപോയ ഒരു പ്രോജക്റ്റുമായുള്ള സംഘർഷം ഡെമണുമായുള്ള സംഘർഷം പോലെ തന്നെ തോന്നുന്നു.

ഒരു സേവനത്തിലെ സ്റ്റാറ്റിക് ipv4_address ഒരു കണ്ടെയ്നറുടെ വിലാസമാണ്, pool-ന്റെ നിർവചനമല്ല. അത് മാറ്റുന്നത് ഓവർലാപ്പ് നീക്കില്ല, കാരണം ഓവർലാപ്പ് കണ്ടെയ്നറുകൾക്കിടയിലല്ല, നെറ്റ്വർക്ക് സബ്നെറ്റുകൾക്കിടയിലാണ്. Docker-ന്റെ network-create റഫറൻസ് സാധാരണ ബ്രിഡ്ജ് അനുവദനത്തിന് ഓവർലാപ്പ് ഇല്ലാത്ത സബ്നെറ്റുകൾ ആവശ്യപ്പെടുന്നു, ഒന്ന് വ്യക്തമായി തിരഞ്ഞെടുക്കുന്ന വിധം രേഖപ്പെടുത്തുന്നു.

VPN-യെ അതിജീവിക്കുന്ന ഒരു പ്രിഫിക്സ് തിരഞ്ഞെടുക്കുക

തൽക്ഷണ സംഘർഷവും ഭാവി റൂട്ടും ഒരേ തിരഞ്ഞെടുപ്പാണ് നിർണ്ണയിക്കുന്നത്, അതിനാൽ അത് ഒരിക്കൽ ചെയ്യുക. സ്ഥാനാർത്ഥി ശ്രേണിയെ LAN-മായി, ഹോസ്റ്റിന് എത്താനാകുന്ന ഓരോ VPN ലക്ഷ്യസ്ഥാനവുമായി, ഉപയോഗത്തിലുള്ള മറ്റേതെങ്കിലും overlay-മായി താരതമ്യം ചെയ്യുക.

Docker-നെ തൃപ്തിപ്പെടുത്തുകയും വിദൂര നെറ്റ്വർക്കുമായി കൂട്ടിയിടിക്കുകയും ചെയ്യുന്ന ഒരു പ്രിഫിക്സ് വൃത്തിയായി ആരംഭിച്ച് ടണൽ ഉയരുന്ന നിമിഷം എത്തിപ്പെടാനാകാത്തതാകുന്ന ഒരു കണ്ടെയ്നർ നൽകുന്നു. ഇതാണ് ഈ ലേഖനത്തിലെ രണ്ടാമത്തെ പിശക്, ഇപ്പോൾ ഒഴിവാക്കുന്നതിനേക്കാൾ പിന്നീട് രോഗനിർണയം ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

തിരഞ്ഞെടുത്ത ശ്രേണികൾ അടുത്ത പ്രോജക്റ്റിന് വായിക്കാനാകുന്ന ഒരിടത്ത് എഴുതിവയ്ക്കുക. അനുവദിച്ച പ്രിഫിക്സുകളുടെ ഒരു വരി രജിസ്റ്റർ വിശദീകരണമില്ലാത്ത ഒരാഴ്ചത്തെ ടൈംഔട്ടുകളേക്കാൾ വിലകുറഞ്ഞതാണ്.

നെറ്റ്വർക്ക് ബോധപൂർവ്വം ഒഴിവാക്കുകയോ മാറ്റുകയോ ചെയ്യുക

പുതിയ Compose നെറ്റ്വർക്കിന്, നെറ്റ്വർക്കിന്റെ IPAM കോൺഫിഗറേഷനിൽ ഉപയോഗിക്കാത്ത പ്രിഫിക്സ് സെറ്റ് ചെയ്യുക. നിലവിലുള്ള ഒരു പ്രോജക്റ്റിന്, പുനർസംഖ്യാക്രമണം ആസൂത്രണം ചെയ്യുക: സ്ഥിര വിലാസങ്ങൾ, ആശ്രിത സേവനങ്ങൾ, നെറ്റ്വർക്ക് വീണ്ടും സൃഷ്ടിക്കുന്ന ഘട്ടം എന്നിവയെല്ലാം കണക്കിലെടുക്കണം, കാരണം YAML എഡിറ്റ് ചെയ്യുന്നത് പ്രവർത്തിക്കുന്ന നെറ്റ്വർക്കിനെ പുനർസംഖ്യാക്രമീകരിക്കുന്നില്ല.

ഒരു കാലഹരണപ്പെട്ട നെറ്റ്വർക്ക് സംഘർഷമുള്ള അനുവദനം കൈവശം വയ്ക്കുന്നുവെങ്കിൽ, അത് നീക്കം ചെയ്യുന്നതിന് മുമ്പ് ആരാണ് ബന്ധിപ്പിച്ചിരിക്കുന്നതെന്ന് പരിശോധിക്കുക. docker network rm സജീവ endpoint-കൾ ഉള്ളിടത്തോളം വിസമ്മതിക്കുന്നു, docker stop നെറ്റ്വർക്ക് പേരിന് പകരം കണ്ടെയ്നർ പേരുകളോ ID-കളോ എടുക്കുന്നു. ഒരു കണ്ടെയ്നർ നിർത്തുന്നത് pool കൈവശം വയ്ക്കുന്ന നെറ്റ്വർക്ക് നിർവചനം നീക്കം ചെയ്യുന്നുമില്ല.

വിശാലമായ prune ഒരു രോഗനിർണയ ഉപകരണമല്ല. അത് ബന്ധമില്ലാത്ത പ്രോജക്റ്റുകളിൽ എത്തി നിങ്ങൾ ശേഖരിക്കാൻ പോകുന്ന തെളിവുകൾ നശിപ്പിക്കുന്നു.

ഡിഫോൾട്ട് pool-കൾ അടുത്ത അനുവദനത്തിന് മാത്രം സഹായിക്കുന്നു

ഡെമണിന്റെ ഡിഫോൾട്ട് വിലാസ pool ക്രമീകരണം ഭാവിയിലെ സ്വയമേവയുള്ള അനുവദനങ്ങൾ നിങ്ങൾ റിസർവ് ചെയ്യുന്ന ശ്രേണികൾക്ക് പുറത്ത് നിർത്തി മെച്ചപ്പെടുത്തുന്നു. അത് ഇതിനകം നിലവിലുള്ള നെറ്റ്വർക്കുകൾക്ക് പിന്നോട്ട് പുതിയ വിലാസങ്ങൾ നൽകുന്നില്ല, മറ്റൊരു വ്യക്തമായ സബ്നെറ്റുമായി ഓവർലാപ്പ് ചെയ്യുന്ന വ്യക്തമായ സബ്നെറ്റ് പരിഹരിക്കുന്നുമില്ല.

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

സൃഷ്ടി വിജയിച്ചതിന് ശേഷം, യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന സബ്നെറ്റ് പരിശോധിച്ച്, VPN അതിന്റെ ഉദ്ദേശിച്ച അവസ്ഥയിൽ നിർത്തി ഒരു യഥാർത്ഥ ആപ്ലിക്കേഷൻ അഭ്യർത്ഥന നടത്തുക. pool സാധുവാണെങ്കിലും പ്രവേശനം ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ, ശേഷിക്കുന്ന ജോലി റൂട്ട് തിരഞ്ഞെടുപ്പ്, ഫിൽട്ടറിംഗ്, മടങ്ങിവരവ് പാത എന്നിവയാണ്. അത് ഒരു റൺടൈം അന്വേഷണമാണ്, അത് അനുവദന പിശകിനെ പിന്നോട്ട് അർത്ഥശൂന്യമാക്കുന്നില്ല.

ജോലിയുടെ ക്രമം: അനുവദിച്ച pool-കൾ വായിക്കുക, Docker-നെയും VPN ലക്ഷ്യങ്ങളെയും ഒരുപോലെ ഒഴിവാക്കുന്ന ഒരു പ്രിഫിക്സ് തിരഞ്ഞെടുക്കുക, നെറ്റ്വർക്ക് ബോധപൂർവ്വം വീണ്ടും സൃഷ്ടിക്കുക, തുടർന്ന് ടണൽ ഉയർത്തിയ അവസ്ഥയിൽ ഒരു അഭ്യർത്ഥന പരീക്ഷിക്കുക.