Ինչու OpenVPN-ի երթուղու հրահանգում wildcard-ը չի կարող աշխատել

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

Ինչ է տեղադրում երթուղին, և ինչ նա երբեք չի կարդում

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

OpenVPN-ը որոշ երթուղու պարամետրերում կարող է ընդունել լուծելի անուն, և այդ հանդուրժողականությունը շփոթության աղբյուր է։ Անունը լուծվում է կոնֆիգուրացիան կիրառելիս՝ ստեղծելով մեկ կամ մի քանի հասցեներ, որոնք դառնում են սովորական երթուղիներ։ Դրանից հետո անունը լիովին անհետանում է պատկերից։

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

Երբ նպատակակետն իսկապես նախածանց է

Եթե թիրախը հայտնի մասնավոր ցանց է, գրեք նախածանցը։ Փաստաթղթային տարածությունից օրինակի համար մեկ հոսթը և մեկ ենթացանցը այսպիսի տեսք ունեն՝

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

Մեկ DNS պատասխանից մեծ նախածանց մի՛ ենթադրեք։ Մեկ հասցեի լուծվող մեկ հոսթի անունը ձեզ ոչինչ չի ասում դրա հետևում գտնվող ցանցի չափի մասին, և գուշակված նախածանցը հենց այն ձևն է, որով թունելը ի վերջո որսում է երթևեկություն, որը ոչ ոք չէր նախատեսում դրա միջով ուղարկել։ Փոխարենը որոնումից եզրակացնելու՝ հարցրեք ցանցի տիրոջը փաստացի նախածանցի մասին։

Երբ աշխատանքի միավորը հոսթի անուն է

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Ճշգրիտ անվան համեմատությունը ընդգրկում է հենց տիրույթը, իսկ վերջածանցի համեմատությունն ընդգրկում է նրա զավակներին՝ չհամընկնելով այն անվան հետ, որն ուղղակի ավարտվում է նման նշաններով։ Երկուսն էլ անհրաժեշտ են, և մեկը բաց թողնելը ստեղծում է կանոն, որը ճիշտ է թվում և բաց է թողնում գագաթը կամ խաբեբային։

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

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

Ծրագրերը, որոնք անտեսում են բրաուզերի պրոքսիի կոնֆիգուրացիան, այս ամենից չեն տուժի։ Հրամանի տողի գործիքները, թարմացնողները և սեփական ցանցային կույտ ունեցող հավելվածները վերցնում են երթուղիների աղյուսակը, ոչ թե PAC ֆայլը, ուստի այդ դեպքերին անհրաժեշտ է աջակցվող մեխանիզմ յուրաքանչյուր հավելվածի համար կամ այլ ձևավորում։ Նախքան խոստանալը, որ բրաուզերի կանոնը ընդգրկում է աշխատանքային հոսքը, գույքագրեք կարևոր հաճախորդներին։

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

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

Փորձարկել երկու ուղիները, ոչ միայն երջանիկը

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

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