DNS-ը չի լուծվում, երբ VPN-ի kill switch-ը արգելափակում է 53 պորտը
Kill switch-ը կարող է դիտավորյալ արգելափակել DNS-ը։ Համեմատեք միայն թունելի ներսում լուծումը տեղական resolver-ի բացառության հետ, ապա պարզեք, թե որ շերտն է իրականում ձախողվել։
Երբ kill switch-ը գցում է թունելը, այն իր հետ տանում է նաև DNS-ի ուղին, և մնացած resolver-ը հազվադեպ է այն, ինչ դուք սպասում եք։ Երկու ձևավորում այդ պահին շատ տարբեր կերպ են մոտենում՝ արգելափակել յուրաքանչյուր DNS փաթեթ, որը թունելի ներսում չէ, կամթողնել մեկ resolver՝ որպես բացառություն։ Երկուսն էլ պաշտպանելի են։ Բրաուզերի ներդիրից ախտանիշները գրեթե նույնն են երևում, ուստի առաջին խնդիրն է պարզել, թե որ ձևավորումն եք իրականում տեղակայել։
Այդ տարբերությունը պահում եմ աչքի առաջ, որովհետև ուղղումը յուրաքանչյուր դեպքում հակառակ է։ Մեկ ձևավորման ավելի լայն բացառություն է պետք, մյուսին՝ ավելի նեղ։ Գուշակելը ձեզ արժենում է կամ գաղտնիություն, կամ կես օր։
Երկու DNS ձևավորում նույն խափանման համար
Ձևավորում A-ն resolver-ին վերաբերվում է որպես թունելի հետևում գտնվող սովորական ծառայության։ Firewall-ի կանոնները թույլ են տալիս UDP և TCP 53 միայն թունելի ինտերֆեյսում, և հաճախորդին տրվող հասցեն թունելի ներսում գտնվող resolver է։ Երբ թունելը ընկնում է, որոնումները դադարում են, և դա նախատեսված արդյունքն է, ոչ թե խափանում։
Ձևավորում B-ն resolver-ը հասանելի է պահում տեղական ցանցում՝ սովորաբար 192.168.1.1 հասցեով երթուղիչը կամ 127.0.0.53 հասցեով օպերացիոն համակարգի stub-ը, այն պատճառաբանությամբ, որ անունների լուծումը չպետք է մահանա թունելի հետ։ Դա հարմար է տնային LAN-ում, որտեղ երթուղիչը լուծում է ամբողջ տան համար։ Հյուրանոցի կամ օդանավակայանի Wi-Fi-ում նույն բացառությունը մատնանշում է ուրիշի սերվերը, և ձեր մուտքագրած յուրաքանչյուր անուն բացահայտվում է, թեև ձեր վեբ երթևեկությունը մնում է արգելափակված։
Սահմանն այն է, թե ումն է resolver-ը։ Եթե վստահում եք տեղականին, բացառությունը փոքր ու ազնիվ անցք է։ Եթե ոչ, ապա միայն թունելով ձևավորումն է միակը, որ դիմանում է, և գինը այն է, որ ընկած թունելը տանում է բոլոր անունները։
Ինչու VPN հաճախորդի սեփական որոնումը դեռ աշխատում է
Հաճախորդը պետք է լուծի դարպասի հոսթի անունը նախքան թունելի գոյությունը, ուստի խիստ արգելքը չպետք է ծածկի հաճախորդի բեռնարկման ուղին։ Հաճախորդների մեծ մասը կամ քեշավորում է վերջնակետի հասցեն, կամ տալիս է փաստաթղթավորված բեռնարկման բացառություն հենց այդ մեկ հոսթի համար։ Եթե ձեր կանոնների հավաքածուն արգելափակում է այդ որոնումը, թունելը երբեք չի վերադառնա, և մատյանները ցույց կտան հաճախորդ, որը չի հասնում իր իսկ սերվերին. սա քաղաքականության թերություն է, ոչ DNS-ի։
Բաժանված DNS-ը երկրորդ տեղն է, որտեղ սա ի հայտ է գալիս։ Հաճախորդը ներքին գոտին հրում է մասնավոր resolver-ին և մնացած ամեն ինչ թողնում համակարգի resolver-ին։ Ընկնելուց հետո հանրային անունները կարող են դեռ լուծվել, մինչ ներքինները ժամկետանց են լինում, որովհետև մասնավոր գոտին այլևս ուղի չունի։ Օգտատիրոջ համար դա «VPN-ը կոտրեց ինտերնետը» է. resolver-ի մատյանի համար դա հարցում է, որը երբեք չհասավ։
systemd-resolved-ի ներքո կարող եք բաժանումը տեսնել ուղղակիորեն։resolvectl statusթվարկում է յուրաքանչյուր կապի DNS սերվերները և երթուղման դոմենները, և թունելի անկումից հետո ներքին դոմենը շարունակում է մատնանշել սերվերի, որը գտնվում է այլևս գոյություն չունեցող կապի վրա։ 127.0.0.53-ի stub-ը դեռ ընդունում է հարցումը, ապա սպասում է վերին հոսքին, որը չի պատասխանի, և դրա համար էլ խափանումը տևում է վայրկյաններ՝ անմիջապես վերադառնալու փոխարեն։
Գաղտնագրված DNS-ը չի շրջանցում փաթեթային ֆիլտրը
DNS over HTTPS-ը և DNS over TLS-ը ճամփորդում են 443 և 853 պորտերով, ուստի 53 պորտն արգելափակող կանոնը նրանց մասին ոչինչ չի ասել։ «DNS»-ը պորտով արգելափակելը պորտի մասին քաղաքականություն է, ոչ անունների լուծման։ Եթե ձեր kill switch-ը արգելափակում է թունելից դուրս ամբողջ երթևեկությունը, DoH-ը պատահաբար ծածկվում է։ Եթե captive portal-ի կամ հանրային resolver-ի համար թույլտվություն եք առանձնացրել, ապա ոչ։
Հաճախորդի կողմի կառավարումը ավելի էժան լծակն է։ Firefox-ը թողնում է իր DoH resolver-ը, երբ դեղձանիկ անունըuse-application-dns.netչի լուծվում, և դրա համար էլ կառավարվող ցանցերը հրապարակում են այդ դոմենը որպես NXDOMAIN. ձեռնարկության քաղաքականությունը կարող է նաև ամրացնել այն անջատված։ Android Private DNS-ը և Chrome-ի անվտանգ DNS-ը ունեն իրենց անջատիչներն ու իրենց լռելյայնները։ Դրանք անջատելը ավելի հուսալի է, քան resolver-ի հասցեների հետևից ընկնելը, որովհետև հասցեների ցանկը փոխվում է, իսկ ձեր կանոնների հավաքածուն՝ ոչ։
Սրա մի տարբերակ կա, որն ընդհանրապես արտահոսքի մասին չէ։ Ամրացված resolver ունեցող հավելվածը դեռ ցանցային ուղի է պետք այնտեղ հասնելու համար։ Գաղտնագրումը փոխում է, թե ով կարող է կարդալ հարցումը, ոչ թե՝ կարող է փաթեթը թողնել մեքենան, ուստի ամբողջ սարքի արգելքը հաղթում է կարգավորումը՝ չդիպչելով դրան։
Համապատասխանեցրեք ախտանիշը շերտին
Հաշվետվությունների մեծ մասը հասնում է մեկ նախադասությամբ, և այդ նախադասությունը սովորաբար արդեն անվանում է շերտը։ Ստորև բերված աղյուսակն այն է, ինչ ես անցնում եմ մինչև որևէ կանոնի դիպչելը. նպատակն է որոշել՝ հարցումը արգելափակվե՞լ է, սխալ ուղղվե՞լ, թե՞ ընդհանրապես չի ուղարկվել։
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Առաջին երկու տողերն են, որ մարդիկ սխալ են ախտորոշում։ Լուռ անկումը և մերժումը բրաուզերում նույն տեսքն ունեն՝ «DNS-ը կոտրված է», բայց դրանցից միայն մեկն է նշանակում, որ ձեր kill switch-ը կատարում է իր աշխատանքը։ Մերժումը նշանակում է, որ ինչ-որ բան պատասխանել է, ուստի արգելքը այն տեղում չէ, որտեղ դուք կարծում եք։
Վերականգնեք resolver-ի քաղաքականությունը, ապա ապացուցեք այն
Ուղղեք ձևավորումը, ոչ ախտանիշը։ Միայն թունելով լուծման համար թույլ տվեք 53-ը թունելի ինտերֆեյսում, հրեք ներքին resolver-ը թունելի կոնֆիգուրացիայի հետ և թողեք ֆիզիկական կապը առանց DNS-ի թույլտվության։ wg-quick-ում տողըDNS =է, որը գրում է resolver-ը ինտերֆեյսի կոնֆիգուրացիայի մեջ, ուստի այն բաց թողնող թունելը հին resolver-ը թողնում է տեղում, և յուրաքանչյուր հարցում սխալ ուղու վրա է։wg-quick ձեռնարկըփաստաթղթավորում է այդ վարքը յուրաքանչյուր հարթակի համար։
Ապա ստուգեք այս հերթականությամբ։ Linux-ումresolvectl statusցույց է տալիս ակտիվ կապը,dig +short example.comստուգում է հանրային անուն,dig @10.8.0.1 internal.example.comստուգում է մասնավորը, ևsudo tcpdump -ni any port 53ցույց է տալիս, թե որ ինտերֆեյսն են օգտագործում փաթեթները, մինչ դուք երկուսն էլ գործարկում եք։ Windows-ումGet-DnsClientServerAddress -AddressFamily IPv4ևResolve-DnsName example.comտալիս են նույն երկու փաստը՝ ով է կարգավորված, և ով է պատասխանում։
Ավարտեք բացասական թեստով։ Անջատեք թունելը, հաստատեք, որ թարմ հանրային անունը ձախողվում է, հաստատեք, որ մասնավոր անունը ձախողվում է, ևհաստատեք, որ ոչ մի 53 պորտի փաթեթ չի լքել ֆիզիկական ադապտերը։ Արգելքը, որը դիմանում է միայն քեշավորված պատասխանների համար, ընդհանրապես չի դիմանում։
Ստուգաթերթ՝ տոմսը փակելուց առաջ.
- Խափանման ընթացքում օգտագործված resolver-ն այն է, ինչ նախատեսում է քաղաքականությունը։
- Հաճախորդի սեփական վերջնակետի որոնումը դեռ թույլատրված է՝ քեշով կամ բացառությամբ։
- DoH-ը և DoT-ը կա՛մ ծածկված են արգելքով, կա՛մ անջատված են քաղաքականությամբ։
- Մասնավոր գոտիները ձախողվում են փակ, ոչ բաց, հենց թունելը վերանում է։