ప్రైవేట్ DNS పేరా లేక కేవలం IP యా? పంచుకునే ముందు నిర్ణయించుకోండి

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

మొదటి షరతు: క్లయింట్లకు ఏ resolver మార్గం ఉంది?

ప్రైవేట్ పేరు క్లయింట్ resolver దానికి సమాధానం ఇవ్వగలిగినప్పుడే పనిచేస్తుంది. అంటే అధికారం ఇచ్చిన దూరపు క్లయింట్ జోన్ కలిగి ఉన్న DNS సర్వర్ను చేరుకోవాలి, టన్నెల్ ద్వారా లేదా సంస్థ ఇప్పటికే దూరపు వినియోగదారుల కోసం నడుపుతున్న resolver ద్వారా. టన్నెల్ ఒక రవాణా, డైరెక్టరీ కాదు. ఇది క్లయింట్కు resolver వరకు మార్గం ఇస్తుంది, ఏ జోన్ అడగాలో చెప్పదు.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ల్యాప్టాప్ VPN తో కనెక్ట్ అయిందని పబ్లిక్ resolver ప్రైవేట్ జోన్ను నేర్చుకోదు.

ప్రత్యయం కూడా అంతే శ్రద్ధకు అర్హం. సంస్థ నియంత్రించే డొమైన్ యొక్క ఉపడొమైన్ ఉపయోగించండి, తద్వారా యాజమాన్యం మరియు సర్టిఫికెట్ ప్రణాళిక స్పష్టంగా ఉంటాయి. .local ను నివారించండి: మల్టికాస్ట్ DNS స్పెసిఫికేషన్ ఆ ప్రత్యయాన్ని లింక్-లోకల్ పరిష్కారంతో కలుపుతుంది, మరియు రూట్ చేసిన టన్నెల్ ఆ ప్రవర్తనను మీ కోసం పునరుత్పత్తి చేయదు.

రెండవ షరతు: సేవ ఏ మూలాన్ని పొందుతుంది?

యాక్సెస్ నియమాలు చిరునామాలపై రాయబడతాయి, కాబట్టి ఉపయోగకరమైన ప్రశ్న ఏమిటంటే రూటింగ్ మరియు అనువాదం తర్వాత సేవ ఏ చిరునామాను చూస్తుంది. 10.20.30.40 లోని ఉదాహరణ సేవకు, కార్యాలయ క్లయింట్లు 10.20.30.0/24 నుండి వస్తారు మరియు దూరపు క్లయింట్లు 10.99.0.0/24 వంటి ప్రత్యేక పూల్ నుండి వస్తారు.

గేట్వే దూరపు పూల్ను అనువదిస్తే, సేవ అనువాదకుడిని చూస్తుంది, మరియు 10.99.0.0/24 కోసం రాసిన నియమం సరిపోలదు.

దీన్ని క్లయింట్ వైపు నుండి కాదు, సేవ వైపు నుండి చదవండి. సేవ హోస్ట్పై శ్రోత లాగ్ లేదా ప్యాకెట్ క్యాప్చర్ నిజంగా వచ్చిన మూలాన్ని చూపుతుంది; క్లయింట్ స్వంత చిరునామా మార్గంలో మిగిలిన దాని గురించి ఒక ఊహ మాత్రమే.

మూడవ షరతు: పేరు సేవతో ముడిపడి ఉందా లేక హోస్ట్తో?

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

ఒకే అంతర్గత సేవకు, నేరుగా రికార్డ్ సాధారణంగా సరిపోతుంది మరియు ఆలోచించడం సులభం.

భర్తీ చేయబడే, పునర్నిర్మించబడే లేదా స్కేల్ చేయబడే ఏదైనా, స్థిర ముందు భాగం అదనపు కాన్ఫిగరేషన్కు అర్హం. పరీక్ష సులభం: వినియోగదారులకు చెప్పకుండా మీరు బ్యాకెండ్ను భర్తీ చేయగలిగితే, పేరు సేవతో ముడిపడి ఉంది; చేయలేకపోతే, అది హోస్ట్తో ముడిపడి ఉంది.

రెండు నిర్ణయాలను విడివిడిగా పరీక్షించండి

మొదట పరిష్కరించండి, తర్వాత కనెక్ట్ అవ్వండి. ఆశించిన చిరునామాను తిరిగి ఇచ్చే పరిష్కార పరీక్ష పేరు మార్గాన్ని నిరూపిస్తుంది మరియు యాక్సెస్ గురించి ఏమీ చెప్పదు. కనెక్షన్ పరీక్ష మార్గాన్ని మరియు నియమాన్ని కలిసి నిరూపిస్తుంది, కాబట్టి పరిష్కారం విజయవంతమైన తర్వాతే దాన్ని అమలు చేయండి.

curl -sv --max-time 5 https://files.corp.example/health

తర్వాత ఒకసారి నిషేధిత మూలాన్ని పరీక్షించి, ఫలితాన్ని నమోదు చేయండి.

మీ డాక్యుమెంటేషన్లో రెండు రికార్డులను విడివిడిగా ఉంచండి: పేరు మరియు దాని జోన్, అంగీకరించిన మూలాలు మరియు నియమం యజమాని. ఒకటి మారినప్పుడు, మరొకటి మారాల్సిన అవసరం లేదు.

నిర్ణయం సాధారణంగా ఎక్కడ తప్పు జరుగుతుంది

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

ఒక విజయవంతమైన పరీక్ష నుండి ఏ తప్పు కనిపించదు. అందుకే రెండు నిర్ణయాలకు వేర్వేరు రికార్డులు మరియు వేర్వేరు పరీక్షలు అవసరం, ఒకే వ్యక్తి రెండింటినీ తీసుకున్నా.

సేవ ప్రారంభమయ్యే ముందు రెండింటినీ రాయండి, తదుపరి మార్పు గురించి ఆలోచించడం సులభమవుతుంది. రికార్డు చిన్నది: పేరు మరియు దాని జోన్కు ఒక లైన్, అంగీకరించిన మూలాలకు మరియు నియమం యజమానికి ఒక లైన్.