Որտե՞ղ պետք է լինի երթուղին OpenVPN-ում՝ կլիենտի՞ մոտ, թե՞ սերվերի։
Սերվերի կոնֆիգուրացիայում մերկ երթուղին փոխում է սերվերը, ոչ թե կլիենտը։ Ընտրեք կլիենտի ֆայլը, գլոբալ push կամ միայնակ կլիենտի push և ստուգեք, թե ինչ է հասել։
Դուք ավելացնում եք route 10.60.0.0 255.255.255.0 սերվերի կոնֆիգուրացիային, վերսկսում, նորից միացնում եք դյուրակիր համակարգիչը, և ենթացանցը դեռևս անհասանելի է այդ դյուրակիրից։ Տողը ընդունվել է, ծառայությունը սկսվել է մաքուր, և մատյանում ոչինչ սխալ չի թվում։ Եղել է այն, որ երթուղին տեղադրվել է այն մեքենայի վրա, որը դուք խմբագրել եք՝ դարպասը հիմա կարծում է, որ կարող է հասնել այդ նախածանցին, մինչդեռ կլիենտին ոչինչ չեն ասել։ Տեղադրությունը ողջ հարցն է, և կան չորս տեղեր, որտեղ նույն տողը կարող է ապրել։
Չորս տեղերը և ով է ստանում յուրաքանչյուրը
Երթուղին կարող է ավելացվել կլիենտի սեփական կոնֆիգուրացիայով, առաջարկվել բոլոր կլիենտներին գլոբալ push-ով, առաջարկվել մեկ կլիենտի հատուկ ֆայլով, կամ գրվել սերվերի սեփական երթուղայնացման համատեքստում։
Այդ չորս դեպքերը օգտագործում են գրեթե նույն շարահյուսությունը և տալիս են բոլորովին տարբեր արդյունքներ։ Առաջին երեքը ազդում են այն բանի վրա, թե ինչ է կլիենտը ուղարկում թունել. չորրորդը ազդում է այն բանի վրա, թե ինչպես է սերվերը հասնում ցանցին, ինչը օգտակար է, երբ սերվերն ինքն ուղի է պահանջում, և վնասակար, երբ այն շփոթում են բաշխման հետ։
Որոշեք, թե չորսից որն եք ուզում, նախքան տողը գրելը, ապա հաստատեք ստացողին։
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Ինչու է մերկ սերվերային երթուղին զարմացնում մարդկանց
Սերվերի կոնֆիգուրացիան այն տեղն է, որտեղ ադմինիստրատորները նախ նայում են, և այնտեղի երթուղու հրահանգը կարդացվում է որպես հայտարարություն VPN ցանցի մասին։ Դա այդպես չէ։ OpenVPN-ը դա համարում է տեղական երթուղու տեղադրում այն մեքենայի վրա, որտեղ աշխատում է դեմոնը, ինչը ճիշտ նույն տեսակի փոփոխությունն է, որը դուք կանեիք ip route-ով և հետո կմոռանայիք։
Բաշխումը պահանջում է, որ երթուղին push արվի, իսկ push-ը պահանջում է, որ կլիենտը քաշի այն։ Քաշված ընտրանքները անջատված վիճակում սկսված կլիենտը լիովին անտեսում է առաջարկը։ Ստուգեք այդ ձեռքսեղմման երկու ծայրերը նախքան սերվերի ֆայլը վերագրելը, որովհետև սերվերի մատյանը չի բողոքի՝ իր կողմից առաջարկն ուղարկվել է։ Ընդունված երթուղին նույնպես ուժի մեջ է մտնում միայն հաջորդ միացման ժամանակ, երբեք այն սեսիայում, որտեղ դուք արդեն գտնվում եք։
Հենց որ տեսնեք երկուսը որպես առանձին գործողություններ, ձախողումը դադարում է խորհրդավոր լինելուց՝ սերվերը հասնում է նախածանցին, կլիենտը՝ ոչ, և երկու պնդումներն էլ ճշմարիտ են միաժամանակ։
Կլիենտին հատուկ ֆայլերը և այն ինքնությունը, որին դրանք համապատասխանում են
Կլիենտին հատուկ ֆայլը անվանվում է այն ինքնությամբ, որը սերվերը նույնականացրել է, ինչը լռելյայն վկայագրի ընդհանուր անունն է։ Աշխատասեղանի կլիենտում բարեկամական միացման անունը այդ արժեքը չէ, և անհամապատասխանությունը ստեղծում է ֆայլ, որը երբեք չի կարդացվում։
Ստուգեք այն պանակը, որը սերվերը փաստացի օգտագործում է, ապա հաստատեք, որ ֆայլի անունը ճիշտ համապատասխանում է նույնականացված ինքնությանը՝ ներառյալ մեծ ու փոքր տառերը։
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Այդ ֆայլի ներսում երթուղին դեռ պետք է push արվի, քանի որ կլիենտին հատուկ համատեքստը այդ կլիենտի սեսիային կիրառվող ընտրանքների ամբողջություն է, ոչ թե տեղական երթուղայնացման աղյուսակ։ Այնտեղի մերկ երթուղին ունի նույն խնդիրը, ինչ գլոբալ ֆայլի մերկ երթուղին։
Կլիենտի սեփական ֆայլը և այն գործիքը, որը տիրապետում է դրան
Կլիենտի կոնֆիգուրացիայում տեղադրված երթուղին տեղադրվում է, երբ այդ կլիենտը միանում է, և հեռացվում է, երբ անջատվում է, ինչը ճիշտ կենսացիկլ է ստատիկ նպատակակետի համար։
Եթե ցանցի կառավարիչը տիրապետում է պրոֆիլին, այն կարող է մեկ անգամ ներմուծել այդ ընտրանքները և հետո պահել իր օրինակը։ Ներբեռնված ֆայլը հետո խմբագրելը ոչինչ չի փոխում, ինչը "երթուղին այնտեղ է, բայց չի գործում" արտահայտության տարածված պատճառն է։
Ստուգեք ակտիվ պրոֆիլը, ոչ թե ներբեռնած ֆայլը, և ստուգեք ներմուծված կարգավորումները, որոնք ցույց է տալիս կառավարիչը։ Ապա միացեք և հարցրեք համակարգին, թե որ ուղին է օգտագործում կոնկրետ հասցեն, փոխարենը ենթադրելու, որ թունելը հաղթել է, որովհետև երթուղին կար տեքստային ֆայլում։
Ստուգեք կլիենտի վրա, ապա ստուգեք վերադարձի ուղին
Հարցրեք կլիենտի սեփական երթուղայնացման աղյուսակին նպատակակետի մասին, ոչ թե սերվերինը։ Նախածանցի ներսում մեկ հոսթի որոնումը բավական է ցույց տալու, թե որ ինտերֆեյսն ու հաջորդ ցատկը կօգտագործվեն։
ip route get 10.60.0.10Եթե որոնումը ցույց է տալիս թունելը, բաշխումը աշխատել է, և մնացած խնդիրը այլ տեղ է։ Եթե այն ցույց է տալիս լռելյայն դարպասը, երթուղին տեղադրված չէ, զտվել է կլիենտի կողմի ընտրանքով, կամ պատկանում է պրոֆիլի, որը կլիենտը չի օգտագործում։
Ենթադրենք բաշխումը աշխատել է, և դեռ ոչինչ չի պատասխանում՝ ապա ստուգեք փոխանցումը դարպասի վրա, մյուս կողմի վերադարձի ուղին և ցանկացած հրավահան նրանց միջև։ Երթուղին ընտրում է ուղի, այն չի տալիս հասանելիություն։