రూట్ చేసిన OpenVPN టన్నెల్ మీద పేర్ల వెతుకులు ఎందుకు విఫలమవుతాయి

హోస్ట్ చిరునామా ద్వారా ping కి జవాబిస్తుంది, పేరు ద్వారా జరిగే ప్రతి వెతుకులో విఫలమవుతుంది. టన్నెల్ పనిచేస్తోంది, మార్గం కూడా ఉంది, కాబట్టి VPN తప్పుగా కాన్ఫిగర్ చేయబడిందనేది సహజ ముగింపు. మరింత ఉపయోగకరమైన ముగింపు ఏమిటంటే ఆ వెతుకు ఎప్పుడూ రూట్ చేయదగినది కాదు: రూట్ చేసిన టన్నెల్ unicast IP మోస్తుంది, అయితే ఆ ప్రశ్న రెండో వైపు లేని విభాగం కోసం వెతుకుతున్న బ్రాడ్‌కాస్ట్. పొరల అసమతుల్యత కనిపించగానే పరిష్కారాలు తమంతట తాము ఖర్చు ప్రకారం వరుసలో నిలబడతాయి.

అపోహ: పేర్లు విఫలమవుతున్నందున టన్నెల్ పాడైంది

పేరు పొరకు పైన ఉన్నదంతా పనిచేస్తుంది కాబట్టి లక్షణం నమ్మదగినది. చిరునామాలు రూట్ అవుతాయి, ఇంటర్‌ఫేస్ పనిచేస్తోంది, భాగస్వామి ping కి జవాబిస్తాడు. విఫలమైంది పాయింట్-టు-పాయింట్ లింక్ మీద ఎప్పుడూ మార్గం లేని కనుగొనే విధానం, ఇది పాడైన టన్నెల్ కంటే భిన్నమైన ప్రకటన. ఈ రెండు ప్రకటనలను వేరు చేయడమే నిర్ధారణలో పెద్ద భాగం.

దాన్ని టన్నెల్ లోపంగా చూస్తే సహాయపడలేని ప్రొఫైల్ మార్పులకు దారి తీస్తుంది. ఎంపికలు జోడించడం, ఎన్‌క్రిప్షన్ మార్చడం లేదా క్లయింట్‌ను మళ్లీ ఇన్‌స్టాల్ చేయడం బ్రాడ్‌కాస్ట్‌ను ఉన్న చోటే ఉంచుతాయి.

పరిష్కారానికి పేరు పెట్టే ముందు విఫలమైన విధానానికి పేరు పెట్టండి. బ్రాడ్‌కాస్ట్ ఉపయోగించే వెతుకుకు విభాగం కావాలి, రిజాల్వర్ ఉపయోగించే వెతుకుకు అడగడానికి చిరునామా కావాలి.

TUN ఏమి మోస్తుంది, ఏమి మోయదు

TUN పరికరం ఒక IP ఇంటర్‌ఫేస్, అదే దాన్ని రూట్ చేయదగినదిగా చేస్తుంది. OpenVPN క్లయింట్‌కు చిరునామా మరియు మార్గాల సమితిని ఇస్తుంది, ఆ తర్వాత క్లయింట్ భాగస్వామికి డేటాగ్రామ్‌లు పంపుతుంది. ఆ నమూనాలో ప్రతి హోస్ట్ ప్రతి ఫ్రేమ్ వినే పంచుకున్న లింక్‌ను ఏదీ సృష్టించదు.

కనుగొనే ట్రాఫిక్ ఆ నమూనాకు అసలు సరిపోదు. పాత Windows పేరు ప్రశ్నలు, SSDP ప్రకటనలు మరియు mDNS అభ్యర్థనలు ఒక గమ్యానికి బదులు విభాగంలోని అందరికీ పంపబడతాయి. రూట్ చేసిన లింక్‌కు పంపడానికి «అందరూ» ఉండరు. ఆ ప్రతి విధానం పంచుకున్న మాధ్యమాన్ని ఊహిస్తుంది.

అందువల్ల టన్నెల్ ఆరోగ్యంగా ఉండగానే కనుగొనడం పూర్తిగా విఫలం కావచ్చు. ఎవరైనా VPN డౌన్ అని నివేదించినప్పుడు పట్టుకోవాల్సిన వాక్యం అదే.

వంతెన సరిహద్దును తొలగించడం ద్వారా పనిచేస్తుంది

TAP పరికరం ఫ్రేమ్‌లను మోస్తుంది, వంతెన దాన్ని నిజమైన LAN విభాగానికి కలుపుతుంది. అప్పుడు క్లయింట్ ఆ విభాగంలో చిరునామా కలిగి ఉంటుంది, దాని బ్రాడ్‌కాస్ట్ ట్రాఫిక్ వింటుంది. అందుకే వంతెన పేరు సమస్యను నయం చేసినట్టు కనిపిస్తుంది. ఇది చిరునామా కేటాయింపు కోసం క్లయింట్‌ను ఆ విభాగంపై ఆధారపడేలా కూడా చేస్తుంది.

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

చిన్న ప్రయోగశాలకు ఇది న్యాయమైన మార్పిడి. చెదురుమంచిన సిబ్బందికి ఇది అరుదు.

DNS మరియు WINS పుష్ చేయడమే ఇరుకైన పరిష్కారం

క్లయింట్‌కు అడగడానికి నిర్దిష్ట స్థలం ఇవ్వండి. dhcp-option DNS మరియు dhcp-option DOMAIN అంతర్గత పేర్లను జోన్ తెలిసిన సర్వర్‌కు మళ్లిస్తాయి, NetBIOS పై ఇంకా ఆధారపడే Windows క్లయింట్ కూడా అదే విధంగా WINS సర్వర్ పొందగలదు. టన్నెల్ రూట్ చేయబడినట్టే ఉంటుంది, విభాగం తన స్థలంలోనే ఉంటుంది.

ఇది పనిచేస్తుందో లేదో రెండు షరతులు నిర్ణయిస్తాయి. పేర్కొన్న సర్వర్ జోన్ కోసం జవాబివ్వాలి, ప్రశ్నకు టన్నెల్ ద్వారా అనుమతి ఉండాలి.

రిజాల్వర్‌ను సర్వర్ సొంత షెల్ నుంచి కాకుండా క్లయింట్ నుంచి పరీక్షించండి. స్థానికంగా పనిచేసే రిజాల్వర్ టన్నెల్ ఏమి మోస్తుందనే దానిపై ఏమీ చెప్పదు.

ఏ పొర విఫలమైందో కనుగొనండి

మొదట చిరునామాకు ping చేయండి, తర్వాత పేరును పరిష్కరించి ఏ సర్వర్ జవాబిచ్చిందో చదవండి. జోన్‌ను హోస్ట్ చేయని సర్వర్ ప్రతికూల జవాబు, యంత్రం నుంచి ఎప్పుడూ బయటకు వెళ్లని ప్రశ్న కంటే భిన్నంగా కనిపిస్తుంది. పరిష్కరమైనా కనెక్షన్లను తిరస్కరించే పేరు పూర్తిగా మూడో సమస్య.

మల్టీకాస్ట్ అదే గోడ వెనుక ఉంది. 224.0.0.251 వంటి గుంపు డిఫాల్ట్‌గా రూట్ చేసిన టన్నెల్ ద్వారా పంపబడదు, మల్టీకాస్ట్ అర్థం చేసుకునే మార్గం లేదా LAN లో ప్రతిబింబకం లేకుండా గుంపు కోసం మార్గం సరిపోదు.