Ինչպես կարդալ VPN DNS-ի երթուղավորումը յուրաքանչյուր կապի համար resolvectl-ից

Կատարեք resolvectl status և կստանաք պատ՝ յուրաքանչյուր կապի բլոկներով, յուրաքանչյուրն իր սերվերներով և իր տիրույթների տողով։ Երթուղավորումը որոշող տողը տիրույթների ցանկն է, ոչ թե անվան սերվերի հասցեն, քանի որ տեղական stub-ը յուրաքանչյուր հարցում ուղարկում է այն կապին, որը պահանջում է անունը։ Կարդացեք այդ պահանջները նախքան պատասխանը կարդալը, ապա հարցրեք անունը և ստուգեք, թե որ կապն է այն ստեղծել։ Ճիշտ կապից սխալ պատասխանն այլ խնդիր է, քան սխալ կապից ճիշտ պատասխանը։

Ինչ է ձեզ ասում յուրաքանչյուր կապի բլոկը

Յուրաքանչյուր բլոկ թվարկում է սերվերները, որոնք լուծիչը կօգտագործի այդ ինտերֆեյսի համար, տիրույթների ցանկը և արդյոք կապը լռելյայն երթուղին է։ Տիրույթների ցանկը պահանջների բազմություն է, և լուծիչը կիրառում է ամենաերկար վերջածանցի համընկնումը՝ host.corp.example-ի հարցումը պահանջում է corp.example կրող կապը՝ նախքան միայն լռելյայն երթուղին կրողը։ Երկու կապեր, որոնք պահանջում են նույն վերջածանցը, արդյունքը թողնում են առաջնահերթությանը և կարգին, դրա համար կրկնօրինակներն առաջինն են արժանի ուշադրության։ Ընթացիկ սերվերի տողը ցույց է տալիս, թե թվարկված սերվերներից որն է այդ պահին օգտագործվում։

Stub հասցեն, ինչպես 127.0.0.53-ը /etc/resolv.conf-ում, ասում է միայն, որ stub-ը առջևում է։ Այն չի նշում պատասխանած վերին հոսքը, դրա համար միայն resolv.conf-ի վրա հիմնված ախտորոշումը կանգ է առնում։

Ճիշտ կարդացեք տիրույթի գրառումների երեք տեսակները

Տիլդան փոխում է որոնման վարքը, ոչ թե երթուղավորումը։ Առանց տիլդայի գրառումը և՛ երթուղավորման տիրույթ է, և՛ որոնման տիրույթ, ուստի դրա տակ գտնվող անունները ուղարկվում են այդ կապին, և մեկ պիտակով անուններին ավելացվում է վերջածանցը։ Տիլդայով գրառումը երթուղավորում է նույն վերջածանցը՝ պահելով այն որոնման ցանկից դուրս։ Դրա համար տիլդան հեռացնելը փոխում է, թե որ մերկ անուններն են լուծվում, և դրա համար բացակայող տիլդան որոնման խնդիր է, ոչ թե բաժանված DNS-ի ձախողում։

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

Հարցրեք անուն և տեսեք, թե որ կապն է պատասխանել

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

resolvectl status
resolvectl query host.corp.example

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

Առանձնացրեք անունների երթուղավորումը փաթեթների երթուղավորումից

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

Հավելվածները կարող են ամբողջությամբ շրջանցել համակարգի լուծիչը՝ իրենց անվտանգ DNS կարգավորմամբ կամ ներկառուցված լուծիչով։ resolvectl-ի արդյունքը նկարագրում է համակարգի ուղին, և այն անտեսող դիտարկիչը կհակասի ձեր կատարած յուրաքանչյուր փորձարկմանը։ Ստուգեք այդ կարգավորումը նախքան եզրակացնելը, որ քաղաքականությունը կոտրված է։

Գրանցեք այն հասցեն, որին լուծվել է անունը՝ կապի կողքին։ Ճիշտ անունը, որը ցույց է տալիս սխալ հասցե, գրառման խնդիր է, ոչ թե երթուղավորման։

Կրկին ստուգեք կապի փոփոխությունից հետո

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

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