WireGuard DNS iPhone-ում՝ դոմենը միայն որոնման վերջածանց է

Դուք գրում եք մեկ տող՝ լուծիչի հասցեով և ընկերության դոմենով, ակնկալելով, որ միայն այդ դոմենի անունները կօգտագործեն թունելի լուծիչը։ Apple-ի հաճախորդում այժմ բոլոր անունները գնում են այնտեղ, և դոմենի կարճ անունները նույնպես լուծվում են։ Տողը երկու առանձին բան է անում, և դրանցից միայն մեկն է այն մասին, թե որ հարցումներն է թունելը մշակում։ Մյուսը մուտքագրելու հարմարություն է, որը ցանկալի ընթերցմամբ բարձրացվել է մինչև քաղաքականություն։

Ինչի է վերածվում DNS տողը

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

DNS = 10.24.8.53, lab.internal.example

Հասցեն տալիս է լուծիչը։ Դոմենը տալիս է վերջածանց, որը թույլ է տալիս հաճախորդին մուտքագրել կարճ անուն, իսկ համակարգին՝ հարցնելուց առաջ ավելացնել մնացածը։ Տարրերից ոչ մեկը ոչինչ չի ասում լուծիչը այդ դոմենով սահմանափակելու մասին, և դա հենց այն մասն է, որ մարդիկ ակնկալում են և չեն ստանում։ Միայն մեկ դաշտ հարթակում կարող է արտահայտել այդ սահմանափակումը, և դա այս դաշտը չէ։

Apple-ի երկու դաշտ, երկու տարբեր աշխատանք

Apple-ը տարբերությունը ցույց է տալիս իր DNS կարգավորումների օբյեկտում։ Որոնման դոմենների ցանկը փաստաթղթավորված է որպես մեկ պիտակով հոսթանունները որակավորելու համար օգտագործվող ցանկ՝ մուտքագրեք մերկ հոսթանուն, և համակարգը կարող է հերթով ավելացնել յուրաքանչյուր վերջածանց։ Սա լրացման կանոն է, ոչ թե երթուղավորման կանոն։ Այդ ցանկում ոչինչ չի որոշում, թե որ սերվերին է հարցվում։

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

Այսպիսով, այդ տողի դոմենը անվանատարածքի ընտրիչ չէ։ Եվս մեկ ավելացնելը չի նեղացնում, թե որ հարցումներն է օգտագործում թունելը, և հեռացնելը նույնպես չի լայնացնում դրանք։ Փոխվում է միայն այն, թե քանի կարճ անուն է լրացվում։

Ինչու ամեն անուն դեռ հասնում է թունելի լուծիչին

Դատարկ համապատասխանության գրառման դեպքում թունելը սովորական անունների համար թեկնածու լուծիչ է, ոչ միայն ընկերության դոմենի համար։ Ամբողջական թունելի կարգավորման դեպքում սա սովորաբար քիչ նշանակություն ունի, քանի որ ամբողջ երթևեկությունն ամեն դեպքում թունելում է։ Բաժանված թունելում սա շատ կարևոր է։ Հանրային անունները այժմ կարող են լուծվել լուծիչով, որն ունի միայն մասնավոր գոտի, և խափանումը նման է կոտրված VPN-ի, մինչդեռ իրականում դա լուծիչ է, որը պատասխանում է անվանատարածքի միայն մի մասին։ Թունելը կարգին է, հարցումները դուրս են գալիս, և պատասխանները վերադառնում են դատարկ։

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

Ինչի՞ կարիքը կունենար բաժանված DNS-ը իրականում

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

Կառավարվող Apple սարքերում սա սովորաբար տրամադրվում է կարգավորման պրոֆիլով, որը կրում է դոմենին հատուկ DNS կարգավորումները։ Սա տարբեր մեխանիզմ է WireGuard-ի կարգավորման ֆայլից, և երկուսը կարող են գոյակցել միայն այն դեպքում, երբ հաճախորդը հարգում է պրոֆիլը։ Ստուգեք, թե ձեր հաճախորդն ինչպես է իրականում անվանում դաշտը, նախքան ենթադրել, որ երկու արտադրանքները նույն կերպ են վարվում։ Mac-ում wg-quick սկրիպտը և iPhone-ում WireGuard հավելվածը կարդում են նման տողեր և տեղադրում դրանք տարբեր շերտերով։

Կարդացեք տեղադրված կարգավորումները, ոչ թե կոնֆիգը

Mac-ում կարող եք ստուգել, թե ինչի է հանգել համակարգը, ինչն ավելի տեղեկատվական է, քան ձեր գրած ֆայլը նորից կարդալը։ Լուծիչների ցանկը ցույց է տալիս, թե որ սերվերներն են կարգավորված որ դոմենների համար, և սահմանափակ հարցումները ցույց են տալիս, թե որն է հաղթել։ Տողը փչացնող հաճախորդը դա ցույց է տալիս այստեղ, այլ ոչ թե ձեր գրած ֆայլում։ iOS-ում համարժեք հրամանի տող չկա, ուստի այնտեղ ապացույցը արդյունք է՝ մասնավոր անուն, որը լուծվում է թունելի միջով, և հանրային անուն, որի պատասխանը բացահայտում է, թե որ լուծիչն է պատասխանել։

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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