WireGuard DNS DNAT: պահեք պատասխանի ուղին աշխատունակ

WireGuard-ի հաճախորդի DNS հարցումը այլ resolver-ին ուղղելը նման է մեկ կանոնի, բայց իրեն պահում է որպես երեք որոշում։ Նշանակվածը պետք է վերաշարադրվի, փաթեթը պետք է փոխանցվի, և պատասխանը պետք է գտնի իր ճանապարհը հետ՝ դարպասի ստեղծած թարգմանության վիճակի միջով։ Բաց թողեք երրորդը, և հարցումը հանգիստ դուրս կգա, մինչ հաճախորդը հավերժ սպասում է։

Վերցրեք 10.77.0.0/24-ում լիազորված հաճախորդների օրինակը, որոնք գալիս են wg0-ով, հարցնում են հայտարարված 10.77.0.1 հասցեն և կարիք ունեն resolver-ի 203.0.113.53-ում։ Վերին հասցեն փաստաթղթավորման տեղապահ է, ոչ թե աշխատող ծառայություն։

Հարցման վերահասցեավորումը փոխում է միայն դրա նշանակվածը

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

DNS-ի երկու տրանսպորտներն էլ պահանջում են համապատասխան կանոններ, որովհետև հաճախորդը վերադառնում է TCP-ին, երբ պատասխանը կտրվում է։

Ստորև կանոնները ընտրում են մեկ ներգնա ինտերֆեյս, մեկ հաճախորդի տիրույթ և մեկ սկզբնական նշանակված հասցե։ Դարպասի վրա ուրիշ ոչինչ չի ազդվում, և դարպասի սեփական հարցումը բոլորովին չի համընկնում։

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Պատասխանի ուղին առանձին որոշում է

Երկու դասավորություն թույլ են տալիս պատասխանին վերադառնալ, և մեկը վաղ ընտրելը խնայում է կարգաբերման մեկ նստաշրջան։ Կա՛մ վերին resolver-ն ունի հետադարձ երթուղի դեպի 10.77.0.0/24 այս դարպասով, կա՛մ դարպասը ելքի վրա թարգմանում է աղբյուրը, որպեսզի պատասխանը հասնի այն հասցեին, որը վերինը արդեն գիտի։ Երկուսն էլ աշխատում են։ Միայն մեկն է համապատասխանում վերինի վրա ձեր ունեցած վերահսկողությանը։

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

Սահմանափակեք այդ թարգմանությունը նույնքան խստորեն, որքան վերահասցեավորումը, այլապես կանոնը կդառնա ընդհանուր նշանակության NAT այն ամենի համար, ինչը պատահաբար համընկնում է դրա հետ։

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

Գրեք կանոնները ավելի նեղ, քան երևում է առաջադրանքը

Փոխանցման թույլտվությունը նույն շրջանակին է պատկանում։ Թույլատրեք հաճախորդից resolver հոսքը և վերադարձի երթևեկությունը, որը conntrack-ն արդեն ճանաչում է, փոխարենը մեքենայի վրա ամեն DNAT կապ ընդունելու։ Համապարփակ ընդունումը նաև լիազորում է պորտերի փոխանցումներ, որոնք կապ չունեն DNS-ի հետ։

Դարպասի սեփական resolver-ը այլ կոդի ուղի է։ Տեղում թողարկված հարցումն անցնում է OUTPUT-ով, ուստի դարպասի shell-ից փորձարկելը չի վարժեցնում ո՛չ PREROUTING կանոնը, ո՛չ փոխանցման քաղաքականությունը։ Այդ պատճառով տեղական փորձարկումը կարող է անցնել, մինչ յուրաքանչյուր հաճախորդ ձախողվում է, և հակառակը նույնքան սովորական է։

Այստեղ ոչինչ չի ծածկում DNS-ը HTTPS-ի վրայով 443 պորտում կամ DNS-ը TLS-ի վրայով 853 պորտում, և ոչինչ չի ծածկում IPv6-ը։ IPv6 resolver-ով կարգավորված հաճախորդը ուրախությամբ կանտեսի ամբողջ դասավորությունը։

Ինչ է ապացուցում թարմ հարցումը

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

Նախքան որևէ բան վերահասցեավորելը հաստատեք, որ resolver-ը գիտի այն անունները, որոնք դուք սպասում եք։ Փոխարինիչ, որը պատասխանում է հանրային անուններին, բայց ոչ ձեր մասնավոր գոտուն-ը աշխատող որոնումը վերածում է NXDOMAIN-ի, որը նման է կոտրված թունելի։ Փորձարկեք resolver-ը ուղղակիորեն, դարպասից, նախքան հաճախորդի ուղին կներգրավվի։ Իսկ iptables ընդլայնումների տեղեկագիրք-ը փաստագրում է DNAT-ի և masquerade-ի իմաստաբանությունը, որոնց վրա հիմնված են այս կանոնները։