VPN లోపల mDNS: .local పేర్లు ఎందుకు పరిష్కరించబడవు

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

ఈరోజు ఏది పరిష్కరించబడుతుంది మరియు ఏది పరిష్కరించబడినట్లు మాత్రమే కనిపిస్తుందో తనిఖీ చేయండి

మొదట రెండు ప్రశ్నలను వేరు చేయండి: హోస్ట్ పేరు కోసం unicast ప్రశ్న రిజాల్వర్ను అడుగుతుంది, _ipp._tcp కోసం వెతుకుడు స్థానిక లింక్ను అడుగుతుంది. Linuxలో, avahi-browse -a మల్టీకాస్ట్ DNS ఏమి చూడగలదో చూపిస్తుంది, resolvectl query name.local రిజాల్వర్ స్టాక్ ఆ పేరుతో ఏమి చేస్తుందో చూపిస్తుంది. macOSలో, dns-sd -B _ipp._tcp మొదట చిరునామా అవసరం లేకుండా కనుగొన్న సేవలను జాబితా చేస్తుంది.

చిరునామా సమాధానం ఇచ్చి పేరు ఇవ్వకపోతే, రూటింగ్ పనిచేస్తుంది మరియు ఆవిష్కరణ పనిచేయదు. .local పేరుకు avahi-browse ఇన్స్టాల్ కాకపోయినా nss-mdns ద్వారా హోస్ట్పైనే సమాధానం ఇవ్వవచ్చు, కాబట్టి ఆ పేరుకు విజయవంతమైన getent లేదా పింగ్ ఆవిష్కరణ సురంగాన్ని దాటిందని రుజువు కాదు; శోధన ఫలితం మరియు రిజాల్వర్ ఫలితం వేర్వేరు రుజువులు. యాప్లు కనుగొన్నదాన్ని కాష్ చేస్తాయి, అందుకే వైఫల్యం కనెక్ట్ అయిన వెంటనే కాకుండా కనెక్ట్ అయిన గంటల తర్వాత కనిపిస్తుంది. యాప్ను మూసి మళ్లీ తెరవండి, ఆ తర్వాత కాష్ చేసిన ఎంట్రీలో పేరు ఉందా చిరునామా ఉందా తనిఖీ చేయండి, ఎందుకంటే ఆవిష్కరణ ఆగిన తర్వాత కూడా చిరునామా చాలా కాలం పనిచేస్తుంది.

ప్రశ్న ఎందుకు ఎప్పటికీ సురంగాన్ని దాటదు

మల్టీకాస్ట్ DNS ప్రశ్నలను 224.0.0.251కి, స్థానిక నెట్వర్క్ నియంత్రణ బ్లాక్ లోపల, UDP పోర్ట్ 5353పై పంపుతుంది. రౌటర్లు ఆ బ్లాక్ చిరునామాలను ఫార్వర్డ్ చేయవు, కాబట్టి ప్రశ్న పంపిన లింక్లోనే ఉంటుంది. పంపేవారు IP TTL లేదా IPv6 హాప్ పరిమితిని 255కి సెట్ చేస్తారు, తద్వారా స్వీకర్త ఇప్పటికే రౌటర్ దాటిన ప్యాకెట్ను తిరస్కరించగలరు; లింక్ వెలుపలి ఫోర్జరీని ప్రోటోకాల్ ఇలా గుర్తిస్తుంది, ఇలా స్థానికంగా ఉండదు. స్థానికత గమ్యస్థాన చిరునామా నుండి వస్తుంది, ఒక-హాప్ TTL నుండి కాదు.

సురంగ రకం కూడా ముఖ్యం. tun శైలి ఇంటర్ఫేస్ IP ప్యాకెట్లను మాత్రమే తీసుకువెళుతుంది, వేరే ఏదీ కాదు, కాబట్టి ఏ మల్టీకాస్ట్ సమూహం దాని ద్వారా మనుగడ సాగించదు. tap శైలి వంతెన ప్రసార డొమైన్ను స్వయంగా విస్తరిస్తుంది, అందుకే కొన్ని పాత డిజైన్లు రూటింగ్కు బదులు వంతెన నిర్మించాయి, వంతెన తెచ్చే ప్రతి సమస్యను వారసత్వంగా పొందాయి.

నమ్మదగిన LAN కోసం మినహాయింపు ఇందులో ఏదీ మార్చదు, ఎందుకంటే అది సురంగానికి మల్టీకాస్ట్ ఫార్వర్డ్ చేయడం నేర్పించడం బదులు ఏ ట్రాఫిక్ సురంగాన్ని ఉపయోగించవచ్చో నిర్ణయిస్తుంది. ప్యాకెట్కు ఇంకా వినడానికి ఉమ్మడి విభాగం లేదు.

మీరు నిర్వహించగల నామకరణ డిజైన్ను ఎంచుకోండి

కంపెనీ వనరుల కోసం నిలకడైన సమాధానం VPN నెట్టే రిజాల్వర్ అందించే రూట్ చేయబడిన హోస్ట్ పేరు, దానితో పాటు విభజిత DNS, అంతర్గత పేర్లు అంతర్గత సర్వర్లకు వెళ్లాలి మరియు మిగతావి వెళ్లకూడదు. Windows దీన్ని పేరు పరిష్కార విధాన పట్టికగా చూపిస్తుంది, macOS ప్రతి ఇంటర్ఫేస్కు పరిమిత రిజాల్వర్లను ఉపయోగిస్తుంది, చాలా క్లయింట్లకు సమానమైన పుష్ సెట్టింగ్ ఉంటుంది. పరికరం అంతర్గత DNSలో తన సాధారణ పేరును ఉంచుతుంది, ఆవిష్కరణ మార్గంలో భాగం కావడం ఆపేస్తుంది.

ఆవిష్కరణ ప్రాక్సీ లేదా mDNS రిఫ్లెక్టర్ ఈ అంతరాన్ని వంతెన చేయగలదు, మరియు అది తన సొంత హోస్ట్, తన సొంత బహిర్గతం మరియు తన సొంత క్లయింట్ అవసరాలతో కూడిన నిజమైన డిజైన్. మీరు మార్గాన్ని జోడించినందుకు అది కనిపించదు. .local ప్రశ్నలను ఎప్పుడూ పబ్లిక్ రిజాల్వర్కు ఫార్వర్డ్ చేయవద్దు: డొమైన్ RFC 6762 ద్వారా స్థానిక మల్టీకాస్ట్ వినియోగానికి రిజర్వ్ చేయబడింది, దాన్ని బయటకు పంపడం నెమ్మదైన వైఫల్యాలు మరియు అనవసర డేటా వెల్లడిని కలిగిస్తుంది.

పేరు కాదు, సేవను ధృవీకరించండి

శోధన జాబితాలోని పేరు ఆవిష్కరణ దశను రుజువు చేస్తుంది, సేవ సమాధానం ఇస్తుందని కాదు. ప్రింట్ క్యూ లేదా వెబ్ ఇంటర్ఫేస్ తెరిచి నిజమైన ఆపరేషన్ పూర్తి చేయండి, ఆ తర్వాత మళ్లీ కనెక్ట్ అయిన తర్వాత దాన్ని పునరావృతం చేయండి.

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