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.
• பாதை மாறிய பிறகும் இலக்கின் உள்வரும் விதிகள் உண்மையான மூலத்தை அனுமதிக்கின்றன.