OpenVPN-ի DNS դարպասում՝ dnsmasq և ֆայրվոլի շրջանակը

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

Լսողը երկու ուղղություն ունեցող տեղական ծառայություն է

Ներս մտնող ուղղությամբ հաճախորդը հարցում է ուղարկում դարպասի թունելի հասցեին 53 պորտում։ Դուրս եկող ուղղությամբ դեմոնը փոխանցում է այդ հարցումը իր կարգավորված վերին հոսքի սերվերին։ Երկու կեսերն էլ պետք է աշխատեն, և նրանք ձախողվում են տարբեր ձևերով։

Հաճախորդի հաղորդած ժամանակի սպառումը և դարպասում երևացող ժամանակի սպառումը նույն խափանումը չեն։

Կապեք թունելի հասցեն, ոչ թե բոլոր հասցեները

Այս աշխատանքի համար նախատեսված dnsmasq պատճենին անհրաժեշտ է հստակ լսելու հասցե, կապման ռեժիմ, որը հանդուրժում է թունելի հայտնվելը մեկնարկից հետո, և մեկ հստակ վերին հոսք։ Սա ամենափոքր տարբերակն է, որ օգտագործում եմ՝

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic կապում է առանձին հասցեները և հաղթահարում, երբ tun0 ավելի ուշ է հայտնվում, ինչը կարևոր է այն հոսթում, որտեղ VPN ծառայությունը վերագործարկվում է։ loopback-ը թվարկելը տեղական գործիքները աշխատունակ է պահում՝ առանց հանրային լսող ավելացնելու։ no-resolv խանգարում է դեմոնին ժառանգել վերին հոսքերը հոսթի լուծիչի կարգավորումից, և no-hosts խանգարում է այս պատճենին հրապարակել դարպասի hosts ֆայլը։ Այս տարբերակներից ոչ մեկը ոչ մեկին թույլտվություն չի տալիս հարցումներ անել ծառայությանը։

Ստուգեք, արդյոք կա արդեն գոյություն ունեցող լսող 53 պորտում նախքան երկրորդ դեմոնը գործարկելը, և օգտագործեք տարածման կարգավորումների սեփականատիրոջը՝ սխալ պանակում թափառող ֆայլի փոխարեն։

Թույլատրեք DNS մուտքը, ոչ թե թունելի տարանցումը

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS-ը աշխատում է TCP-ով ինչպես նաև UDP-ով, ուստի միայն UDP-ի կանոնը մեծ պատասխանները թողնում է ձախողված այնպիսի ձևով, որը ընդհատվող է թվում։ Սրանք ufw route թույլտվություններ չեն, և չպետք է դառնան լայն թույլտվություն tun0-ի վրա։ Հերթականությունը նույնքան կարևոր է, որքան բովանդակությունը. ավելի վաղ կանոնը, որը մերժում է ամբողջ մուտքը tun0-ից, այնուամենայնիվ հաղթում է, և վերջնական մերժումից ներքև թույլտվություն ավելացնելը ոչինչ չի ստեղծում։

Եթե դարպասի DNS-ը հիմա դիզայնի մաս է, ապա վերանայեք այդ վաղ քաղաքականությունը դիտավորյալ և գրանցեք ինչու։

Վերին հոսքի կեսը առանձին ուղի է

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

Մի ավելացրեք անսահմանափակ թունելի ելք, որպեսզի պատասխանները աշխատեն. հետևվող պատասխաններին դա պետք չէ։

Հրեք տարբերակը, ապա ստուգեք հանձնումը

Սերվերը կարող է լուծիչը հայտարարել հաճախորդներին հրված տարբերակով։ Սա տարբերակ է, ոչ թե հրահանգ, որին օպերացիոն համակարգը պարտավոր է ենթարկվել՝

push "dhcp-option DNS 10.90.0.1"

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

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

Փորձարկեք այն, ինչ իրականում կառուցել եք

Հարցրեք մեկ մասնավոր լիարժեք որակավորված անուն և մեկ թույլատրված արտաքին անուն ուղիղ թունելի հասցեին՝ UDP-ով և TCP-ով։ Այնուհետև կրկնեք հավելվածի սովորական որոնման ուղիով։

Եթե ուղիղ հարցումները աշխատում են, իսկ հավելվածը դեռ ձախողվում է, խափանումը հանձնման մեջ է, ոչ թե սերվերում՝

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

Ավարտեք հաստատելով, որ հաստատված VPN ուղուց դուրս գտնվող աղբյուրը բոլորովին չի կարող օգտագործել լսողը։ Հաջող լուծումը չի լիազորում վերադարձված հասցեն, ուստի այս երկու հարցերը առանձին պահեք։