Ինչու է DNS-ը դադարում աշխատել Windows-ում OpenVPN-ի միացումից հետո

Ping-ը դեպի գրասենյակի լուծիչը դեռ պատասխան է ստանում "OpenVPN"-ի միանալուց հետո, և այնուամենայնիվ յուրաքանչյուր անվան որոնում ձախողվում է։ Հասցեն հասանելի է, իսկ պորտը՝ ոչ, համակցություն, որը իմաստ ունի, երբ գիտեք, որ Windows-ը կարող է զտել DNS-ը ըստ ադապտերի։ Քանի որ պրոֆիլում block-outside-dns կա, այդ զտիչն առաջին կասկածյալն է, և երթուղիների աղյուսակը փնտրելու սխալ տեղն է։ Ստորև երկու թեստերը շերտերը բաժանում են վայրկյանների ընթացքում։

Հասանելի հասցե, մեռած պորտ

Հաջող ping-ը ապացուցում է, որ հոսթը աշխատում է և ուղի գոյություն ունի։ Այն ոչինչ չի ասում 53 պորտին հասնելու թույլտվության մասին, քանի որ խնդրո առարկա զտիչն աշխատում է այլ շերտում և կախված է ադապտերից։ Դրա համար է, որ նույն մեքենան կարող է պատասխանել ICMP-ին և մերժել նույն հասցեին ուղարկված յուրաքանչյուր հարցում։ Երկու թեստերն էլ գործարկեք նույն նստաշրջանում՝ նախքան որևէ կարգավորում փոխելը։

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

Այս ընտրանքը զտման հարթակի կանոն է

OpenVPN-ի տեղեկատուն block-outside-dns-ը նկարագրում է որպես Windows Filtering Platform-ի սահմանափակում, որը խանգարում է հավելվածներին հասնել DNS-ին թունելից դուրս գտնվող ադապտերներում։ Այն ընդգրկում է TCP և UDP 53 պորտը։ Քանի որ զտիչը ապրում է WFP-ում, այլ ոչ թե հրամուրի սովորական կանոնների ցանկում, այլ տեղ թույլատրող կանոն ավելացնելը պարտադիր չէ, որ փոխի արդյունքը։ Այդ պատճառով DNS-ը թույլատրելու սովորական խորհուրդը շարունակում է ձախողվել։

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

Փնտրեք այն հաճախորդային բաղադրիչը, որին պատկանում է սահմանափակումը, այլ ոչ թե ավելացրեք նոր կանոններ։ Տերը հենց այն բանն է, որը կարող է իրականում հեռացնել այն։

Զտիչը լուծիչ չէ

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

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

1. Օգտագործվող լուծիչ՝ համեմատեք Resolve-DnsName -Server <resolver-ip> <name>-ը ipconfig /all-ի թվարկած DNS սերվերների հետ։
2. VPN-ի DNS կիրառված է՝ ստուգեք թունելի ադապտերի DNS գրառումները նույն ipconfig /all ելքում։
3. Օգտագործվող ինտերֆեյսը՝ Find-NetRoute -RemoteIPAddress <resolver-ip>-ը նշում է այդ նպատակակետի ելքային ինտերֆեյսը։

LAN լուծիչը այս քաղաքականության ներքո դառնում է անհասանելի ըստ նախագծի, նույնիսկ երբ այլ LAN երթևեկություն է աշխատում։ Սա այն ընտրանքն է, որ կատարում է իր գործը։ Եթե նախագծին VPN DNS է պետք, ուղղեք լուծիչի գրանցումը և թունելի ուղին, իսկ եթե տեղական բացառություններով split DNS է պահանջվում՝ կոնֆիգուրացիայի տերը պետք է այդ բացառությունները արտահայտի աջակցվող եղանակով։

Ինչ այս ընտրանքը չի ընդգրկում

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

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

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

Ստուգեք վիճակը անջատումից առաջ և հետո

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

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

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