Արդյո՞ք ձեր VPN-ի DNS-ն իսկապես օգտագործվում է. բռնեք 53-րդ պորտը և տեսեք

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

Մղված ընտրանքը հարցում չէ

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

Անսարքությունների որոնման մեծ մասը միավորում է այդ երեքը մեկի մեջ և մեղադրում VPN սերվերին, որը սովորաբար միակ կողմն է, որն ի վիճակի է ապացուցել, թե կատարել է իր բաժինը։ Փոխարենը կարդացեք հաճախորդի լուծիչի իրական վիճակը, ապա դիտեք մեկ հարցման ելքը։ Այդ երկու դիտարկումները բաժանում են կոնֆիգուրացիան երթուղավորումից և քաղաքականությունից, և արժեն մոտ հինգ րոպե։ Պահպանեք գրառումները, որովհետև հաջորդ ինժեները ցանկանում է «առաջ» և «հետո», այլ ոչ դրանց նկարագրությունը։

Ստուգեք, թե ինչ է իրականում պահում ինտերֆեյսը

Linux-ում համակարգի լուծիչը կարող է լինել սովորական ֆայլը, NetworkManager-ը կամ systemd-resolved-ը, և թե դրանցից ով է տիրապետում, որոշում է, թե որտեղ կհանգչի մղված սերվերը։ Հրամանի տողի OpenVPN գործընթացն ինքնուրույն չի թարմացնում համակարգի լուծիչը, ուստի փաստաթղթավորված ինտեգրումը up/down սկրիպտ է կամ միացումների կառավարիչ, որն արդեն գիտի ինչպես կիրառել կարգավորումները։ Երկուսը միասին գործարկելը մրցավազք ստեղծելու արդյունավետ միջոց է։

resolvectl status
cat /etc/resolv.conf

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

Հետևեք մեկ հարցման մեքենայից դուրս

Միաժամանակ բռնեք երկու ինտերֆեյսերը, ապա լուծեք մեկ անուն, որը պետք է օգտագործի ներքին լուծիչը։ Այդ զույգ գրառումը պատասխանում է այն, ինչին ոչ մի կոնֆիգուրացիոն արդյունք չի կարող։

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

Այն հրշեջ պատը, որն ընդունում է միայն իր DNS-ը

Առևտրային հաճախորդները երբեմն տեղադրում են իրենց զտիչ շղթաները։ Մեկ փաստաթղթավորված ձև թույլ է տալիս DNS դեպի հաճախորդի սեփական լուծիչը և դեն է նետում մնացած ամբողջ UDP երթևեկությունը 53-րդ պորտում, որ փորձում է լքել ոչ loopback ինտերֆեյսը, ներառյալ այն երթևեկությունը, որ օգտատերը միտումնավոր այլ տեղ է ուղղել։ Դեմոնի հարցումներն անհետանում են առանց հետքի, ինչը կարդացվում է որպես լուծիչի խափանում, այլ ոչ զտիչ։

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

Ինչու արտահոսքի էջն ավելի քիչ է ապացուցում, քան թվում է

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

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