OpenVPN-ի pull-filter-ը համընկնում է նախատեսված երթուղուց ավելիին
pull-filter-ը ձեր տեքստը նախածանցի պես համեմատում է ուղարկված ընտրանքների հետ, ուստի route-ը բռնում է նաև route-gateway-ն ու route-ipv6-ը։ Նախ ստուգեք բայերը, ապա՝ երթուղիները։
Դուք մեկ տող եք ավելացնում՝ ձեր տեղական լռելյայն երթուղին պահելու համար, և դրանից հետո թունելն այլևս չի հասնում ներքին DNS սերվերին։ Այդ տողը pull-filter ignore "route" էր, ինչը չի նշանակում «անտեսիր այս երթուղին»։ Այն նշանակում է «դեն նետիր յուրաքանչյուր ուղարկված ընտրանք, որի տեքստը սկսվում է այդ հինգ տառերով», և սովորական սերվերի վրա դա ներառում է route-gateway, route-metric և route-ipv6 ընտրանքները՝ հենց երթուղիների հետ միասին։ Ստորև բերված ստուգաթերթն այն է, ինչ ես անցնում եմ մինչև մեկ այլ մարդու օգտագործելիք պրոֆիլին դիպչելը։
Զտիչը գործում է միայն ուղարկված ընտրանքների վրա
pull-filter-ը գործում է միայն այն ընտրանքային տողերի վրա, որոնք սերվերն ուղարկում է թունելի հաստատումից հետո, և ուրիշ ոչնչի վրա։ Ձեր տեղական ֆայլում գրված ընտրանքները դրանից չեն ազդվում, ինչպես նաև հավելվածների երթևեկությունը։ Եթե հույս ունեիք կանխել ինչ-որ պրոցեսի՝ թունելն օգտագործելը, ապա սա բոլորովին սխալ գործիք է, և զտիչների ոչ մի համադրություն դա չի անի։
Այդ ծավալը օգտակար է, որովհետև նշանակում է, որ կարող եք սերվերի կոնֆիգուրացիան անձեռնմխելի թողնել և միևնույնն է տեղում մերժել դրա մի մասը։ Սա նաև սահմանափակում է, որն արժե գրել տոմսի մեջ. զտիչը փոխում է այն, ինչ այս հաճախորդն է ընդունում, ոչ թե այն, ինչ սերվերն է առաջարկում։ Այն ոչ մի ազդեցություն չունի նույն պրոֆիլի այլ օգտագործողների վրա։ Այն չի պահպանվում նաև մեկ այլ հաճախորդի անցնելիս, որը չի իրականացնում ընտրանքը, ինչն արժե իմանալ դրա վրա աշխատանքային հոսք կառուցելուց առաջ։
Նախքան նախշը գրելը համոզվեք, թե սերվերն ինչ է իրականում ուղարկում։ Բարձր մանրամասնության դեպքում հաճախորդը տպում է ստացած ուղարկված ընտրանքների տողը, և դա ձեր համեմատած ճշգրիտ տեքստի միակ ազնիվ աղբյուրն է.
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnԿարդացեք ուղարկված տողը որպես ստորակետերով բաժանված ընտրանքների ցանկ, և նկատեք, որ ընտրանքների անուններն ու դրանց արգումենտները բաժանվում են բացատներով։ Ձեր զտիչի տեքստը համեմատվում է այդ հոսքի հետ, դրա համար էլ հաջորդ քայլում բացատներն այդքան կարևոր են։
Համընկնումը նախածանց է, ուստի բացատներն են ամբողջ խաղը
Համեմատությունը տողի նախածանց է, ոչ թե վերլուծված ընտրանքի անուն։ Ուստի "route"-ը համընկնում է route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 և route-metric 100 ընտրանքների հետ։ Վերջում մեկ բացատ ավելացնելը նեղացնում է այն հավանական ընտանիքին, որը նկատի ունեիք, իսկ ամբողջական նախածանցը՝ ավելի է նեղացնում կոնկրետ նպատակակետի։
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
Վերջին տողն այն է, որ մարդկանց բռնում է բաժանված թունելի աշխատանքի ժամանակ։ Սեփական լուծիչը պահելը օրինաչափ ընտրություն է, և դա նշանակում է, որ յուրաքանչյուր ներքին անուն այժմ կախված է լուծիչից, որը չի տեսնում մասնավոր գոտին։ Դա հետևանք է, որն ընդունվում է դիտավորությամբ, ոչ թե կողմնակի ազդեցություն, որը հայտնաբերվում է արտադրությունում։
Նախածանցով համընկնումը նաև նշանակում է, որ կանոնը կարող է հետագայում լուռ լայնանալ։ Երբ սերվերն ավելացնում է նոր ընտրանք, որը սկսվում է ձեր տեքստով, ձեր զտիչը սկսում է կիրառվել դրա վրա՝ առանց որևէ մեկի պրոֆիլը խմբագրելու։ Դա այն ձախողման եղանակն է, որի դեմ պետք է նախագծել, և մեղմացումը ընտրանքի հնարավորինս մեծ մասը համընկնելն է, ոչ թե հնարավորինս փոքրը։
Երեք բայ՝ երեք տարբեր արդյունքով
accept, ignore և reject նույն մտքի երեք ուղղագրություն չեն։ Դրանք տարբերվում են նրանով, թե հաճախորդն ինչ է անում համընկնման հետ, և նրանով, թե արդյոք որևէ մեկն իմանում է այդ մասին։
ignore լուռ դեն է նետում համընկնող ընտրանքը, ինչը ցանկալի է դիտավորությամբ փոխարինված կարգավորման համար։ reject դեն է նետում այն և ստիպում հաճախորդին բողոքել, ինչը ցանկալի է, երբ դրա բացակայությունը պետք է երևա մատյանում, այլ ոչ թե հայտնաբերվի ավելի ուշ։ accept դրական ձևն է, օգտագործվում է, երբ կառուցում եք թույլատրվածների ցանկ՝ առանձին ընտրանքներ հեռացնելու փոխարեն։
Ինչ բայ էլ օգտագործեք, զտիչները կիրառվում են իրենց հայտնվելու հերթականությամբ, ուստի երկու համընկնող կանոն տալիս են հերթականությունից կախված արդյունք, որը շատ դժվար է վերանայել։ Պահեք մեկ կանոն յուրաքանչյուր նպատակի համար և յուրաքանչյուրում դրեք ամենակոնկրետ տեքստը։ Եթե թույլատրվածների ցանկ է պետք, նախընտրեք մի քանի accept կանոն՝ նույնն ամփոփող ignore կանոնների կույտի փոխարեն։ Այն ժամանակ վերանայողները կկարողանան ֆայլը կարդալ վերևից ներքև և կանխատեսել արդյունքը, և դա միակ փորձությունն է, որ մասշտաբավորվում է։
Ստուգեք կիրառված երթուղին և լուծիչը, ոչ թե պրոֆիլը
Ֆայլում ճիշտ թվացող զտիչը դեռ կարող է ձեզ թողնել թունելով, որը ոչ մի օգտակար բան չի երթուղավորում։ Ստուգեք ազդեցությունը աշխատող համակարգի վրա, որտեղ ուղարկված ընտրանքներն արդեն կիրառվել կամ դեն են նետվել.
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/Առաջին երկու տողերը ձեզ ասում են՝ հասե՞լ է ուղարկված լռելյայն երթուղին, և քանի ստատիկ գրառում է վերապրել։ Լուծիչի հարցումը ցույց է տալիս, թե թունելի ինտերֆեյսն իրականում որ սերվերն է օգտագործում, և սովորաբար հենց այնտեղ է ի հայտ գալիս DNS-ի անակնկալը։ Վերջին տողը պատասխանում է օգտագործողի համար կարևոր միակ հարցին։
Փորձարկեք երկու ուղղությունները, քանի դեռ այնտեղ եք։ Կանոնը, որը ձեր տեղական ինտերնետը գործող է պահում, բայց լուռ կոտրում է ներքին անունների լուծումը, անցնում է մակերեսային ստուգումը և ձախողվում առաջին իրական առաջադրանքում, ուստի նույն փորձարկման մեջ ներառեք մեկ ներքին ռեսուրս և մեկ հանրային կայք։
Գրանցեք բացառությունը և դրա սեփականատերը
Զտիչը բացառություն է օպերատորի նախագծից, ուստի գրեք այն պատճառով և վերանայման կետով։ «Անտեսում է ուղարկված երթուղիները՝ տեղական լռելյայնը պահելու համար» վերանայելի է. պրոֆիլում մերկ տողը՝ ոչ, և հաջորդ մարդը կջնջի այն կամ կընդլայնի գուշակությամբ։
Տարբերակն այստեղ նույնպես կարևոր է։ Համընկնման վարքը և ճշգրիտ ընդունված շարահյուսությունը զտվել են OpenVPN 2.4-ի, 2.5-ի և 2.6-ի ընթացքում, ուստի հաստատեք նախշը ձեր տարածած կառուցման ձեռնարկով, այլ ոչ թե ավելի հին թողարկման մասին ֆորումի գրառմամբ։ OpenVPN 2.6-ի ձեռնարկը փաստաթղթավորում է ընտրանքը և դրա համընկնման կանոնը։
Վերջում համաձայնեցրեք բացառությունը նրա հետ, ով կառավարում է սերվերը։ Հաճախորդի կողմի զտիչը, որը հակասում է դիտավորյալ սերվերի քաղաքականությանը, աջակցության միջադեպ է, որը սպասում է հաջորդ աուդիտին, և շատ ավելի էժան է լուծել այն նախքան պրոֆիլը ուղարկվելը, քան այն բանից հետո, երբ ինչ-որ մեկը նկատի, որ երթուղիները բացակայում են։