AdGuard Home-ը պատասխաններ է տալիս WireGuard հաճախորդներին ձեր LAN հասցեից

Թունելը բաց է, firewall-ը թույլ է տալիս 53 պորտը, AdGuard Home-ը աշխատում է, և WireGuard հաճախորդի համար անունները դեռ չեն լուծվում։ Հարցումը սովորաբար գալիս է, և պատասխանն սովորաբար հեռանում է, այնպես որ resolver-ի փաթեթների հաշվողիչները առողջ տեսք ունեն, և ծառայությունը անմեղ է թվում։ Խնդիրը պատասխանի աղբյուրի հասցեում է․ այն հեռանում է տեղական հասցեից, որը հաճախորդը երբեք չի խնդրել, և հաճախորդի stub resolver-ը այնdiscard է անում։ AdGuard Home-ի կոնֆիգուրացիայի մի ցուցակ որոշում է դա, և սովորական նախնական կարգավորումը որոշումը հանձնարարում է kernel-ին։

Հարցումը գալիս է, պատասխանը հեռանում է այլ տեղից

Հաճախորդը, որի կարգավորիչը 10.6.0.1 է, ուղարկում է UDP հարցում 10.6.0.1 հասցեով՝ 53 պորտին: Այն փաթեթը անցնում է թունելի միջով և հասնում հոստին, և AdGuard Home-ը պատասխանում է դրան: Վերինի վրա սակայն, պատասխանն արդեն նոր փաթեթ է, որի աղբյուրի հասցեն ընտրվում է հոստի ստեկի կողմից, ոչ թե հաճախորդի սպասելիքի համաձայն։

Երբ հաճախորդի լուծՄԱՆ կարգավորիչը միացված սոքում է, ինչը օգտագործում են systemd-resolved, dnsmasq և առավել մասը stub լուծիչների, այն ընդունում է միայն պատասխաններ այն հասցեից, որի ուղղությամբ էլ ուղարկվել է հարցումը: 192.168.1.10 հասցեից ուղարկված պատասխան, որը պետք է գնար 10.6.0.1 հասցե, չեղարկվում է մինչև որևէ վերծանում: Լուծիչը գրանցում է հաջող պատասխան, հաճախորդը գրանցում է ժամանակի ավարտ, և երկուսն էլ ասում են ճշմարտությունը:

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

Ինչպե՞ս կորնելը ընտրում է պատասխանման աղբյուրը

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

Մեկ հոսթ ունեցող համակարգում սա անտեսանելի է, քանի որ կա միայն մեկ հավանական պատասխան։ Մեքենայում, որը կրում է LAN հասցե, WireGuard հասցե և կառավարչական հասցե, մի քանի պատասխաններ հնարավոր են, և հաղթողը կախված է այն պահի երթուղավորման աղյուսակից։ Ավելացրեք լրացուցիչ երթուղի, նույն ինտերֆեյսի երկրորդ հասցե, NAT վերածիլի առաջ, կամ անեք AdGuard-ը կոնտեյներում՝ իր սեփական namespace-ով, և ընտրված աղբյուրը կարող է տարբերվել այն բանից, ինչը հարցրեց հաճախորդը։

ss -lunp | grep :53ցույց է տալիս, թե ո՞ր խաղում եք գտնվում։0.0.0.0:53-ի վրա լսողը wildcard դեպքն է;10.6.0.1:53-ի վրա լսողը արդեն հաստատել է պատասխանը։ Սոկետի ընթերցումը ավելի արագ է, քան YAML-ի ընթերցումը, և այն արտացոլում է, թե ինչն է իրականում աշխատում, ոչ թե թե ինչն է վերջին անգամ պահպանվել։

Ի՞նչ է իրականում վերահսկում bind_hosts

AdGuard Home-իdns.bind_hostsը տեղական հասցեների ցուցակն է, որը օգտագործում է DNS լսարանը: Առաքված լռելյայնը բազմակողմանի նշանն է, ինչը նշանակում է ընդունել բոլոր տեղական հասցեներով և թողնել կորնելը ընտրի աղբյուրը ամեն պատասխանի համար: Բազմակողմանի նշանը փոխարինելով այն հասցեով, որի վրա հարցում են հաճախորդները, փոխվում է սոկետը, և դրա հետ հանդերձ յուրաքանչյուր պատասխանում աղբյուրի հասցեն:

Ցուցակը կարող է ունենալ մի քանի գրառում, ինչը կարևոր է լուծիչի համար, որը ծառայում է երկու ցանցերի: Ցուցակագրելով10.6.0.1և192.168.1.10ստացվում են երկու կապված սոկետներ, և հարցումը, որը գալիս է ցանկացած մեկի վրա, պատասխանում են այն հասցեից, որի վրա այն հասել է: Սա այն վարքագիծն է, որը շատերը ենթադրում են, որ բազմակողմանի նշանը արդեն ապահովում է:

YAML-ը պարզ է, և այն հասցեն, որը նշված է դրա մեջ, այն է, որը ձեր թունելի հաճախորդներին տեղեկացրել են օգտագործել, ոչ թե հյուրընկալողի հիմնական հասցեն:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Ինչու մեկ լուծիչի երկու տեղադրումներն համաձայն չեն

Plugin-կառավարվող, այս համատեքստում, նշանակում է, որ լուծարիչը կարող է տեղադրվել և ղեկավարվել է մեկ այլ փաթեթի կողմից՝ ռաութերի ֆիրմայի փաթեթ, NAS փաթեթ կամ տնային ավտոմատացման լրացում։ Նույն փաթեթը սովորաբար ուղարկում է AdGuard Home-ի YAML-ի իր սեփական պատճենը և սկսում գործընթացը իր ժամանակացույցով, մինչդեռ առանձին օրինակն այն է, որ վաճառողը տրամադրում է բինար կամ կոնտեյներ, որը դուք ինքներդ եք կարգավորում։ Ամեն դեպքում, դուք դիտարկում եք երկու անկախ գործընթացներ՝ առանձին կազմաձևային ֆայլերով և առանձին կապման ընտրությամբ, նույնիսկ այն դեպքում, երբ երկուսն էլ կարդում են նույն upstream ցուցակը և նույն ֆիլտրների ցուցակները։ Մեկը կարող է կապվել կոնկրետ թունելի հասցեին, մինչդեռ մյուսը ժառանգում է wildcard-ը, և վեբ ինտերֆեյսը երկու կողմից էլ նույնն է թվում։

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

Փաթաթեք այն, այնուհետև թեստ արեք թունելի կողմից

Փոխեքbind_hostsթունելի հասցեով, վերագործարկեք ծառայությունը, և հաստատեք, որ Socket-ը տեղափոխվել է՝ss -lunp | grep :53այժմ պետք է ցույց տա10.6.0.1:53և չկառուցված (wildcard) գրանցում չկա։ Եթե այն դեռ ցույց է տալիս0.0.0.0,ընթացիկ պրոցեսը չի կարդում այն ֆայլը, որը խմբագրել եք։

Այնուհետև թեստ արեք հաճախորդի կողմից, քանի որ միայն այն կողմն է, որը կարևոր է։ Հարցումdig @10.6.0.1 example.comօգտագործում է այն ուղին, որով օգտվողը գործում է, և հաղորդումը հոստում capture-ի միջոցով ցույց է տալիսtcpdump -ni wg0 udp port 53ցույց է տալիս պատասխանողի աղբյուրի հասցեն կալվածքի վրա: Համեմատեք այն հաճախորդի լուծչի կարգաբերման հասցեի հետ; երբ դրանք հավասար են, ժամանակի ավարտը դադարում է լինել գաղտնիություն:

ip route get 10.6.0.2բացատրում է մնացած տարօրինակությունը, որովհետև այն տպում է ինտերֆեյսը և աղբյուրը, որը հոստը վերադարձնում է հաճախորդին: Եթե այդ ելքի մեջ նշված է LAN ինտերֆեյսը, սահմանամանի փոփոխությունը ամբողջական լուծումը չէ, և հաջորդ բանն ուղիների աղյուսակն է, որը պետք է կարդալ:

այն, ինչ սահմանումների փոփոխությունը չի կարող լուծել

Նմուշելու լսողի (listener) ամրացումը չի վերականգնում մուտքի ցուցակը, որը բացառել է թունելի ենթակենսը, ֆայրքալի կանոնը, որ թույլ է տալիս հարցումը բայց ոչ պատասխանը, կամ բացակա ուղինը դեպի WireGuard պուլը: Դրանք ձախողվում են աղբյուրի հասցեից ավելի շուտ կամ ավելի ուշ, և յուրաքանչյուրը ունի տարբեր տեր:

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