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।
• मार्ग बदलल्यानंतरही गंतव्याचे इनबाउंड नियम खऱ्या स्रोताला परवानगी देतात।