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 कोरमकडे नाही.

चालणाऱ्या विंडोचे कॅप्चर ठेवा, कारण त्याची तुटलेल्याशी तुलना कॉन्फिग पुन्हा वाचण्यापेक्षा वेगवान आहे.