இரண்டு நெட்வொர்க்குகள் உள்ள கொள்கலன் தவறான கேட்வேயைத் தேர்ந்தெடுக்கிறது

உங்கள் கொள்கலன் இன்னும் அதன் கட்டுப்பாட்டுப் பாலத்தில் பதிலளிக்கிறது, ஆனால் ஒவ்வொரு வெளிச்செல்லும் பாக்கெட்டும் அலுவலக macvlan வழியாக வெளியேறுகிறது. எதுவும் தோல்வியடையவில்லை. இரண்டு இணைப்புகள் ஒவ்வொன்றும் தனித்தனி கேட்வே தருகின்றன, ஒரே இயல்புநிலை வழி நீங்கள் கருதாத நெட்வொர்க்கிற்குச் சென்றது, எனவே சேவை தொடர்ந்து இயங்குகிறது ஆனால் அதன் போக்குவரத்து நீண்ட பாதையை எடுக்கிறது. யாராவது கவனிக்கும்போது ஆதாரம் பிழைச் செய்தி அல்ல, ரூட்டிங் அட்டவணை.

வழக்கமான விளக்கம் Docker நெட்வொர்க்கை தற்செயலாகத் தேர்ந்தெடுத்தது என்பதே. நடைமுறையில் பழைய முடிவு இணைக்கப்பட்ட நெட்வொர்க் பெயர்களின் அகரவரிசையைப் பின்பற்றியது, இது ரூட்டிங்கை ஒரு லேபிளின் பக்க விளைவாக மாற்றியது. gw_priority அதை நீங்கள் வேண்டுமென்றே தேர்ந்தெடுக்கும் எண்ணால் மாற்றுகிறது, மற்றும் அமைப்பு எழுதப்பட்ட பிறகு அதை ஏற்றுக்கொள்ள ஒரு நிமிடம் ஆகும்.

இயல்புநிலை வழி தவறான நெட்வொர்க்கில் விழுவதன் காரணம்

ஒரு சேவை சேரும் ஒவ்வொரு நெட்வொர்க்கும் தனது சொந்த கேட்வேயை வழங்கலாம், ஆனால் கொள்கலனுக்கு சரியாக ஒரு இயல்புநிலை வழி மட்டுமே இருக்கும். Compose 2.33.1 க்கு முன் சமநிலை நெட்வொர்க் பெயர்களை வரிசைப்படுத்தி தீர்க்கப்பட்டது, எனவே control போன்ற லேபிள் office க்கு முன் வந்தால் போக்குவரத்து எங்கு செல்லும் என்பதை அதுவே தீர்மானித்தது. கொள்கலனின் உள்ளே முடிவு தன்னிச்சையானது என்று எதுவும் பதிவு செய்யாது, அதனால்தான் அது குறியீடு மதிப்பாய்வைக் கடந்து பின்னர் விநோதமான பாதையாக வெளிப்படுகிறது. 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 கட்டமைப்பு அதன் சொந்தக் கொள்கையை மட்டும் வைத்திருக்கட்டும்.