Ձեր բաժանված թունելը հասնում է հավելվածին, բայց ոչ նրա DNS սերվերին
Բաժանված թունելը կարող է ուղղորդել հավելվածի ենթացանցը և միևնույն ժամանակ գցել կողքի լուծիչին։ Ավելացրեք հոսթի երթուղին, ապա ստուգեք, թե որ սերվերն է Windows-ը փաստացի ընտրում։
Հավելվածի ենթացանցի ուղղորդումը բաժանված թունելի ակնհայտ մասն է, և դա ամբողջ աշխատանքը չէ։ Լուծիչը հաճախ նստում է այն հավելվածից տարբեր հասցեում, որին ծառայում է, այնպես որ աշխատող թունելը կարող է որոնումը թողնել դրանից դուրս։ 10.80.0.0/16 կրող և ուրիշ ոչինչ չկրող պրոֆիլը 10.90.0.53-ի հարցումն ուղարկում է տեղական ինտերֆեյսով, որտեղ մասնավոր գոտի չկա։ Ավելացրեք լուծիչի ուղին, ապա նայեք խնդրի երկրորդ կեսին՝ թե որ սերվերն է հաճախորդը փաստացի ընտրում։
Առասպելը՝ մեկ երթուղին ծածկում է ողջ ծառայությունը
Բաժանված թունելը միացումով անցնող նպատակակետերի ցանկ է, ոչ թե ծառայության նկարագրություն։ Հավելվածի ենթացանցը և լուծիչի հասցեն երկու նպատակակետ են, և պրոֆիլը կարող է կրել մեկը առանց մյուսի։ Երբ դա տեղի է ունենում, հավելվածը հասանելի է հասցեով, մինչդեռ նրա անունը ձախողվում է, ինչը նման է DNS խափանման, ոչ թե ուղղորդման բացի։
Լուծիչի շուրջի ենթացանցը նույնպես ինքնաբերաբար ծածկված չէ։ Մեկ հասցեին ուղղված հոսթի երթուղին բավարար է այդ լուծիչի համար և չի բացում նրա հարևաններին։ Սա է հոսթի երթուղու իմաստը՝ նախագծով նեղ, և հեշտ մոռանալի, երբ հաջորդ ծառայությունը հայտնվում է նույն ենթացանցում։
Երեք բան պետք է ճիշտ լինի, որպեսզի որոնումը աշխատի՝ հաճախորդը լուծիչի հասցեն ուղղորդում է թունելով, դարպասը ընդունում և փոխանցում է այդ հարցումը, և լուծիչն ընդունում է ստացած աղբյուրը։ Պատասխանը նույնպես պետք է վերադառնա պայմանավորված ուղով։ Եթե դրանցից մեկը բացակայում է, ախտանիշը նույնն է, դրա համար արժե հասցեների աղյուսակը գրի առնել նախքան կարգավորումը ձեռք տալը։
Որոշեք, թե որ հասցեները պրոֆիլը պետք է կրի
Թվարկեք նպատակակետերը հերթականությամբ՝ հավելվածի ցանցը, լուծիչի հասցեն և հանրային վերջնակետը, որը վերջացնում է հենց թունելը։ Երրորդը երբեք չպետք է ուղղորդվի թունելի մեջ, քանի որ արտաքին միացմանը պետք է ուղի, որը գոյություն ունի թունելից առաջ։
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Ներառեք և UDP, և TCP DNS-ի համար, քանի որ ներդրումներից սպասվում է TCP-ի աջակցություն UDP-ի կողքին, և արգելափակված TCP ուղին տալիս է դանդաղ, մասնակի խափանումներ՝ մաքուրների փոխարեն։ Եթե մասնավոր գոտին սպասարկվում է նաև IPv6-ով, համարժեք հոսթ բացառությունն օգտագործում է IPv6 հասցե և նախածանց և առանձին գրառում է։
Գրի առեք, թե պրոֆիլն արդեն ինչ է ծածկում, նախքան ինչ-որ բան ավելացնելը։ Կրկնակի երթուղին անվնաս է, բայց անսպասելի գոյություն ունեցող երթուղին ասում է, որ պրոֆիլը նախագծվել է ձեզ տրվածից տարբեր հասցեների պլանի համար։
Ավելացրեք հոսթի երթուղին միացման սեփականատիրոջ միջոցով
Տեղականորեն կառավարվող բնիկ Windows պրոֆիլի համար երթուղին պատկանում է միացմանը, ոչ թե մեքենայի գլոբալ երթուղային աղյուսակին։ Նախ նախադիտեք ավելացումը, ապա կիրառեք այն նույն շրջանակով, որն օգտագործում է պրոֆիլը։
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Առաջին հրամանը նախադիտում է փոփոխությունը՝ ոչինչ չտեղադրելով, իսկ երկրորդը թվարկում է այն երթուղիները, որոնք պրոֆիլը ներկայումս կրում է։ Microsoft-ի Add-VpnConnectionRoute-ի տեղեկատուն փաստաթղթավորում է մեկ օգտագործողի և բոլոր օգտագործողների շրջանակները՝ բոլոր օգտագործողների պրոֆիլին պետք է իր շրջանակի պարամետրը, և մեկ օգտագործողի հրամանը բոլոր օգտագործողների պրոֆիլի դեմ ձախողվում է կամ հայտնվում սխալ տեղում։
Երբ պրոֆիլը կառավարվում է կամ գալիս է վաճառողի հաճախորդից, փոփոխությունը պատկանում է այդ սեփականատիրոջը։ Մշտական համակարգային երթուղին միացման քաղաքականության վրա դիզելը աշխատում է այնքան ժամանակ, քանի դեռ քաղաքականությունը կրկին չի կիրառվել, և երթուղին չի անհայտացել, ինչը սովորաբար տեղի է ունենում աջակցության զանգի ընթացքում, ոչ թե փորձարկման։ Այդ ձախողումը լուռ է․ երթուղին անհետանում է, անունը դադարում է լուծվել, և ոչ ոք չի կապում երկու իրադարձությունները։ Դրեք փոփոխությունը սեփականատիրոջ սեփական գրառման մեջ, որպեսզի հաջորդ վերակիրառումը այն կրի, ոչ թե ջնջի։
Կիրառելուց հետո նորից միացրեք պրոֆիլը՝ փոխարենը ենթադրելու, որ երթուղին ուժի մեջ է մտել։ Կենդանի միացման վրա երթուղու փոփոխությունները միշտ չէ, որ ընդունվում են, և վերամիացումը նաև վերարտադրում է այն վիճակը, ինչ ձեր օգտագործողները փաստացի կունենան։
Ստուգեք, թե որ լուծիչն է հաճախորդը փաստացի օգտագործել
Երթուղին կառավարում է լուծիչին հասցեագրված փաթեթները։ Այն չի որոշում, թե որ անունները պետք է ուղարկվեն այնտեղ, և այդ ընտրությունը առանձին մեխանիզմ է։ Windows-ում գործող անվանատարածքի կանոնները կարող են լուծիչ ընտրել ըստ տիրույթի, մինչդեռ պրոֆիլի DNS կարգավորումները տալիս են լռելյայն։ Այս երկու շերտերը կարող են չհամաձայնվել՝ առանց որևէ սխալի, դրա համար ուղիղ հարցումը միայն ապացույցի կեսն է։
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Առաջին հրամանը տպում է գործող անվանատարածքի քաղաքականությունը, իսկ երկրորդը մասնավոր լուծիչից ուղիղ հարցնում է հավելվածի անունը։ Ուղիղ պատասխանը ապացուցում է, որ ուղին և լուծիչը աշխատում են․ այն չի ապացուցում, որ հավելվածի սեփական որոնումն ընտրել է այդ սերվերը։ Համեմատեք այն նույն անվան սովորական որոնման և այն պատասխանի հետ, որը ստանում է հավելվածը։
Հաշվի առեք քեշերը և բրաուզերի մակարդակի անվտանգ DNS-ը, որը կարող է ամբողջությամբ շրջանցել համակարգի լուծիչը օգտագործողի մուտքագրած անունների համար։ Որոնման վերջածանցը ևս մեկ կեղծ հետք է․ այն կարճ անունը լայնացնում է լիարժեք որակավորված անվան, և կապ չունի, թե որ սերվերն է պատասխանում։
Ավարտեք՝ նորից միանալով և կրկնելով սովորական որոնումը, ապա հաստատեք, որ սովորական զննարկումը դեռ հետևում է իր հաստատված քաղաքականությանը։ Մասնավոր լուծիչը հանրայինով փոխարինելը, որպեսզի չկապված անուն լուծվի, ուղղում չէ, և այն լուռ տեղափոխում է մասնավոր հարցումները այնտեղ, ուր նրանք երբեք չպետք է գնային։