दुई नेटवर्क भएको कन्टेनरले गलत गेटवे छान्छ

तपाईंको कन्टेनर अझै आफ्नो नियन्त्रण पुलमा जवाफ दिन्छ, तर हरेक बाहिर जाने प्याकेट अफिस 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 कन्फिगलाई आफ्नै नीति मात्र राख्न दिनुहोस्।