ప్రతి దీపస్తంభం ఏదైనా హోస్ట్కు మిగిలిన ప్రతి సహచరుడి గురించి చెప్పగలదు, కానీ దీపస్తంభం స్వయంగా ఉన్న స్థలం తప్ప. overlay ఉనికిలోకి రాకముందే ఏదో తెలిసి ఉండాలి, Nebula ఆ ఏదోను ఒక చిన్న మ్యాప్లో పెడుతుంది. మ్యాప్ overlay గుర్తింపును సాధారణ నెట్వర్క్లో పనిచేసే చిరునామాతో జత చేస్తుంది. తర్వాత నేర్చుకునేదంతా ఆ జత సరిగ్గా ఉండటంపై ఆధారపడి ఉంటుంది.

రెండు పనులతో రెండు చిరునామాలు

ప్రతి Nebula హోస్ట్కు overlay చిరునామా ఉంటుంది, పరికరం నెట్వర్క్ల మధ్య కదులుతున్నప్పుడు కూడా అది స్థిరంగా ఉంటుంది. ఆ చిరునామాయే ధృవపత్రాలు, firewall నియమాలు మరియు సహచర సంబంధాలు ఉపయోగించే గుర్తింపు, ఒంటరిగా అది ఎక్కడికీ మార్గనిర్దేశం చేయదు. చేరుకోగల ముగింపు పాయింట్ మరొకటి: అంతర్లీన నెట్వర్క్లో హోస్ట్ పేరు లేదా చిరునామా మరియు ఒక UDP పోర్ట్, యంత్రం స్థలం మార్చిన ప్రతిసారీ అది మారుతుంది. స్థిర మ్యాప్ రెండింటి మధ్య కలయిక.

మ్యాప్లోకి చల్లగా డయల్ చేయాల్సిన హోస్ట్లు మాత్రమే వస్తాయి, అంటే సాధారణంగా దీపస్తంభాలు మరియు బహుశా ఒక రిలే. ఆ జాబితాను చిన్నగా ఉంచడం డిజైన్ లక్ష్యం, ఎందుకంటే ప్రతి చేతితో రాసిన నమోదు ఎవరో నిర్వహించాల్సిన వాస్తవంగా మారుతుంది. రెండు చిరునామా రకాలను కలపడం సాధారణ కాన్ఫిగరేషన్ పొరపాటు: దీపస్తంభాల జాబితాలో ఉంచిన పబ్లిక్ చిరునామా అన్వేషణను ప్రారంభించదు.

గుర్తింపు గుర్తింపు ఆశించే చోటికి వెళ్తుంది. చేరుకోగల సామర్థ్యం మ్యాప్లోకి వెళ్తుంది.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

మ్యాప్ నమోదు నిర్మాణం

కీ అనేది కోట్స్ మధ్య స్ట్రింగ్గా రాసిన overlay చిరునామా, విలువ ముగింపు పాయింట్ల జాబితా, కాబట్టి ఒక గుర్తింపుకు అనేక ప్రవేశ బిందువులు ఉండవచ్చు. ప్రతి ముగింపు పాయింట్ ఒక హోస్ట్ మరియు ఒక పోర్ట్ కలిగి ఉంటుంది, పోర్ట్ మరొక వైపు నిజంగా వినే దానితో సరిపోలాలి. Nebula డిఫాల్ట్ UDP 4242, ఇది ప్రారంభ బిందువు, మీ అమలు గురించి వాగ్దానం కాదు.

ఒక దీపస్తంభానికి లోపలికి వచ్చే ఒకటి కంటే ఎక్కువ మార్గాలు ఉన్నప్పుడు అనేక ముగింపు పాయింట్లు ఉపయోగకరం, ఉదాహరణకు పబ్లిక్ చిరునామా మరియు అదే విభాగంలోని హోస్ట్లకు ప్రైవేట్ చిరునామా. క్లయింట్ వాటిని క్రమంగా ప్రయత్నిస్తుంది, కాబట్టి అత్యంత నమ్మదగినది మొదట పెట్టండి. IPv6 కోసం పోర్ట్ జోడించే ముందు చిరునామాను చతురస్ర బ్రాకెట్లలో పెట్టండి; తప్పు చేస్తే తప్పు పంక్తిని చూపే పార్స్ లోపం వస్తుంది.

తప్పు పోర్ట్ లోపం బదులు మౌనాన్ని ఇస్తుంది, ఎందుకంటే UDP కి తిరస్కరించే హ్యాండ్షేక్ లేదు. కాబట్టి నమోదు ఆకృతిని Nebula static_host_map సూచనతో తనిఖీ చేయడం విలువైనది, జ్ఞాపకంతో కాదు. సూచన ముగింపు పాయింట్ల జాబితాలు మరియు DNS రిఫ్రెష్ ప్రవర్తనను కూడా కవర్ చేస్తుంది.

overlay కి ముందు బూట్స్ట్రాప్ పనిచేయాలి

మ్యాప్లోని DNS పేరు ఏ టన్నెల్ ఉనికిలోకి రాకముందే హోస్ట్కు ఉన్న రిజాల్వర్ ద్వారా పరిష్కరించబడాలి, అంటే సాధారణ సిస్టమ్ రిజాల్వర్. దాన్ని అదే యంత్రం నుండి, బూట్ సమయంలో, overlay ఆపి ఉంచి పరీక్షించండి. overlay యొక్క స్వంత DNS ద్వారా మాత్రమే పరిష్కరించబడే పేరు overlay ను బూట్స్ట్రాప్ చేయలేదు. అదే పరీక్ష మార్గానికి కూడా వర్తిస్తుంది: overlay ను అనుమతించి కానీ మొదటి UDP మార్పిడిని అనుమతించని firewall నియమం మొదటి ప్యాకెట్ను నిరోధిస్తుంది.

పోర్ట్ తెరిచి ఉందని ఊహించకుండా UDP సాధనంతో తనిఖీ చేయండి. మార్గంలోని ఏదైనా పోర్ట్ ఫార్వార్డింగ్ సరైన అంతర్గత హోస్ట్ను లక్ష్యంగా చేసుకుందని మరియు తిరిగి వచ్చే మార్గం ఉందని నిర్ధారించండి. హోస్ట్ పేరు అనేక చిరునామాలకు పరిష్కరించబడితే, ప్రతిదీ పరీక్షించండి, ఎందుకంటే క్లయింట్ మీరు ఎప్పుడూ తనిఖీ చేయని చిరునామాను ఎంచుకోవచ్చు.

స్థిర నమోదులు నేరుగా డయల్ చేయబడతాయి మరియు ఎప్పుడూ దీపస్తంభాన్ని అడగవు. అందుకే ఇక్కడ వైఫల్యం ఏ సహచరుడూ లేని సాధారణ టైమౌట్లా కనిపిస్తుంది.

మొదటి హ్యాండ్షేక్ తర్వాత ఏమి జరుగుతుంది

హోస్ట్ దీపస్తంభాన్ని చేరుకున్న వెంటనే ఇంకా చేతితో రాసిన నమోదులు లేకుండా సహచరులు మరియు వారి చేరుకోగల చిరునామాల గురించి తెలుసుకుంటుంది. చివరి కనెక్షన్ తర్వాత కదిలిన హోస్ట్లు ఆ ఛానెల్ ద్వారా కనుగొనగలిగేవి అవుతాయి. చేతితో రాసిన మ్యాప్ను చిన్నగా ఉంచడం యొక్క బహుమతి అదే.

హోస్ట్లు తమ అదనపు చేరుకోగల చిరునామాలను కూడా ప్రకటించవచ్చు, అలా తెలిసిన పబ్లిక్ చిరునామా వెనుక ఉన్న సహచరుడు ఇతరులకు దాన్ని కనుగొనడంలో సహాయపడతాడు. ఆ ప్రకటనలు నేర్చుకోబడతాయి, స్థిర మ్యాప్లో రాయబడవు.

DNS పేర్లుగా రాసిన ముగింపు పాయింట్లకు రిఫ్రెష్ ప్రవర్తన ముఖ్యం, ఎందుకంటే ప్రక్రియ కొనసాగుతున్నప్పుడు పరిష్కరించిన చిరునామా మారవచ్చు. Nebula సెట్టింగ్లు ఆ శోధనలు ఎలా జరుగుతాయో, ఏ రిజాల్వర్ ఉపయోగించబడుతుందో కూడా నియంత్రిస్తాయి, కాబట్టి సిస్టమ్ డిఫాల్ట్ను ఊహించకుండా వాటిని చదవండి. టన్నెల్ పైకి వచ్చినప్పుడు రిజాల్వర్ మారే హోస్ట్లో, తప్పు సెట్టింగ్ పనిచేస్తున్న బూట్స్ట్రాప్ను సెషన్ మధ్యలో పరిష్కరించడం ఆపే పేరుగా మార్చవచ్చు. శోధనను స్థిరమైన రిజాల్వర్కు పిన్ చేయడం తరచుగా నమ్మదగిన overlay మరియు అడపాదడపా ఆగిపోయే overlay మధ్య తేడా.

అన్వేషణ పనిచేస్తున్నప్పుడు ఒక సహచరుడు పనిచేయనప్పుడు

దీపస్తంభాలు చేరుకోగలిగితే మరియు చాలా సహచరులు కనెక్ట్ అయితే, బూట్స్ట్రాప్ సమస్య కాదు. మిగిలిన జంట ఒకరినొకరు చేరుకోగల మార్గాన్ని కనుగొనలేదు లేదా చేరుకోగల సామర్థ్యానికి మించి విఫలమవుతుంది. దీపస్తంభ చిరునామా యొక్క మరో స్పెల్లింగ్ జోడించడం రెండు సందర్భాలలో ఏదీ సరిచేయదు.

మిగిలినవన్నీ ఇప్పటికే ఆధారపడిన మ్యాప్ను సవరించే ముందు జంటను తనిఖీ చేయండి. మ్యాప్ మార్పు ప్రతి హోస్ట్ను కలవరపరుస్తుంది, కాబట్టి అది చివరగా తాకవలసినది, మొదటిది కాదు.

ఒకే అధికారం యొక్క ధృవపత్రాలతో ప్రారంభించండి, ఎందుకంటే తిరస్కరించబడిన హ్యాండ్షేక్ దూరం నుండి చేరుకోలేని సహచరుడిలా కనిపించవచ్చు. తర్వాత జంట నేరుగా మార్గాన్ని ఏర్పాటు చేయగలదా, నేరుగా ట్రాఫిక్ను తిరస్కరించే నెట్వర్క్ల కోసం రిలే కాన్ఫిగర్ చేయబడిందా అని తనిఖీ చేయండి. రిలే ఒక హాప్ మరియు ఒక ఆధారాన్ని జోడిస్తుంది, కానీ అది మద్దతు ఉన్న సమాధానం, జంట మార్గాన్ని సరిచేయడం అన్వేషణను సరిచేయడం నుండి భిన్నమైన పని.

సంబంధిత వ్యాసాలు