Nebula रिले कॉन्फ़िगर है पर इस्तेमाल में नहीं: जाँचने के लिए तीन सेटिंग्स

आपने एक रिले होस्ट जोड़ा, उसका Nebula पता कॉन्फ़िग में डाला, और दोनों पीयर फिर भी आपस में बात नहीं कर रहे। ऐसा इसलिए होता है क्योंकि रिले पथ के लिए तीन अलग कथनों का मेल होना ज़रूरी है, और उनमें से सिर्फ़ एक उस मशीन पर है जिसे आपने शायद संपादित किया। मैंने इसका पीछा दो बार किया है: एक बार जहाँ फ़ॉरवर्डिंग होस्ट को कभी रिले भूमिका नहीं दी गई थी, और एक बार जहाँ सेटिंग्स कनेक्शन के गलत तरफ़ लिखी गई थीं। नीचे दिया क्रम भूमिका, घोषणा और अनुमति को इसी क्रम में जाँचता है, और हर चरण के पास एक कमांड है जो बताती है कि आगे बढ़ना है या नहीं।

कॉन्फ़िग संपादित करने से पहले तीनों भूमिकाओं का नक्शा बनाएँ

Nebula हर होस्ट को एक काम देता है, और काम विरासत में नहीं मिलते। लाइटहाउस 'यह पीयर कहाँ है' सवालों का जवाब देता है ताकि होस्ट एक-दूसरे को ढूँढ सकें। रिले उन दो पीयर के बीच ट्रैफ़िक फ़ॉरवर्ड करता है जिनके पास काम करने वाला सीधा रास्ता नहीं है। एक साधारण होस्ट दोनों में से कुछ नहीं करता। मायने रखने वाली तीन सेटिंग्स तीन अलग मशीनों पर रहती हैं, इसलिए पूरी दिखने वाली क्लाइंट कॉन्फ़िग दोनों पीयर को इंतज़ार में छोड़ सकती है।

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

एक लक्षण दो निष्फलता वर्गों को अलग करता है। अगर दोनों पीयर एक-दूसरे को सूचीबद्ध करते हैं और लॉग ऐसे हैंडशेक प्रयास दिखाता है जो कभी पूरे नहीं होते, तो खोज काम कर रही है और डेटा पथ NAT या फ़ायरवॉल से अवरुद्ध है। अगर कोई पीयर दूसरे का पता ही कभी नहीं सीखता, तो समस्या लाइटहाउस या उसके स्थैतिक होस्ट मैप में है, और रिले सेटिंग्स उसे ठीक नहीं कर सकतीं।

कुछ और संपादित करने से पहले पुष्टि करें कि हर होस्ट ने असल में कौन-सा कॉन्फ़िग लोड किया। जो यूनिट आपकी संपादित फ़ाइल से अलग पथ पढ़ती है, वह 'बदलाव ने कुछ नहीं किया' का आम और शर्मनाक कारण है:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

मिश्रित फ़्लीट में वर्ज़न लाइन मायने रखती है। रिले हैंडलिंग, पंचिंग व्यवहार और स्वीकार्य कॉन्फ़िग कुंजियाँ रिलीज़ के बीच एक जैसी नहीं हैं, इसलिए यह न मानें कि पुराना बिल्ड ऐसा अनुभाग समझता है जिसके लिए वह लिखा ही नहीं गया। होस्ट को एक ही माइनर श्रृंखला पर लाएँ, फिर हर होस्ट पर nebula -test -config /etc/nebula/config.yml चलाएँ और ऐसे ट्रांसपोर्ट को डीबग करने से पहले आउटपुट की तुलना करें जिसे कोड लागू नहीं करता।

रिले होस्ट पर फ़ॉरवर्डिंग भूमिका सक्षम करें

रिले भूमिका फ़ॉरवर्डिंग होस्ट पर एक फ़्लैग है, और यह लाइटहाउस होने से अलग है। जिस होस्ट में खोज सक्षम और रिले फ़ॉरवर्डिंग अक्षम है, वह अब भी सिर्फ़ एक खोज सेवा है। रिले पर:

relay:
  am_relay: true

यह फ़्लैग मंशा घोषित करता है; यह पहुँच नहीं बनाता। रिले दोनों पीयर से पहुँच योग्य होना चाहिए, जिसका व्यवहार में अर्थ है सार्वजनिक पता, होस्ट फ़ायरवॉल में और किसी भी क्लाउड सुरक्षा समूह में Nebula पोर्ट पर खुला इनबाउंड UDP, और उसके सामने दोहरा NAT न होना। सुनने वाला सॉकेट जाँचें, फिर पीयर के पैकेट आने को देखें:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

दो सीमाएँ बाद में समय बचाती हैं। किसी रिले तक दूसरे रिले के ज़रिए नहीं पहुँचा जा सकता, इसलिए कॉन्फ़िग में रिले नामों की श्रृंखला फ़ॉरवर्डिंग होस्ट को उपयोगी पथ देने का विकल्प नहीं है। और रिले पैकेट फ़ॉरवर्ड करता है; यह अनुमति नहीं देता, इसलिए रिले किया गया प्रवाह मंज़ूर है या नहीं, यह गंतव्य के अपने इनबाउंड नियम ही तय करते हैं। भूमिका और उसकी आवश्यकताएँ रिले कॉन्फ़िगरेशन दस्तावेज़ में दी गई हैं।

रिले की घोषणा गंतव्य से करें, क्लाइंट से नहीं

यही वह उलटाव है जो सबसे ज़्यादा घंटे खाता है। रिले सूची उस होस्ट पर होनी चाहिए जहाँ आप पहुँचना चाहते हैं, क्योंकि यह दूसरे पीयर को बताती है कि उस होस्ट तक पहुँचने के लिए कौन-से रिले इस्तेमाल किए जा सकते हैं। इसे उस क्लाइंट पर रखना जो कनेक्शन शुरू करता है, उस दिशा के लिए कुछ नहीं करता जिसकी क्लाइंट को ज़रूरत है:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

उसी चरण में गंतव्य को बूटस्ट्रैप पथ दें। स्थैतिक होस्ट मैप Nebula पते को सार्वजनिक एंडपॉइंट से जोड़ता है ताकि पहले हैंडशेक के पास जाने की जगह हो, और अगर गंतव्य उन होस्ट से रिले किया गया ट्रैफ़िक स्वीकार करेगा जहाँ वह सीधे नहीं पहुँच सकता, तो उसे रिले के लिए एक प्रविष्टि चाहिए:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

जुड़ने वाले पीयर को रिले इस्तेमाल करने दें

शुरू करने वाले पक्ष को अपनी अनुमति चाहिए। relay.use_relays डिफ़ॉल्ट रूप से चालू है, इसलिए खोजने लायक मामला स्पष्ट false है, जो अक्सर रिले सुविधा के अस्तित्व से पहले लिखे गए टेम्पलेट से कॉपी किया गया होता है या सीधे पथ थोपने के पुराने प्रयास से बचा रह जाता है:

relay:
  use_relays: true

इस तरफ़ की अनुमति अकेला द्वार नहीं है। गंतव्य के इनबाउंड नियम रिले किए गए पैकेट पर अब भी लागू होते हैं, और जिस स्रोत से वे मेल खाते हैं वह टनल के अंदर की पहचान है, रिले का अपना पता नहीं। जब रिले किया गया हैंडशेक पूरा हो जाए और ऐप्लिकेशन फिर भी विफल हो, तो नियम फिर से लिखने से पहले गंतव्य के लॉग में दर्ज स्रोत पढ़ें।

NAT ट्रैवर्सल सेटिंग्स इन सबसे परस्पर क्रिया करती हैं। punchy.punch दो पीयर को सीधा पथ खोलने में मदद करता है, और जब वह सफल होता है तो देखने लायक कोई रिले ट्रैफ़िक नहीं होता; यह सफलता है, गुम रिले नहीं। जो जोड़ी रुक-रुक कर काम करती है उसका अर्थ आमतौर पर यह होता है कि पंचिंग कभी-कभी सफल होती है, इसलिए एक प्रयास से निष्कर्ष निकालने के बजाय उस जोड़ी को कई बार जाँचें।

जो जोड़ी विफल हुई उसी के साथ सत्यापित करें, फिर रीलोड करें

असल में विफल हुए दो होस्ट को, उनके ज़रूरी ऐप्लिकेशन के साथ जाँचें। आपके वर्कस्टेशन से रिले की अपनी सेवा तक सफल ping दो अन्य पीयर के बीच फ़ॉरवर्डिंग के बारे में कुछ साबित नहीं करता, और यह इस पूरी प्रक्रिया में सबसे आम झूठा सकारात्मक है।

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

रीस्टार्ट के बजाय रीलोड करें और पुष्टि करें कि चल रही प्रक्रिया ने आपकी संपादित फ़ाइल उठाई है। रीस्टार्ट हर टनल तोड़ देता है और अगली जाँच पढ़ना कठिन बनाता है, जबकि SIGHUP प्रक्रिया रखता है और उसे कॉन्फ़िग दोबारा पढ़वाता है:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload तभी काम करता है जब स्थानीय यूनिट ExecReload परिभाषित करे, और प्रोजेक्ट के साथ आने वाली यूनिट ऐसा नहीं करती, इसलिए स्टॉक इंस्टॉल पर सफल होने वाला चरण systemctl kill -s HUP है। रीलोड के बाद प्रक्रिया द्वारा खोले गए कॉन्फ़िग पथ के लिए जर्नल पढ़ें, ताकि आप जानें कि नई फ़ाइल पढ़ी गई, आपकी मानी हुई फ़ाइल नहीं।

रिले सेटिंग्स और NAT पंचिंग दोनों पथ पर काम करती हैं; इनमें से कोई पहचान पर काम नहीं करती। अगर चल रहे कॉन्फ़िग में am_relay, relays और use_relays की पुष्टि के बाद भी जोड़ी का हैंडशेक विफल हो, तो जाँचें कि दोनों होस्ट उन नामों के लिए जारी प्रमाणपत्र प्रस्तुत करते हैं जिनके साथ वे कॉन्फ़िगर हैं और दोनों तरफ़ CA एक ही है। प्रमाणपत्र और फ़ायरवॉल कॉन्फ़िग स्थिर रखें जबकि आप एक बार में एक ट्रांसपोर्ट सेटिंग बदलें, क्योंकि एक ही जाँच में पड़ने वाला प्रमाणपत्र संपादन और रिले संपादन आपको नहीं बताते कि किसने हैंडशेक हिलाया। नाम या CA का बेमेल उसी जगह विफल होता है जहाँ कभी न मिला रिले विफल होता है, इसलिए यह प्रति-जाँच उसी चरण में आती है।

फिर पुष्टि करें कि हर कथन उसी फ़ाइल में बैठा है जिसका वह है:

• फ़ॉरवर्डिंग होस्ट पर am_relay: true, और वह होस्ट दोनों तरफ़ से UDP पर पहुँच योग्य।
• गंतव्य पर उस होस्ट का Nebula पता बताता relays:।
• कनेक्शन शुरू करने वाले पीयर पर use_relays: true।
• पथ बदलने के बाद भी गंतव्य के इनबाउंड नियम असली स्रोत को अनुमति देते हैं।