OpenVPN-ը DNS է ուղարկում, բայց լուծիչը կարող է դա երբեք չտեսնել
Կլիենտի մատյանում DNS արժեքի առկայությունը չի ապացուցում, որ օպերացիոն համակարգի լուծիչը օգտագործում է այն։ Ստուգեք սեփականատիրոջը, ապա փորձարկեք ներքին անուն։
Կլիենտի մատյանը ցույց է տալիս ուղարկված DNS սերվերը, թունելը միացված է, իսկ ներքին անունը դեռ ոչնչի չի լուծվում։ Ուղարկելու մեջ ինքնին ոչինչ կոտրված չէ։ Տարբերակը հասել է, և օպերացիոն համակարգի լուծիչը երբեք չի օգտագործել այն, քանի որ Unix կլիենտների մեծ մասում OpenVPN-ը փոխանցում է արժեքը և հավելվածը թողնում է հարթակին։
Ախտանիշը՝ մատյանը ցույց է տալիս DNS, իսկ անունները դեռ ձախողվում են
OpenVPN dhcp-option-ը կրում է DNS և դոմենի տեղեկատվություն, և կլիենտը գրանցում է, թե ինչ ստացավ։ Որոշ ներդրումներում կլիենտը ներքուստ կիրառում է այդ կարգավորումները, մյուսներում՝ արտահանում է դրանք ինտեգրացիոն սկրիպտի կամ ցանցային ծառայության համար։ Մատյանի տողը նկարագրում է պատմության միայն առաջին կեսը։ Երկրորդ կեսը տեղի է ունենում այնտեղ, որտեղ կլիենտը չի վերահսկում։ Այնտեղ է սովորաբար ապրում ձախողումը։
Այդ պատճառով միացված թունելն ու ձախողվող ներքին անունը այդքան հաճախ գոյակցում են։ Արժեքը կա, սպառողը բացակայում է կամ սխալ կարգավորված է, և լուծիչը լուռ շարունակում է օգտագործել այն հանրային սերվերը, որն օգտագործում էր միացումից առաջ։
Ստանալը կիրառել չէ
Կլիենտը կարող է գրանցել ուղարկված DNS արժեք, մինչդեռ համակարգի լուծիչը դեռ պատկանում է այլ ծառայության։ Դիտարկիչը կարող է ունենալ նաև գաղտնագրված DNS-ի իր քաղաքականությունը, որն ամբողջությամբ շրջանցում է համակարգի լուծիչը, ինչը ստեղծում է հիշարժան իրավիճակ, երբ մի հավելված լուծում է ներքին անուններ, իսկ մյուսը՝ ոչ։
Ստուգեք ներդրման աջակցվող ինտեգրացիան՝ փոխարենը ենթադրելու, որ յուրաքանչյուր Unix կլիենտ վերագրում է նույն ֆայլը։ Այդ ենթադրությունն է պատճառը, որ մարդիկ խմբագրում են լուծիչի կարգավորում, որը ոչինչ չի կարդում։
Գտեք լուծիչի սեփականատիրոջը՝ ըստ հարթակի
Windows-ում անունների լուծման քաղաքականության աղյուսակը կարող է որոշակի վերջավորություններ ուղղել որոշակի սերվերների, և VPN կլիենտը կարող է այնտեղ կանոններ տեղադրել։ Ստուգեք քաղաքականությունը, ոչ միայն ադապտերի DNS ցանկը։ Linux-ում կարգավորումը կարող է պատկանել NetworkManager-ին կամ systemd-resolved-ին, և թե որն է տերը, դա որոշում է, թե ինչ կպահպանվի վերամիացման ժամանակ։
Կարդացեք փաստացի վիճակը այն գործիքով, որն իսկապես պատասխանում է հարցումներին՝ resolvectl query internal.example.net systemd-resolved հոսթում, կամ հարթակի համարժեքը։ Ապա համեմատեք այդ պատասխանը այն DNS սերվերի հետ, որը կլիենտի մատյանը պնդում է, թե ուղարկել է։
Խուսափեք մի քանի ծառայություններից, որոնք առանց համակարգման վերագրում են լուծիչի կարգավորումները։ Երկու տերերը տալիս են ընդհատվող թվացող արդյունք, և յուրաքանչյուր վերամիացում կարծես պատահականորեն ուղղում կամ փչացնում է այն։
Սկրիպտներ և foreign_option
OpenVPN-ը ուղարկված տարբերակները արտահանում է սկրիպտներին foreign_option_N անունով փոփոխականների միջոցով, և սկրիպտը կարող է դրանք թարգմանել լուծիչի հրամանների։ Այդ կարգավորումը աջակցվող ինտեգրացիա է, ոչ ավտոմատ վարք, և այն պետք է տեղադրվի ու կանչվի կլիենտում։
Եթե ապավինում եք սկրիպտի, գրանցեք դրա կատարումը և ելքի կարգավիճակը։ Սկրիպտը, որն աշխատում է, բայց լուռ ձախողվում է, թողնում է նույն ախտանիշը, ինչ սկրիպտի բացակայությունը, և ավելի դժվար է նկատել, քանի որ կարգավորումը ամբողջական է թվում։ Ստուգեք սկրիպտի ելքը, ոչ թե սկրիպտի ֆայլը։ Գոյություն ունեցող ֆայլը չաշխատած սկրիպտ չէ։
Փորձարկեք անունը, ոչ թե մատյանը
Միանալուց հետո կլիենտից հարցրեք միայն ներքին հոսթանուն, ապա հանրային անուն, ապա ստուգեք, թե որ սերվերն է պատասխանել։ Աշխատող տեղադրման դեպքում երկու պատասխանները գալիս են տարբեր տեղերից, և երկուսն էլ պետք է համապատասխանեն նախագծին։
Եթե անունը լուծվում է, բայց ծառայությունը ձախողվում է, անցեք երթուղղմանը և հավելվածների հասանելիությանը՝ DNS-ը նորից փոխելու փոխարեն։ OpenVPN-ի ձեռնարկը փաստաթղթավորում է dhcp-option-ը և սկրիպտային միջավայրը։ Օգտագործեք այն՝ հաստատելու, թե ինչ է սպասվում ձեր կլիենտից կիրառել, նախքան մեկ այլ լուծիչի ֆայլ խմբագրելը։