VPN पर Docker Swarm: कार्य चलते हैं, सेवा कॉल विफल होते हैं

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

mesh को overlay से पहले मौजूद होना चाहिए

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 क्वोरम की ओर नहीं।

काम करने वाली विंडो का कैप्चर रखें, क्योंकि उसकी टूटी हुई से तुलना कॉन्फ़िग फिर पढ़ने से तेज़ है।