Android-ի VPN-ը լուծում է լրիվ հոսթանունը, բայց ոչ կարճ անունը

Դուք մուտքագրում եքfilesտերմինալի էմուլյատորում և ոչինչ չի վերադառնում. մուտքագրում եքfiles.corp.exampleև նույն սերվերը անմիջապես պատասխանում է։ VPN-ի հավատարմագրերում ոչինչ չի փոխվել, և մասնավոր DNS սերվերը երբեք չի խափանվել։ Android-ում կարճ պիտակը և լրիվ անունը տարբեր ուղիներով են անցնում լուծիչով, և այդ ուղիներից մեկը կախված է այն կարգավորումից, որը պետք է տրամադրի թունելի սեփականատերը։ Ձեր առջև դրված որոշումը ոչ թե այն է, թե որ DNS սերվերը փոխել, այլ այն է, թե ով է վերահսկում այն ցանցը, որն իրականում օգտագործում է հավելվածը։

Որոնման դոմենը հասցե չէ։ Դա վերջածանցների ցանկ է, որոնք լուծիչը ավելացնում է մերկ պիտակին՝ նախքան հանձնվելը։

Որոնման վերջածանցը և DNS սերվերը առանձին դաշտեր են

Լուծիչի հասցեն Android-ին ասում է, թե որտեղ հարցնել։ Որոնման վերջածանցը ասում է, թե ինչ հարցնել, երբ տրամադրում եք միայն ձախ պիտակը։ Երկուսն էլ ապրում են նույն ցանցային օբյեկտի վրա, և յուրաքանչյուրը կարող է բացակայել ինքնուրույն։

Հենց այդ անկախությունն է բացատրում, թե ինչու է աշխատում լրիվ հոսթանունը։ Ամբողջովին որակավորված անունը վերջածանցի կարիք չունի, որովհետև այն արդեն այն տողն է, որ գնում է սերվերին։

Android-ը բացահայտում է այդ բաժանումըLinkProperties-ի միջոցով։ DNS սերվերների ցանկը և դոմենների որոնման ցանկը նստած են նույն օբյեկտի վրա, և երկրորդը հաճախ դատարկ է նույնիսկ այն դեպքում, երբ առաջինը լրիվ լցված է։ Լուծիչ ունեցող, բայց դոմեն չունեցող ցանցը ցանց է, որտեղ վերջածանցը երբեք չի կիրառվել՝ ոչ թե սերվեր, որը մերժել է կարճ անունը։

Կարդացեք արդյունավետ ցանցը նախքան ինչ-որ բան փոխելը

Wi-Fi-ը, բջջային ցանցը և VPN ինտերֆեյսը երեք առանձին ցանցեր են, և թունելը դառնում է լռելյայն, հենց որ բարձրանում է։ Ուստի գրասենյակի Wi-Fi-ում աշխատած վերջածանցը ինքնաբերաբար այն վերջածանցը չէ, որն ուժի մեջ է թունելի ակտիվ ժամանակ։ Ստուգեք այն ցանցը, որի վրա հավելվածն իրականում ընտրված է, ոչ թե այն, որը կարգավորել եք անցյալ շաբաթ։

Սարքի տերմինալային կեղևը վատ վկա է այստեղ, որովհետև նրաresolv.confլուծիչի մեկ տեսակետն է արտացոլում, ոչ թե յուրաքանչյուր հավելվածինը։

Զննարկիչների հասցեատողերը ավելացնում են ևս մեկ շերտ. մերկ բառը կարող է դիտվել որպես որոնման հարցում կամ լուծվելզննարկչի սեփական գաղտնագրված DNS քաղաքականությանմիջոցով, ուստի Chrome-ում բեռնվող էջը ոչինչ չի ապացուցում համակարգային որոնումների մասին։ Փորձարկեք մի բանով, որն օգտագործում է հարթակի լուծիչը և տպում է, թե ինչ վերադարձավ։ Այնուհետև գործարկեք կարճ և լրիվ ձևերը նույն նստաշրջանում, նույն ցանցում, և նշեք, թե որն է պատասխան տվել։

Եթե դուք եք կառուցում VPN հավելվածը, վերջածանցը կցեք կառուցիչում

Երբ ձեր հավելվածը ինտերֆեյսը հաստատում էVpnService-ի միջոցով,addSearchDomainսա այդ նպատակի համար աջակցվող մուտքն է։ Այն ընդունում է դոմենի տող, օրինակ՝corp.example, և սա սերվերի հասցեն փոխանցելու այլընտրանքային եղանակ չէ։

Կանչը վերջածանցը կապում է այն ցանցին, որը կառուցում եք, ուստի հետո շրջելու համաշխարհային կարգավորում չկա։ Եթե հավելվածը քանդում է ինտերֆեյսը և վերակառուցում այն վերամիացման ժամանակ, նոր կառուցիչը պետք է կրկին ավելացնի վերջածանցը, այլապես փոխարինող ցանցը բարձրանում է առանց դրա։

Այստեղ են սեղանադիր պրոֆիլների ներմուծումներից շատերը կորցնում այս դաշտը։ Արտահանողը դոմենը գրում է իր մոդելի մեջ, Android-ի առջևը քարտեզագրում է միայն այն ընտրանքները, որոնք գիտի, և ստացված ինտերֆեյսը մնացած բոլոր առումներով ճիշտ է թվում։ Պրոֆիլը, որն աշխատում է դյուրակիր համակարգչում և ձախողվում հեռախոսում, սովորաբար քարտեզագրման բաց է, ոչ թե արձանագրության խնդիր։

Եթե դուք միայն օգտագործում եք VPN-ը, սա ձեր դնելու բանը չէ

Չկա հաճախորդի կողմի խմբագրում, որը վերջածանց ավելացնի, և չկա համաշխարհային հատկություն, որը կարող եք փոխել՝ մեկը կեղծելու համար։ Արժեքը տրամադրում է նա, ով տիրապետում է թունելին՝ կառավարվող հաճախորդի պրոֆիլում, դրա հարթակային քարտեզագրման մեջ կամ այն ամենի միջոցով, ինչ ուղարկում է սերվերը։ Ասեք, թե որ հարթակում եք և որ անունն է ձախողվում, որովհետև սեղանադիր և բջջային առջևները տարբերվում են հենց այս դաշտում։

Սեղանադիր պրոֆիլի կրկնակի ներմուծումը կրկին ոչինչ չի ապացուցում բջջային քարտեզագրման մասին։

Երեք պայման է որոշում, թե դուք թերություն ունեք, թե սպասվող սահմանափակում։ Առաջին՝ կազմակերպությունն ընդհանրապես կարճ պիտակը համարո՞ւմ է աջակցվող անուն, թե դա հարմարավետություն է, որ երբևէ աշխատել է միայն գրասենյակի Wi-Fi-ում։ Երկրորդ՝ ձախողվող որոնումը գալիս է զննարկչից, որը կարող է ամբողջությամբ շրջանցել համակարգի լուծիչը։ Երրորդ՝ կարճ անունը պետք է հասանելի լինի թունելով, թե միայն LAN-ից։ Եթե վերջին պատասխանը միայն-LAN է, վերջածանց ավելացնելը կստեղծի անուն, որը լուծվում է գրասենյակից դուրս և հետո չի երթուղվում։

Երբ վերջածանցը առկա է, և կարճ անունները դեռ ձախողվում են

Եթե դոմենների որոնման ցանկն արդեն ցույց է տալիսcorp.example, դադարեք մեղադրել վերջածանցին։ Ստուգեք՝ արդյոք լուծիչն ընդհանրապես պատասխան է վերադարձնում ընդլայնված անվան համար, որովհետև վերջածանցը փոխում է միայն այն հարցը, որ դուք տալիս եք։ Այն երբեք սերվերին իշխանավոր չի դարձնում այն զոնայի համար, որը նա չի հոսթավորում։

Ապա ստուգեք երթուղին։ Հասցեն, որը լուծվում է, բայց թունելը չի տեղափոխում, ձախողվում է միացման պահին, ինչը նույն տեսքն ունի, ինչ զննարկչում լուռ հանձնվող որոնման ձախողումը։

Վկայագրերը առանձին հիշատակման արժանի են։ HTTPS-ի վավերացումը օգտագործում է այն հոսթանունը, որը դուք իրականում մուտքագրել եք, ուստի ճիշտ ընդլայնվող կարճ անունը ձեռքսեղմման ժամանակ դեռ ներկայացնում էfiles։ Վկայագիրը, որը տրվել էfiles.corp.exampleհասցեի համար, չի վավերացվի այդ կարճ անվան համար, և այդ սխալը ճիշտ վարքագիծ է, ոչ թե ձեր սկսած DNS խնդրի ախտանիշ։

Ինչ անել հետո

Հաստատեք բաժանումը նախքան ինչ-որ բանի դիպչելը. լրիվ անունը լուծվում է, կարճը՝ ոչ, նույն հավելվածը, նույն նստաշրջանը։ Ապա գտեք ընտրված ցանցը և կարդացեք դրա դոմենների որոնման ցանկը լուծիչների ցանկի կողքին։ Երկուսից որն է դատարկ, դա է ասում, թե ով պետք է գործի՝ դուք, եթե հավելվածը ձերն է. թունելի օպերատորը, եթե ոչ։

Վերջում, որտեղ տեղափոխելիությունը կարևոր է, նախընտրեք ծառայության լրիվ հոսթանունը էջանիշներում և հաճախորդի կարգավորումներում։ Այն վերապրում է ցանցի փոփոխությունը, կախված չէ քարտեզագրումից, որը բջջային առջևը գուցե չիրականացնի, և համընկնում է այն անվան հետ, որի համար տրվել է վկայագիր։