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. - මාර්ගය වෙනස් වූ පසුවත් ගමනාන්තයේ ඇතුළත නීති සැබෑ මූලාශ්‍රයට අවසර දෙයි.