Ինչն է OpenVPN-ի route-nopull-ը իրականում թույլ չտալիս սերվերին ուղարկել
route-nopull-ը գցում է ուղարկված երթուղիներն ու DHCP ընտրանքները, ոչ թե ձեռքսեղմումը։ Ընտրեք դրա, pull-filter-ի կամ ոչնչի միջև, ապա ինքներդ ավելացրեք երթուղիները։
Դուք դրել եք route-nopull հաճախորդի պրոֆիլում, որպեսզի թունելը չկուլ տա ձեր լռելյայն երթուղին, և այժմ գրասենյակի ենթացանցն անհասանելի է, մինչ հաճախորդը դեռ ասում է, որ միացած է։ Երկու դիտարկումներն էլ ճշմարիտ են, և ոչինչ չի ձախողվել։ Դրոշը հաճախորդին ասում է բաց թողնել սերվերի ուղարկած երթուղիներն ու DHCP գրառումները, ինչը ավելի նեղ հրահանգ է, քան մարդկանց մեծ մասը սպասում է, երբ ավելացնում է այն։ Մնում է աշխատող թունել, որը կարծիք չունի, թե որ նպատակակետերը պետք է օգտագործեն այն։
Այդ բացն է այն ամբողջ որոշումը, որի մասին այս հոդվածն է։ Կամ սերվերն է նկարագրում ցանցը, կամ հաճախորդը, և դրոշը այդ աշխատանքը հանձնում է հաճախորդին՝ ձեզ փոխարեն դրանից ոչինչ չանելով։
Ինչ է անջատում դրոշը միանալու պահին
Քաշող OpenVPN հաճախորդը սովորաբար նույնականացումից հետո սերվերից վերցնում է փաթեթ՝ երթուղիներ, լռելյայն դարպասի վերահասցեավորում, DNS սերվերներ և մի քանի կարգավորման հրահանգներ։ route-nopull-ի գործողության դեպքում հաճախորդը դեռ ընդունում է սեսիան, դեռ ստուգում է վկայագրերը, դեռ բանակցում է գաղտնագրերի և keepalive-ի շուրջ, և դեռ բարձրացնում է ինտերֆեյսը։ Այն, ինչ նա գցում է, ուղարկված route տողերի և ուղարկված dhcp-option տողերի կիրառումն է՝ ներառյալ DNS-ը։
Շփոթությունը գալիս է մեռած հավելվածի կողքի կանաչ ցուցիչից։ Թունելը գոյություն ունի, նպատակակետերի քարտեզագրումը դեպի այդ թունելը՝ ոչ։ Հաճախորդի կարգավիճակի վահանակում ոչինչ չի տարբերում «միացած և երթուղավորող»-ը «միացած և անգործ»-ից, քանի որ թունելի տեսանկյունից երկուսն էլ նույն վիճակն են։
Ինչու կենդանի թունելը դեռ կարող է ոչինչ չերթուղավորել
Ինտերֆեյսը հայտնվում է իր հասցեով և կետ-կետ կապում հաճախ ավելի կոնկրետ ոչինչ չկա, քան զուգընկերոջը տանող հոսթ-երթուղին։ Մասնավոր ենթացանցը հասանելի է դառնում միայն այն ժամանակ, երբ ինչ-որ երթուղի ճիշտ նախածանցով ցույց է տալիս այդ ինտերֆեյսին, և ուղարկումն անջատված լինելու դեպքում այդ երթուղին երբեք չի գալիս։ Ներբեռնված պրոֆիլը նույնպես սովորաբար չի կարող օգնել, քանի որ այն գրվել է այն ենթադրությամբ, որ սերվերը կտրամադրի հենց այս տեղեկությունը։ Այդ պատճառով ինտերֆեյսը կարող է առողջ երևալ, մինչ ենթացանցը մնում է մութ։
Պրոֆիլը կարդալը քիչ բան է ապացուցում, ուստի կարդացեք աշխատող վիճակը միացած մեքենայի վրա։
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10Երկրորդ հրամանում ենթացանցային երթուղի չունեցող հասցեն այս խնդրի ստորագրությունն է։ Երրորդ հրամանն այնուհետև պատասխանում է այն հարցին, որն իսկապես հուզում է օգտատերերին, քանի որ հայտնում է այն ինտերֆեյսը, որը միջուկը կընտրեր կոնկրետ նպատակակետի համար, այլ ոչ այն ցանկը, որը դուք հույս ունեիք, որ նա կօգտագործեր։ Եթե այն պատասխանում է ձեր ֆիզիկական կապով, ապա թունելն ընդհանրապես ճանապարհին չէ։
Անվան լուծումը ձախողվում է կապված պատճառով, ոչ առանձին։ Ուղարկված dhcp-option DNS գրառումները բաց են թողնվում նույն դրոշով, այնպես որ ներքին հոսթերի հարցումները գնում են այն լուծիչին, որը տրամադրել է տեղական ցանցը։ Այդ լուծիչը գրասենյակի համար գոտի չունի, ուստի հարցումը ձախողվում է կամ վերադարձնում է հանրային պատասխան, և ձախողումը նման է սերվերի խնդրի, մինչդեռ դա հաճախորդի կարգավորման խնդիր է։ Հասցեն անունից առաջ փորձարկելն է, ինչը բաժանում է երկուսը։
Ընտրություն դրոշի և նախածանցի զտիչի միջև
Երկու տարբերակները լուծում են նույն բողոքը տարբեր ձևերով, և վատ ընտրությունն է, որ ստեղծում է միացած-բայց-անօգուտ վիճակը։ Մեկը փոխարինում է ուղարկված քաղաքականությունն ամբողջությամբ, մյուսը խմբագրում է այն նախածանցով։ Աղյուսակը տալիս է համառոտ տարբերակը, իսկ դրանից հետո պարբերությունը ծածկում է այն մասը, որը զարմացնում է մարդկանց։
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter-ը երեք բայով նախածանցային համապատասխանիչ է, ուստի այն կարող է ընդունել տողերի ընտանիք, լռելյայն անտեսել դրանք կամ ամբողջությամբ մերժել կապը, երբ նախածանց է հայտնվում։ Հենց վերջին վարքագիծն է, որ արժե իմանալ. մերժման կանոնը քաղաքական տարաձայնությունը դարձնում է ձախողված ձեռքսեղմում՝ լուռ բացթողման փոխարեն։ OpenVPN 2.6 ձեռնարկը թվարկում է ընդունված նախածանցները և յուրաքանչյուր բայի ճշգրիտ իմաստը։
Տարածված միջին ուղին մերժել միայն redirect-gateway-ը և թույլ տալ, որ գրասենյակի երթուղիներն ու DNS-ը գան ինչպես նախատեսված է։ Սա ուղարկումը պահում է աշխատունակ այն մասերի համար, որոնք սերվերն ավելի լավ է հասկանում, քան դուք, և միաժամանակ կանխում է այն մեկ տողը, որը կզավթեր ձեր լռելյայն երթուղին։
Երթուղիների և լուծիչի ձեռքով ավելացում
Եթե պահում եք դրոշը, պրոֆիլը պետք է ասի այն, ինչ սերվերը կասեր։ Հաճախորդի կողմի route հրահանգները կիրառվում են կապի հաստատումից հետո, ուստի դրանք աշխատում են դրոշի կողքին, այլ ոչ թե արգելափակվում դրա կողմից։ Դրեք դրանք պրոֆիլում, ոչ ինտերակտիվ հրամանի տողում, այլապես հաջորդ վերամիացումը չի վերարտադրի աշխատող վիճակը։
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS տողը անհարմար դիրքում է՝ այն հաճախորդի կողմի հրահանգ է, բայց որոշ հաճախորդներ այն կիրառում են միայն հարթակի DNS ինտեգրման միջոցով, որը կարող է վերագրել այն, երբ կապը փոխվում է։ systemd հոսթի վրա լուծիչն ուղղակիորեն թունելի ինտերֆեյսի վրա դնելը ավելի կանխատեսելի է, քան հույսը, որ հաճախորդը կհաղթի առաջնահերթության մրցույթում:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comԵրթուղավորման տիրույթը նույնքան կարևոր է, որքան հասցեն։ Առանց դրա հանրային անունների հարցումները նույնպես կարող են ուղարկվել ներքին լուծիչին, և ցանկացած ներքին լուծիչ, որը մերժում է ռեկուրսիան, կկոտրի զննարկումը՝ թողնելով մասնավոր գոտին աշխատող։ Դրա հետ միայն այդ վերջածանցի տակ գտնվող անուններն են ուղղորդվում թունելի լուծիչին, և մնացած ամեն ինչ հետևում է ֆիզիկական կապին։
Արդյունքի ստուգում՝ հասցե, անուն և արտաքին ուղի
Երեք թեստեր առանձնացնում են հնարավոր ձախողումները։ Ստացեք մասնավոր հասցեն IP-ով, ապա նույն հոսթը անունով, ապա սովորական հանրային կայք։ Աշխատող IP-ն ձախողվող անունով մատնանշում է լուծիչին, ձախողվող IP-ն աշխատող անունով՝ երթուղավորմանը, իսկ երկուսի ձախողումը սովորաբար նշանակում է, որ թունելը ճանապարհին չէ։
Ապա նայեք դուրս, ոչ ներս։ Թունելի վերջնակետի սեփական երթուղին պետք է վերապրի փոփոխությունը, և ցանկացած արգելափակող ձախողում պետք է սահմանափակվի թունելով՝ առանց վերջնակետը բռնելու։ Հաճախորդը, որը շարունակում է զննարկել թունելի անկումից հետո, քաղաքականության խնդիր է, ոչ երթուղավորման, և այն չի հայտնվի վերը նշված երեք թեստերից ոչ մեկում։
Վերջնական ցանկը գրեք պրոֆիլի փաստաթղթերում՝ երթուղիները, լուծիչը, տիրույթները և յուրաքանչյուրի գոյության պատճառը։ Նույն աղյուսակը վերարտադրող վերամիացումը տեղական քաղաքականության ամբողջականության միակ ապացույցն է։ Եթե հավելվածները դեռ ձախողվում են, երբ թունելը վերևում է և բոլոր երեք թեստերն անցել են, հաջորդ տեղը, որտեղ պետք է նայել, միացած-բայց-անջատված խնդիրների դասն է, ոչ թե արդեն ստուգված վկայագրերը։