VPN मा Docker Swarm: कार्यहरू चल्छन्, सेवा कलहरू असफल हुन्छन्

दुई साइटमा तीन म्यानेजर र पाँच वर्कर, एउटा टनेलले जोडिएका, र docker service ls दुवैतिर चलिरहेका कार्यहरू देखाउँछ, तर सेवाहरूबीचका कलहरू समय सकिन्छन्। Swarm लगहरूमा केही पनि गलत देखिँदैन। त्यो संयोजन डेटा प्लेन समस्याको हस्ताक्षर हो: कन्ट्रोल प्लेनले नोडहरू भेट्टायो, र इन्क्याप्सुलेट गरिएका फ्रेमहरूले कहिल्यै यात्रा पूरा गरेनन्।

overlay अघि mesh हुनैपर्छ

Swarm को overlay ले इन्क्याप्सुलेट गरिएका फ्रेमहरू सिधै नोड ठेगानाहरूबीच धकेल्छ, जसको अर्थ प्रत्येक नोडलाई यस्तो ठेगाना चाहिन्छ जहाँ अरू हरेक नोड अनुवादबिना पुग्न सकोस्, टनेलले दिने इन्टरफेसमा। केवल ग्राहकहरूलाई प्रकाशित पोर्टसम्म पुर्याउने टनेल पर्याप्त हुँदैन। तल्लो तहले दुवै दिशामा नोडदेखि नोडसम्म मार्ग बनाउनुपर्छ।

Swarm छुनुअघि यो परीक्षण गर्नुहोस्। प्रत्येक नोडबाट साथीको टनेल ठेगानासम्मको मार्ग जाँच्नुहोस्, त्यसलाई ping गर्नुहोस्, र त्यसपछि कन्ट्रोल पोर्ट परीक्षण गर्नुहोस्। ping चल्यो तर पोर्ट चलेन भने, टनेल ठीक छ र बाटोमा फिल्टर छ।

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

मार्गले tun0 वा wg0 को सट्टा भौतिक इन्टरफेसतिर देखाएमा, overlay ले दुर्गम साइट पुग्न नसक्ने ठेगानामा इन्क्याप्सुलेट गर्नेछ, र लक्षण प्याकेट हानि जस्तो देखिनेछ।

प्रत्येक नोडले कुन ठेगाना घोषणा गर्छ जाँच्नुहोस्

डेमनले एउटा ठेगाना घोषणा गर्छ, र साथीहरूले त्यसलाई डेटा प्लेनका लागि प्रयोग गर्छन्। धेरै नेटवर्क भएको होस्टमा टनेलले अरू केही बोकिरहेको बेला LAN वा सार्वजनिक ठेगाना घोषणा गर्न सजिलो हुन्छ। अनुमान गर्नुको सट्टा जाँच्नुहोस्, र पूर्वनिर्धारित गलत भएमा सामेल हुँदा --advertise-addr ले त्यसलाई पिन गर्नुहोस्। आफैँले मात्र पुग्न सक्ने ठेगाना घोषणा गर्ने नोड पनि swarm मा सामेल हुन्छ, र असफलता पछि साइटहरूबीच कुरा गर्न नसक्ने सेवाका रूपमा देखिन्छ।

घोषित ठेगाना पछि बदल्नु कन्फिग सम्पादन होइन, किनकि नोडले बाहिर निस्केर फेरि सामेल हुनुपर्छ।

प्रत्येक नोडको घोषित ठेगाना आफ्ना नोटमा लेख्नुहोस्, किनकि यसले धेरैजसो असममित असफलता व्याख्या गर्छ।

Masquerade नै सामान्य दोषी हो

नोड र टनेलबीच गेटवे बस्दा, सामान्य गल्ती भौतिक इन्टरफेसबाट निस्कने सबैमा masquerade लगाउनु हो। यसले overlay का भित्री ठेगाना पनि पुनःलेखन गर्छ, त्यसैले प्रत्येक साथी गेटवेबाट आएको देखिन्छ र VXLAN साथीहरूले एकअर्कालाई चिन्न छोड्छन्। नतिजा हराएको वा एकतर्फी इन्क्याप्सुलेट गरिएको ट्राफिक हुन्छ, जबकि साधारण ping अझै चल्छ।

overlay को प्रिफिक्स गेटवेबाट मार्ग बनाउनुहोस् र अनुवाद नगरी छोड्नुहोस्। यदि अर्को प्रिफिक्सका लागि अनुवाद साँच्चै आवश्यक छ भने, त्यहीँ सीमित गर्नुहोस् र overlay ले प्रयोग गर्ने दायरामा कहिल्यै नगर्नुहोस्।

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

नियमहरूको क्रम र पाठ दुवै जाँच्नुहोस्, किनकि शृंखलामा अगाडि रहेको फराकिलो MASQUERADE पछिको साँघुरो अपवादलाई जित्छ।

VXLAN लाई प्याकेटमा ठाउँ चाहिन्छ

VXLAN ले बोक्ने फ्रेमहरूमा 50 बाइट थप्छ। 1500 बाइटको तल्लो तहले 1500 बाइटको भित्री फ्रेम बोक्दा कुनै मार्गले नपुर्याउने इन्क्याप्सुलेट गरिएको प्याकेट बन्छ, र असफलता आकारको समस्या जस्तो नभई बीचबीचमा सेवा खोज जस्तो देखिन्छ। या त दुवै छेउमा टनेलको MTU घटाउनुहोस् या overlay को MTU यसरी सेट गर्नुहोस् कि ड्राइभरले अटाउने पेलोड घोषणा गरोस्।

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress नेटवर्क स्वतः बन्छ, त्यसैले यसलाई बदल्नु भनेको ठाउँमै सम्पादन गर्नु होइन, हटाएर फेरि बनाउनु हो।

टनेलको एउटा मात्र पक्ष सुधारेमा, सानो MTU नै महत्त्वपूर्ण रहन्छ।

लग होइन, डेटा प्लेन हेर्नुहोस्

दुवै छेउमा VXLAN पोर्ट क्याप्चर गर्नुहोस्। एउटा पक्षबाट निस्केर अर्को पक्षमा पुग्ने फ्रेमहरू भनेको तल्लो तह ठीक छ र समस्या overlay भित्र छ। निस्केर कहिल्यै नपुग्ने फ्रेमहरू भनेको मार्ग वा फिल्टर। बिल्कुलै ननिस्कने फ्रेमहरू भनेको स्रोत ठेगाना गलत छ।

केही सेकेन्डपछि मेटिने सेवा खोज असफलताहरू सामान्यतया प्याकेट बजेट वा अस्थिर मार्गतिर संकेत गर्छन्, raft क्वोरमतिर होइन।

चलिरहेको विन्डोको क्याप्चर राख्नुहोस्, किनकि यसलाई बिग्रिएकोसँग तुलना गर्नु कन्फिग फेरि पढ्नुभन्दा छिटो हुन्छ।