രണ്ട് നെറ്റ്‌വർക്കുകളുള്ള കണ്ടെയ്നർ തെറ്റായ ഗേറ്റ്‌വേ തിരഞ്ഞെടുക്കുന്നു

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

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

ഡിഫോൾട്ട് റൂട്ട് തെറ്റായ നെറ്റ്‌വർക്കിൽ എത്തുന്നത് എന്തുകൊണ്ട്

ഒരു സേവനം ചേരുന്ന ഓരോ നെറ്റ്‌വർക്കും സ്വന്തം ഗേറ്റ്‌വേ വാഗ്ദാനം ചെയ്യാം, എന്നാൽ കണ്ടെയ്നറിന് അവസാനം കൃത്യം ഒരു ഡിഫോൾട്ട് റൂട്ട് മാത്രമായിരിക്കും. Compose 2.33.1-ന് മുൻപ് നെറ്റ്‌വർക്ക് നാമങ്ങൾ അടുക്കി സമനില തീർപ്പാക്കിയിരുന്നു, അതിനാൽ office-ന് മുൻപ് വരുന്ന control പോലുള്ള ഒരു ലേബലാണ് ട്രാഫിക് എവിടെ പോകുമെന്ന് തീരുമാനിച്ചിരുന്നത്. കണ്ടെയ്നറിനുള്ളിൽ തീരുമാനം ഏകപക്ഷീയമായിരുന്നു എന്ന് ഒന്നും രേഖപ്പെടുത്തുന്നില്ല, അതുകൊണ്ടാണ് അത് കോഡ് അവലോകനം കടന്ന് പിന്നീട് ഒരു വിചിത്രമായ പാതയായി പുറത്തുവരുന്നത്. compose ഫയലിൽ ഒരു നയം ഇടുന്നതാണ് തിരഞ്ഞെടുപ്പ് പരിശോധിക്കാവുന്നതാക്കാനുള്ള ഏക വഴി.

ഏത് നെറ്റ്‌വർക്ക് വിജയിക്കുമെന്ന് യഥാർത്ഥത്തിൽ മാറ്റുന്നത് രണ്ട് കാര്യങ്ങളാണ്: നിങ്ങൾ നൽകുന്ന gw_priority മൂല്യങ്ങളും, ഏത് നെറ്റ്‌വർക്കുകളാണ് ബന്ധിപ്പിച്ചിരിക്കുന്നത് എന്നതും. മൂന്നാമതൊരു നെറ്റ്‌വർക്ക് ചേർത്താൽ സ്ഥാനാർത്ഥികളുടെ കൂട്ടം വളരും; macvlan ഒഴിവാക്കിയാൽ ബ്രിഡ്ജിനോട് മത്സരിക്കാൻ ഒന്നും ബാക്കിയില്ല. രണ്ട് നീക്കങ്ങളും ആപ്ലിക്കേഷൻ ലോഗുകളിൽ കാണുന്നില്ല, കാരണം തെറ്റായ ഡിഫോൾട്ട് റൂട്ട് ബന്ധം പൂർണ്ണമായി മുറിക്കുന്നത് അപൂർവമാണ്. അത് മറുപടികൾ എതിർവശം പ്രതീക്ഷിക്കാത്ത ഒരു വിലാസത്തിൽ നിന്ന് വരാൻ മാത്രം ഇടയാക്കുന്നു.

gw_priority ഉപയോഗിച്ച് ഗേറ്റ്‌വേ പിൻ ചെയ്യുക

Compose 2.33.1 പതിപ്പ് മുതൽ ഓരോ സേവന-നെറ്റ്‌വർക്ക് അറ്റാച്ചുമെന്റിലും gw_priority നൽകുന്നു, ഏറ്റവും വലിയ സംഖ്യ വിജയിക്കുന്നു. ഓരോ സേവനത്തിനും പ്രത്യേക ഗേറ്റ്‌വേ കീ ഇല്ല, അതിനാൽ മൂല്യം സേവനത്തിന്റെ networks ബ്ലോക്കിൽ വരുന്നു. താഴെയുള്ള ഉദാഹരണം ഡിഫോൾട്ട് control-ന് നൽകുന്നു, office അതിന്റെ നേരിട്ട് ബന്ധിപ്പിച്ച LAN-ന് എത്താവുന്നതായി തുടരുന്നു.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

ബ്ലോക്കിനെ രണ്ട് വേർതിരിച്ച നിയന്ത്രണങ്ങളായി വായിക്കുക: gw_priority ഡിഫോൾട്ട് റൂട്ട് തീരുമാനിക്കുന്നു, ipam ഭാഗം വിലാസനിർണ്ണയം തീരുമാനിക്കുന്നു. subnet മാത്രം മാറ്റിയാൽ എക്സിറ്റ് തിരഞ്ഞെടുപ്പ് അസ്പൃശ്യമായി തുടരും, ഈ തിരുത്ത് പകുതി മാത്രം പ്രയോഗിക്കപ്പെടുന്ന സാധാരണ മാർഗം അതാണ്. മുൻഗണനകൾ അവ നിയന്ത്രിക്കുന്ന നെറ്റ്‌വർക്കിന് അടുത്തുതന്നെ സൂക്ഷിക്കുക, അടുത്ത വായനക്കാരൻ തീരുമാനം തിരയേണ്ടിവരരുത്.

gw_priority-യെ അടുത്തുള്ള സാധാരണ priority ഗുണവുമായി കൂട്ടിക്കുഴയ്ക്കരുത്. അത് കണക്ഷനുകളുടെ സൃഷ്ടി ക്രമീകരിക്കുന്നു, റൂട്ടിംഗിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ ഡിഫോൾട്ട് ഗേറ്റ്‌വേ തിരഞ്ഞെടുക്കാനാവില്ല, ഇന്റർഫേസ് നാമങ്ങളും ശരിയാക്കുന്നില്ല. ട്രാഫിക് തിരിച്ചുവിടാൻ priority ഉയർത്താൻ ആരെങ്കിലും ശുപാർശ ചെയ്താൽ, ഫലമായ ക്രമം യാദൃച്ഛികമായി ശരിയായി തോന്നിയാലും ശുപാർശ തെറ്റാണ്.

ഏത് നെറ്റ്‌വർക്കാണ് യഥാർത്ഥത്തിൽ ഡിഫോൾട്ട് റൂട്ട് വഹിക്കുന്നതെന്ന് പരിശോധിക്കുക

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

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

ശരിയായ ഫലം ബ്രിഡ്ജ് ഉപകരണവും 172.30.50.1-ഉം പേരിടുന്നു; തെറ്റായത് 192.168.120.1-ഉം macvlan ഉപകരണവും പേരിടുന്നു. ഇമേജിൽ iproute2 പാക്കേജ് ഇല്ലെങ്കിലും /proc ഫയൽ ഡിഫോൾട്ട് റൂട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു, ലക്ഷ്യം 00000000, ഗേറ്റ്‌വേ ബൈറ്റുകൾ തലതിരിഞ്ഞ്. ഉപകരണ നാമങ്ങൾ വ്യക്തമല്ലാത്തപ്പോൾ ഇന്റർഫേസ് നിര docker inspect-മായി താരതമ്യം ചെയ്യുക.

macvlan ഒരു ഭൗതിക പോർട്ടാണ്, ബ്രിഡ്ജിന്റെ പകർപ്പല്ല

macvlan കണ്ടെയ്നറിന് കേബിളിൽ രണ്ടാമത്തെ ഐഡന്റിറ്റി നൽകുന്നു, അതാണ് പ്രാദേശിക ഉപകരണങ്ങളിലേക്കുള്ള പ്രവേശനം പ്രവർത്തിപ്പിക്കുന്നത്. സ്വിച്ച് പോർട്ടും ഹൈപ്പർവൈസറും ഒരു അധിക MAC വിലാസം സ്വീകരിക്കണം എന്നും ഇത് അർത്ഥമാക്കുന്നു, പല ക്ലൗഡ് നെറ്റ്‌വർക്കുകളും അത് നിശ്ശബ്ദമായി നിരസിക്കുന്നു. ഒരു ഫ്ലീറ്റ് ആസൂത്രണം ചെയ്യുന്നതിന് മുൻപ് ഒരു കണ്ടെയ്നർ പരീക്ഷിക്കുക, കാരണം നിരസിക്കപ്പെട്ട MAC സാധാരണയായി മുകളിലുള്ളതും ഒന്നും കടത്തിവിടാത്തതുമായ ഒരു ലിങ്കായി കാണപ്പെടുന്നു.

macvlan_mode: bridge ക്രമീകരണം macvlan ഡ്രൈവറിന്റെ ഒരു മോഡാണ്, Docker-ന്റെ സോഫ്റ്റ്‌വെയർ ബ്രിഡ്ജല്ല, passthru ഡിഫോൾട്ടല്ല, വേറിട്ട ഒരു പ്രത്യേക മോഡാണ്. Linux macvlan കണ്ടെയ്നറിനെ സ്വന്തം ഹോസ്റ്റിൽ എത്തുന്നതിൽ നിന്നും തടയുന്നു അതേ പാരന്റ് വഴി, അതുകൊണ്ടാണ് ഒരു അറ്റാച്ചുമെന്റ് രണ്ട് ജോലിയും ചെയ്യുമെന്ന് പ്രതീക്ഷിക്കാതെ കൺട്രോൾ ബ്രിഡ്ജ് നിലനിർത്തുന്നത്.

Compose കാണുന്നതിന് മുൻപ് VLAN പാരന്റിന് പേരിടുക

Docker eno1.120 പോലുള്ള പുള്ളിയുള്ള പാരന്റിനെ 802.1Q സബ്-ഇന്റർഫേസായി കണക്കാക്കി VLAN ഉപകരണം സ്വയം സൃഷ്ടിക്കുന്നു. ആ സൗകര്യത്തിന് പരിധികളുണ്ട്: ഉരുത്തിരിഞ്ഞ നാമം ഭൗതിക ഇന്റർഫേസിന്റെ നാമത്തെ ആശ്രയിച്ചിരിക്കുന്നു, നീളമുള്ള നാമങ്ങൾ ഫലത്തെ ചുറ്റുമുള്ള ഉപകരണങ്ങൾ പ്രതീക്ഷിക്കുന്നതിനപ്പുറത്തേക്ക് തള്ളിയേക്കാം. ഹോസ്റ്റിന്റെ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷനിൽ പേരുള്ള VLAN ഇന്റർഫേസ് സൃഷ്ടിച്ച് parent അതിലേക്ക് ചൂണ്ടിച്ചാൽ രണ്ട് അറ്റങ്ങളും പ്രവചനീയമായി നിൽക്കും.

networks-ന് കീഴിലുള്ള കീ Compose നാമമാണ്, Linux ഉപകരണമല്ല എന്ന് ഓർക്കുക. ഹോസ്റ്റിൽ office എന്ന പേരുള്ള ഇന്റർഫേസ് തിരയുന്നത് പരാജയപ്പെടും, കാരണം കേർണൽ പാരന്റ് ഇന്റർഫേസും കണ്ടെയ്നറിന് പിന്നിലെ veth ജോഡിയും മാത്രമാണ് കാണുന്നത്.

മുകളിൽ VPN-ന് ഇടം ഉണ്ടാക്കുക

VPN ക്ലയന്റ് ഈ നെറ്റ്‌വർക്കുകൾ നിലവിലുള്ളതിന് ശേഷമാണ് ബന്ധിപ്പിക്കുന്നത്, അതിനാൽ gw_priority പരിഗണിക്കാതെ കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടുകളും നയ നിയമങ്ങളും ഫിൽട്ടറുകളും ചേർക്കാനാകും. രണ്ട് പ്രാദേശിക subnet-കൾക്കെതിരെ ദൂര പ്രിഫിക്സുകൾ ആസൂത്രണം ചെയ്യുക, നിയന്ത്രണ പാതയ്ക്ക് ആവശ്യമായ മറുപടികൾ ഉൾപ്പെടെ. ദൂര പ്രിഫിക്സ് ഓഫീസ് LAN-മായി ഓവർലാപ്പ് ചെയ്യുമ്പോൾ, മുഴുവൻ സ്വകാര്യ ശ്രേണിയും ടണലിൽ നിന്ന് പറിച്ചെടുക്കുന്നതിന് പകരം വിലാസ പദ്ധതി ശരിയാക്കുക.

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