VPN వెనుక IoT సెన్సార్లు పెట్టే ముందు మూడు చిరునామా నిర్ణయాలు
మూడు చిరునామాలు మూడు పనులు చేస్తాయి: పబ్లిక్ హబ్, ధృవీకరించిన సైట్ సహచరుడు మరియు సెన్సార్ యొక్క ప్రైవేట్ చిరునామా. ఏదైనా పబ్లిక్గా కేటాయించే ముందు ప్రతిదీ ప్రణాళిక చేయండి.
ప్రతి IoT-VPN ప్రణాళికలో మూడు చిరునామాలు చిక్కుకుపోతాయి, అవి ఒకే రకమైన నిర్ణయం కాదు. ఒకటి దూర ఆపరేటర్ టన్నెల్ ముగింపు బిందువును ఎలా కనుగొంటాడో, మరొకటి సైట్ తానే సైట్ అని ఎలా నిరూపిస్తుందో, మూడవది సెన్సార్ సేవ వాస్తవానికి ఎక్కడ వినిపిస్తుందో. అదే క్రమంలో సమాధానం ఇవ్వండి, రూపకల్పన దాదాపు తనంతట తానే వస్తుంది. ఒకే ప్రశ్నగా సమాధానం ఇస్తే, ఎప్పుడూ అవసరం లేని పరికరాలకు పబ్లిక్ చిరునామాలు కేటాయించే స్థితికి వస్తారు. బయటకు వెళ్లే సైట్ టన్నెల్ వెనుక ఉన్న సెన్సార్, సెన్సార్ వైపు చూపే ఏ లోపలికి వచ్చే నియమం లేకుండా అధికారం ఉన్న ఆపరేటర్కు చేరుకోగలదు.
ఎవరు ప్రారంభిస్తారో దానితో ప్రారంభించండి
ఎవరు కాల్ చేస్తారో దాదాపు మిగతా అన్నింటినీ నిర్ణయిస్తుంది. సైట్ హబ్కు కాల్ చేసినప్పుడు, సైట్కు లోపలికి వచ్చే చేరుకోగల సామర్థ్యం అవసరం లేదు, హబ్కు సైట్ పరిష్కరించగల పేరు లేదా చిరునామా అవసరం. ఆ ఒక్క ఎంపిక స్థిర పబ్లిక్ చిరునామా చర్చలో ఎక్కువ భాగాన్ని అది ప్రారంభం కాకముందే తొలగిస్తుంది.
తర్వాత మూడు పాత్రలు స్పష్టంగా విడిపోతాయి, క్రింది పట్టిక నిర్ణయం యొక్క చిన్న రూపం.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
ప్రతి వరుసకు వేరే యజమాని ఉంటారు, అదే నిజమైన విషయం. హబ్ VPN సేవను నడిపేవారిది, సైట్ సహచరుడు నెట్వర్క్ బృందానిది, సెన్సార్ చిరునామా పరికరాన్ని కలిగి ఉన్నవారిది.
హబ్ చిరునామా ప్రారంభం, గమ్యం కాదు
నిర్వహించే పబ్లిక్ చిరునామాకు పరిష్కరించే పేరు హబ్కు సరిపోతుంది. టన్నెల్ ముగింపు బిందువు కదిలినప్పుడు DNS రికార్డు దానిని అనుసరించగలదు, ప్రతి సైట్ కాన్ఫిగరేషన్ను చేతితో మార్చకుండా. DNS చేయనిది చేరుకోగల సామర్థ్యాన్ని సృష్టించడం లేదా పాత సమాధానాన్ని కాష్ చేసుకున్న క్లయింట్ను రిఫ్రెష్ చేయడం, అవి వేరే సమస్యలు వేరే పరిష్కారాలతో.
హబ్ లేకుండా సైట్-నుండి-సైట్ టన్నెల్స్ నడిపిస్తే, అదే తర్కం మరో రూపంలో వర్తిస్తుంది: ఒక వైపు చేరుకోగల ముగింపు బిందువు కావాలి, లేదా రెండు వైపులా మూడవ పక్షాన్ని కాల్ చేస్తాయి. ఎవరైనా ఆ చిరునామా మరియు దాని పునరుద్ధరణలను ఇంకా కలిగి ఉండాలి.
సైట్ సహచరుడు అనేది ఉపసర్గ జోడించిన గుర్తింపు
సహచరుడు మొదట గుర్తింపు, తర్వాత ఉపసర్గ. WireGuard పదాలలో సహచరుడు కీ జతను ఉంచుకుంటాడు, హబ్ యొక్క AllowedIPs నమోదు ఆ కీని సైట్ ఉపసర్గకు కలుపుతుంది. IKEv2 పదాలలో ధృవపత్రం లేదా ముందుగా పంచుకున్న కీ సైట్ను గుర్తిస్తుంది, దాని ట్రాఫిక్ ఎంపికకారులు ఏమి తీసుకెళ్లగలదో చెబుతాయి. ఒక సగం మాత్రమే మార్చితే ఏర్పాటు విరిగిపోతుంది, అందుకే చిరునామా మార్పును ఎప్పుడూ గుర్తింపు మార్పుగా పరిగణించకూడదు.
కీ లేదా ధృవపత్రం యాజమాన్యాన్ని హబ్ ఆపరేటర్ వద్ద కాకుండా సైట్ వద్ద ఉంచండి, సరఫరాదారు మార్పు గుర్తింపు మార్పు కాకుండా.
ఉపసర్గ అనేది ప్రజలు ప్రణాళిక చేయడం మరచిపోయే భాగం. హబ్ సెన్సార్ ఉపజాలాన్ని సరైన సహచరుడితో అనుసంధానించాలి, ఆపరేటర్ క్లయింట్కు అక్కడికి మార్గం కావాలి; క్లయింట్లో మాత్రమే ఉన్న మార్గం ట్రాఫిక్ను నిశ్శబ్దంగా పడేసే టన్నెల్కు పంపుతుంది. కీ వేలిముద్ర పక్కన సైట్ రికార్డులో ఉపసర్గను రాయండి, భర్తీ చేసిన గేట్వే గమనించకుండా వేరే కవరేజీతో రాకుండా.
సెన్సార్ చిరునామా అప్లికేషన్కు చెందుతుంది
సైట్ ప్రణాళిక నుండి ప్రైవేట్ చిరునామా సరిపోతుంది, దానికి పబ్లిక్ చేరుకోగల సామర్థ్యం కాదు స్థిరత్వం కావాలి: DHCP రిజర్వేషన్, స్థిర కేటాయింపు, లేదా సైట్ సొంత జోన్లో పేరు. పరికరాన్ని తిరిగి నంబర్ చేయలేకపోతే, సైట్ గేట్వేపై అనువాదం చెల్లుబాటు అయ్యే సమాధానం, అనువాదం నమోదు చేయబడి తిరిగి వచ్చే ట్రాఫిక్ దానిని అనుసరిస్తే.
నిలబెట్టుకోదగిన మరో అలవాటు: సెన్సార్ హోస్ట్లోని తదుపరి-హాప్ ఫీల్డ్లో పబ్లిక్ హబ్ చిరునామాను ఎప్పుడూ అతికించవద్దు. VPN తన సొంత మార్గాన్ని ఇన్స్టాల్ చేస్తుంది, పబ్లిక్ ముగింపు బిందువుకు సాధారణ ఈథర్నెట్ పొరుగుతనం నమ్మదగినట్టు కనిపించే కాన్ఫిగరేషన్ను ఉత్పత్తి చేసే కల్పన.
సమాధానాలే దాటవేయబడే సగం. పరికరం తన సమాధానాన్ని టన్నెల్ వైపు తిరిగి పంపాలి, ఒకటి ఆపరేటర్ క్లయింట్కు మార్గం ద్వారా లేదా అభ్యర్థనను అనువదించిన అదే గేట్వే ద్వారా. తప్పు డిఫాల్ట్ గేట్వే ఉన్న సెన్సార్ అభ్యర్థనను అంగీకరించి శూన్యంలోకి సమాధానం ఇస్తుంది, ఫార్వార్డింగ్ నోట్స్ రాక మరియు సమాధాన రూటింగ్ ఒకటి కాదు రెండు అవసరాలు ఎందుకు అని వివరిస్తాయి.
నిర్ణయించండి, తర్వాత పరిమితిని రాయండి
ఎవరైనా కనెక్ట్ అయ్యే ముందు ప్రవేశ పరిమితిని రాయండి. గేట్వేను IoT విభాగానికి మరియు ఆపరేటర్కు అవసరమైన నిర్దిష్ట సేవలకు పరిమితం చేయండి, ఎందుకంటే పని చేసే మార్గం ప్రమాదవశాత్తు సాధారణ ప్రవేశంగా మారుతుంది. చదవడం-మాత్రమే పర్యవేక్షణ మరియు కాన్ఫిగరేషన్ అధికారాన్ని వేర్వేరు గుర్తింపులతో వేర్వేరు పాత్రలుగా ఉంచండి, ఒప్పందం ముగిసినప్పుడు ప్రవేశాన్ని తొలగించే వ్యక్తిని పేర్కొనండి.
ఆమోదం నెట్వర్క్ యజమానికి చెందుతుంది, DMZలో ఉండటం ప్రవేశ విధానం కాదు.
అమలు తర్వాత పరీక్ష బోరింగ్ మరియు నిర్ణాయకం: అనుమతించిన ఉపసర్గ లోపల ఒక అభ్యర్థన విజయవంతమవుతుంది, గేట్వేపై కౌంటర్ పెరుగుతుంది, ఉపసర్గ వెలుపల ఒక ఉద్దేశపూర్వక ప్రయత్నం విఫలమవుతుంది.