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।
• मार्ग बदलिएपछि पनि गन्तव्यका इनबाउन्ड नियमहरूले वास्तविक स्रोतलाई अनुमति दिन्छन्।