Ինչու են անվանումների որոնումները ձախողվում երթուղավորված 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 սերվեր ստանալ։ Թունելը մնում է երթուղավորված, և սեգմենտը մնում է իր տեղում։

Երկու պայման է որոշում՝ կաշխատի՞ արդյոք։ Նշված սերվերը պետք է պատասխանի գոտու համար, և հարցումը պետք է թույլատրվի թունելով։

Փորձարկեք լուծիչը հաճախորդից, այլ ոչ թե սերվերի սեփական shell-ից։ Տեղայնորեն աշխատող լուծիչը ոչինչ չի ասում, թե ինչ է կրում թունելը։

Պարզեք, թե որ շերտը ձախողվեց

Նախ ping արեք հասցեին, ապա լուծեք անվանումը և կարդացեք, թե որ սերվերն է պատասխանել։ Գոտին չհոսթավորող սերվերի բացասական պատասխանը այլ տեսք ունի, քան այն հարցումը, որը երբեք չի լքել մեքենան։ Անվանում, որը լուծվում է, բայց մերժում է կապերը, բոլորովին երրորդ խնդիր է։

Multicast-ը նույն պատի հետևում է։ 224.0.0.251-ի նման խումբը լռելյայն չի փոխանցվում երթուղավորված թունելով, և խմբի երթուղին բավարար չէ առանց multicast-ը հասկացող ուղու կամ LAN-ում անդրադարձիչի։