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.
• మార్గం మారిన తర్వాత కూడా గమ్యస్థానం యొక్క ఇన్‌బౌండ్ నియమాలు నిజమైన మూలాన్ని అనుమతిస్తాయి.