दोन नेटवर्क असलेला कंटेनर चुकीचा गेटवे निवडतो

तुमचा कंटेनर अजूनही त्याच्या नियंत्रण पुलावर उत्तर देतो, पण प्रत्येक बाहेर जाणारे पॅकेट ऑफिस 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 कॉन्फिगला फक्त स्वतःचे धोरण ठेवू द्या.