Ինչու են dnsmasq-ի հարցումները դուրս գալիս VPN-ից DNS վերահասցեավորումից հետո

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

Նշանը չի ճամփորդում հարցման հետ

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

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

Երկու զրույցներն իսկապես կիսում են մեկ անուն և մեկ ժամանակ, և դա է, որ դրանք նմանեցնում է մեկ հոսքի, երբ արագ նայում ես գրավմանը։

Որտեղ փոխանցումը դառնում է տեղական լուծում

Սկսեք պարզելով՝ 53 պորտը վերահասցեավորվու՞մ է, փոխարկվու՞մ է այլ հոսթի, թե՞ մնում է անձեռնմխելի, քանի որ երեք դեպքերն իրենց այլ կերպ են պահում։ Տեղական պորտի վերահասցեավորումը վերջ է դնում փոխանցմանը, մինչդեռ այլ մեքենայի փոխարկումը փաթեթը պահում է շարժման մեջ և հաճախորդի tuple-ը՝ իմաստալից։

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

Տվեք լուծիչին իր սեփական ելքի քաղաքականությունը

Տիրույթին հատուկ վերին հոսքը ամենամաքուր գործիքն է, երբ թունելը պետք է միայն որոշ անունների։ dnsmasq-ն ընդունում է տիրույթով սահմանափակված server տող՝ ըստ ցանկության ինտերֆեյսով կամ աղբյուրի հասցեով, որը հարցումը դուրս է տանում ընտրված սարքից։ Հենց այդ ուղղորդումն է, որ ստիպում է երկրորդ զրույցին հետևել VPN-ին։

server=/corp.example/10.30.0.53@tun_work
log-queries

Վերևում նշված տիրույթը, հասցեն և ինտերֆեյսը տեղապահներ են ձեր սեփական արժեքների համար։ Տիրույթի ընտրությունը և ելքի վերահսկումը մնում են առանձին որոշումներ. երթուղին պետք է գոյություն ունենա, աղբյուրի հասցեն պետք է թույլատրվի վերին լուծիչի կողմից, և firewall-ը պետք է թույլատրի պատասխանը։ Միայն ինտերֆեյսով ուղղորդումը fail-closed չէ, քանի որ անհետացած թունելը կարող է լուծիչին թողնել ընկնելու այլ ուղի։ Ցանկացած հանրային պահուստ հեռու պահեք այն անվանատարածքից, որը պետք է մնա մասնավոր։

Տողը դրեք այն կոնֆիգուրացիայի տիրոջ մեջ, որն աջակցում է երթուղիչը, ոչ թե ստեղծված ֆայլի մեջ, այլապես հաջորդ վերաբեռնումը կջնջի ուղղումը։

Ինչ չի կարող պահպանել ընդհանուր քեշը

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

Քեշավորված պատասխանը նույնպես ապացույց չէ նոր ուղու մասին։ Պատասխանը կարող է գալ հիշողությունից, մինչ վերին երթուղին մնում է կոտրված։

53 պորտի կանոնները ոչինչ չեն ասում այն հավելվածների մասին, որոնք DNS են խոսում HTTPS-ով կամ TLS-ով։ Այդ հարցումները երբեք չեն հասնում վերահասցեավորմանը, ուստի միայն 53 պորտի վրա կառուցված քաղաքականությունը նկարագրում է երթևեկության ենթաբազմություն և պետք է փաստաթղթավորվի որպես ենթաբազմություն։

Ստուգեք երկրորդ զրույցը, ոչ թե առաջինը

Փորձարկեք մի անունով, որը դուք եք վերահսկում, և դիտեք երկու կողմերը։ Հաճախորդի կողմի գրավումն ապացուցում է, որ հարցումը լքել է LAN-ը. միայն երթուղիչի կողմն է ապացուցում, թե ուր այն գնաց հետո։

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

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