Docker: VPN സെഷൻ സമയത്ത് മുൻകൂട്ടി നിർവചിച്ച വിലാസ പൂളുകൾ ഒന്നും ബാക്കിയില്ല

പരാജയം വ്യക്തമാണ്: പുതിയ ബ്രിഡ്ജ് നെറ്റ്‌വർക്കിനായി സ്വീകാര്യമായ ഒരു സ്വയമേവയുള്ള സബ്‌നെറ്റ് Docker-ന് കണ്ടെത്താനാകുന്നില്ല. യന്ത്രത്തിന്റെ വിലാസങ്ങൾ തീർന്നു എന്നോ VPN തകർന്നു എന്നോ ഇത് അർത്ഥമാക്കുന്നില്ല. രോഗനിർണയം രണ്ട് ചോദ്യങ്ങൾ തീരുമാനിക്കുന്നു: ഡീമണിന് ഏത് സ്ഥാനാർത്ഥി ബ്ലോക്കുകൾ കാണാനാകും, ഈ പരിതസ്ഥിതിയിൽ അതിന്റെ അനുവദനക്കാരൻ അവയിൽ ഏതൊക്കെ ഒഴിവാക്കുന്നു. അവ അതേ ക്രമത്തിൽ കൈകാര്യം ചെയ്യുക, കാരണം ആദ്യ ചോദ്യത്തിന് ഉത്തരം ലഭിക്കുന്നതുവരെ രണ്ടാമത്തെ ചോദ്യത്തിന് അർത്ഥമില്ല.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് എന്താണ് പരാജയപ്പെട്ടതെന്ന് സ്ഥിരീകരിക്കുക

താഴെയുള്ള ഘട്ടങ്ങൾ ഡീമൺ പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുക. ദൂരസ്ഥ കോൺടെക്സ്റ്റുമായി സംസാരിക്കുന്ന ഷെൽ മറ്റൊരു യന്ത്രത്തെ വിവരിക്കുന്നു, ആ തെറ്റ് മാത്രം ഒരു മണിക്കൂർ പാഴാക്കാം.

അതേ സമയം ടിക്കറ്റിൽ Engine പതിപ്പ് കുറിച്ചിടുക. ഈ റൺബുക്കിന്റെ ബാക്കി ഭാഗത്തെ ഓരോ ഹ്യൂറിസ്റ്റിക്കും പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു, പതിപ്പില്ലാത്ത അവകാശവാദം കിംവദന്തിയാണ്.

നിങ്ങൾക്ക് ഇപ്പോൾ ഉള്ള അനുവദനങ്ങൾ എണ്ണുക

നെറ്റ്‌വർക്കുകൾ ലിസ്റ്റ് ചെയ്ത്, പിന്നീട് പ്രധാനപ്പെട്ടവ പരിശോധിക്കുക: docker network ls, തുടർന്ന് docker network inspect NETWORK_NAME. അവയുടെ IPAM സബ്‌നെറ്റുകളും ഓരോന്നിനോട് ബന്ധിപ്പിച്ച കണ്ടെയ്നറുകളും വായിക്കുക. നിരവധി Compose പ്രോജക്റ്റുകൾ കണ്ടെയ്നർ എണ്ണം സൂചിപ്പിക്കുന്നതിലും കൂടുതൽ ബ്ലോക്കുകൾ ഉപയോഗിക്കുന്നു, കാരണം ഓരോ പ്രോജക്റ്റും സ്വന്തം സ്ഥിരസ്ഥിതി നെറ്റ്‌വർക്ക് സൃഷ്ടിക്കാൻ ചായ്‌വ് കാണിക്കുന്നു. നിർത്തിയ കണ്ടെയ്നർ അതിന്റെ നെറ്റ്‌വർക്കിന്റെ അനുവദനം വിട്ടുകൊടുക്കുന്നില്ല.

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

എണ്ണം കുറിച്ചിടുക. അടുത്ത മാറ്റം സഹായിച്ചോ ഇല്ലയോ എന്ന് പറയുന്ന അടിസ്ഥാന രേഖ അതാണ്.

ഡീമൺ റൂട്ടുകളെ എങ്ങനെ കാണുന്നു എന്ന് താരതമ്യം ചെയ്യുക

VPN സ്ഥാനാർത്ഥി തിരഞ്ഞെടുപ്പിനെ സ്വാധീനിക്കാം, പക്ഷേ എങ്ങനെ എന്നത് കൃത്യമായ നിർവ്വഹണം തീരുമാനിക്കുന്നു. Linux-ലെ Moby 28.2.2-ൽ, InferReservedNetworks നെയിംസർവർ വിലാസങ്ങളും ചില ഓൺ-ലിങ്ക് IPv4 റൂട്ടുകളും ശേഖരിക്കുന്നു, എല്ലാ പട്ടികയിലെയും എല്ലാ റൂട്ടും അത് ലളിതമായി സംരക്ഷിക്കുന്നില്ല. ശേഖരിച്ച ലിങ്ക് റൂട്ടുകൾ വ്യക്തമാക്കാത്ത ലക്ഷ്യ വിലാസവും ഒഴിവാക്കുന്നു, അതിനാൽ ഒരു 0.0.0.0/1 റൂട്ട് മാത്രം എല്ലാ വിലാസങ്ങളും സംരക്ഷിക്കുന്നില്ല. മറ്റൊരു വിശാലമായ ഓൺ-ലിങ്ക് പ്രിഫിക്സ്, ഉദാഹരണത്തിന് 128.0.0.0/1, പരിചിതമായ 172, 192 സ്ഥാനാർത്ഥി ശ്രേണികളെ ഛേദിക്കാം.

VPN ബന്ധിപ്പിക്കുന്നതിന് മുമ്പും ശേഷവും ip -4 route show table all ഡീമണിന്റെ ഹോസ്റ്റിൽ താരതമ്യം ചെയ്യുക. വ്യത്യാസമാണ് തെളിവ്, പതിപ്പാണ് അവകാശവാദത്തിന്റെ പരിധി.

ഒരു റിലീസിന്റെ ഹ്യൂറിസ്റ്റിക്ക് എല്ലാ റിലീസുകൾക്കും പൊതുവാക്കരുത്. അങ്ങനെയാണ് ഒരു ഫോറം ഉത്തരം നയ മാറ്റമായി മാറുന്നത്.

പ്രവർത്തിക്കുന്ന ഏറ്റവും ചെറിയ തിരുത്ത് തിരഞ്ഞെടുക്കുക

സ്ഥിരീകരിച്ച ഉപയോഗിക്കാത്ത നെറ്റ്‌വർക്ക് നിങ്ങൾക്ക് ആവശ്യമുള്ള ഒരു ബ്ലോക്ക് കൈവശം വെക്കുന്നുണ്ടെങ്കിൽ, വിശാലമായി വെട്ടിച്ചുരുക്കുന്നതിന് പകരം ഉടമയുമായി അതിന്റെ ലക്ഷ്യബദ്ധമായ ഒഴിവാക്കൽ ആസൂത്രണം ചെയ്യുക. പുതിയ നെറ്റ്‌വർക്കിന്, വ്യക്തമായി അവലോകനം ചെയ്ത ഉപയോഗിക്കാത്ത സബ്‌നെറ്റ് സ്വയമേവയുള്ള തിരഞ്ഞെടുപ്പിനെ ആശ്രയിക്കുന്നത് പൂർണ്ണമായി ഒഴിവാക്കുന്നു. ആ സബ്‌നെറ്റ് ഇപ്പോഴും യഥാർത്ഥ Docker, LAN, ആവശ്യമായ VPN ലക്ഷ്യങ്ങൾ ഒഴിവാക്കണം, കാരണം സ്വകാര്യം എന്നത് സുരക്ഷിതം എന്നല്ല. യഥാർത്ഥ ദൂരസ്ഥ പ്രിഫിക്സ് റൂട്ട് ചെയ്യുന്നത് അനുവദന പിശക് തകർന്ന ആക്സസുമായി കൈമാറും.

default-address-pools മാറ്റുന്നത് ഭാവി അനുവദനങ്ങളെക്കുറിച്ചുള്ള വിശാലമായ നയമാണ്. കൂട്ടിയിടിയില്ലാത്ത അടിസ്ഥാനവും ഉചിതമായ അനുവദിച്ച വലിപ്പവും തിരഞ്ഞെടുക്കുക, അത് നിലവിലുള്ള ഡീമൺ ക്രമീകരണങ്ങളുമായി ലയിപ്പിക്കുക, രേഖപ്പെടുത്തിയ റീസ്റ്റാർട്ട് ആഘാതം ആസൂത്രണം ചെയ്യുക. നിലവിലുള്ള നെറ്റ്‌വർക്കുകൾ നിശ്ശബ്ദമായി പുനർനമ്പർ ചെയ്യപ്പെടുന്നില്ല.

അനുവദനം വിജയിക്കാൻ കമ്പനി റൂട്ട് പുഷുകൾ അപ്രാപ്തമാക്കരുത്. വ്യക്തമായ വിലാസ പ്ലാൻ സാധാരണയായി നിർബന്ധിത നയം ദുർബലപ്പെടുത്താതെ പ്രാദേശിക പ്രശ്നം പരിഹരിക്കുന്നു.

അനുവദനവും റൂട്ടിംഗും വെവ്വേറെ സ്വീകരിക്കുക

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

റൂട്ട് വ്യത്യാസവും പൂൾ എണ്ണവും മാറ്റ രേഖയോടൊപ്പം സൂക്ഷിക്കുക, കാരണം അടുത്ത VPN ക്ലയന്റ് അപ്ഡേറ്റ് Docker-നെ സ്പർശിക്കാതെ ആദ്യത്തേത് മാറ്റാം.

മറ്റൊരാൾക്ക് ഈ രണ്ട് പരിശോധനകൾ ആവർത്തിച്ച് അതേ ഉത്തരം ലഭിക്കുമ്പോൾ റൺബുക്ക് പൂർണ്ണമാകുന്നു.