OpenVPN iroute և միջուկի երթուղի. որն է բացակայում

10.77.20.0/24-ի համար փաթեթը OpenVPN սերվերի վրա երկու առանձին որոշում է պահանջում. օպերացիոն համակարգը պետք է այն հանձնի VPN ինտերֆեյսին, և OpenVPN-ը պետք է իմանա, թե որ միացված հաճախորդն է տիրապետում այդ նախածանցին։ Բացակայող միջուկի երթուղին այն գցում է թունելից առաջ, իսկ բացակայող զուգընկերոջ երթուղին՝ դրանից հետո։ Երկու խափանումները հեռավոր LAN-ից նույն տեսքն ունեն, և դրանցից որը ձերն է՝ պարզելու համար յուրաքանչյուր կողմում մեկ հրաման է պետք։

Դասական օգտվողական տարածության տվյալների ուղում միջուկի երթուղին փաթեթը հասցնում է թունելի պրոցեսին, և iroute-ը այդ պրոցեսին ասում է, թե որ զուգընկերը պետք է ստանա այն։ Ոչ մեկը չի փոխարինում մյուսին, և դրանցից միայն մեկը պարունակող կազմաձևը խելամիտ կթվա մինչև առաջին ping-ը։

Երկու որոշում, ոչ թե մեկ երթուղի

Պատկերացրեք կայքից կայք կապ, որտեղ 10.77.20.0/24-ը գտնվում է մեկ հաճախորդի հետևում։ Սերվերի միջուկի երթուղին, օրինակ ip route add 10.77.20.0/24 dev tun0-ը, համապատասխան փաթեթներն ուղարկում է թունելի սարքին։ Այնուհետև OpenVPN-ը դիտարկում է իր սեփական ներքին աղյուսակը, որը կառուցված է հաճախորդի կազմաձևման պանակի iroute գրառումներից, որպեսզի որոշի, թե որ զուգընկերոջ միացումը կստանա դրանք։ Առանց միջուկի երթուղու փաթեթը երբեք չի հասնում պրոցեսին, իսկ առանց զուգընկերոջ երթուղու այն հասնում է պրոցեսին և ոչ մի տեղ չի գնում։

Այդ բաժանումը հեշտ է մոռանալ, որովհետև հաճախորդի պրոֆիլում մեկ երթուղու տողը կարող է թվալ, թե կատարում է երկու աշխատանքն էլ։ Չի կատարում. երթուղի հրելը հաճախորդներին ասում է, թե ինչ ուղարկել թունելով, մինչդեռ iroute-ը սերվերին ասում է, թե ում է պատկանում հաճախորդի հետևի հասցեների միջակայքը։ Դրանք ապրում են տարբեր ֆայլերում, կարդացվում են տարբեր կողմերից և խափանվում են հակառակ ուղղություններով։

Որտեղ է տեղը iroute-ին և ինչ է ասում

Գրառումը գնում է հաճախորդի common_name-ով անվանված առանձին ֆայլի մեջ, client-config-dir-ի տակ, որպես iroute 10.77.20.0/24։ Ֆայլի անվան համընկնումը զուտ դեկորատիվ չէ. OpenVPN-ը փնտրում է նույնականացված ինքնությունը և կարդում ֆայլը հենց այդ անունով, ուստի site-a անունով ֆայլը գործում է միայն այն հաճախորդի համար, ում ընդհանուր անունը site-a է։ Ավելացրեք ccd-exclusive, եթե նման ֆայլ չունեցող հաճախորդներին պետք է ամբողջովին մերժել, ինչը ճիշտ կարգավորումն է, երբ յուրաքանչյուր հաճախորդ կայքի դարպաս է։ Պահեք մեկ ֆայլ յուրաքանչյուր դարպասի համար և անվանեք այն այն վկայագրի սուբյեկտով, որը դուք իսկապես թողարկում եք։

Փորձարկեք գրառումը սերվերից նախքան հեռավոր LAN-ին մեղադրելը։ Կարգավիճակի ֆայլը թվարկում է միացված հաճախորդներին իրենց ընդհանուր անուններով, և --verb 4-ով աշխատող սերվերը գրանցում է iroute-ի տեղադրումը զուգընկերոջ միանալու պահին։ Եթե միանալիս ոչինչ չի հայտնվում, ֆայլը սխալ պանակում է կամ նշում է սխալ ինքնություն։

Թակարդը. ֆայլը կա, ինքնությունը սխալ է

Ճիշտ տեսք ունեցող, բայց սխալ զուգընկերոջը կցված iroute-ը ավելի շատ ժամանակ է վատնում, քան բացակայող ֆայլը, որովհետև սկավառակի վրա ամեն ինչ ճիշտ է թվում։ Վկայագրերի վերանվանումը, կրկնվող ընդհանուր անունները և արդյունավետ ինքնությունը փոխող username-as-common-name-ը բոլորը ստեղծում են դա։ Ստուգեք, թե որ ինքնությունն է սերվերը նույնականացրել, այլ ոչ թե որը դուք էիք սպասում. կարգավիճակի ելքը հեղինակավոր է, մինչդեռ ֆայլի անունը միայն որոնման բանալի է։

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

Ավարտեք ուղին զուգընկերոջից այն կողմ

Զուգընկերոջ պատկանելությունը ուղու մեջտեղն է, ոչ թե վերջը։ Հաճախորդը պետք է փաթեթները թունելից փոխանցի իր LAN, ինչը նշանակում է, որ այդ հոսթում IP փոխանցումը միացված է, և արգելապատնեշի կանոնը թույլ է տալիս անցումը։ Հեռավոր LAN-ի հոսթերին պետք է վերադարձի ուղի թունելի հասցեի համար. կամ դարպասին հետ ուղղված երթուղի, կամ հաճախորդի կողմում դիտավորյալ NAT լուծում։ Հաստատեք փոխանցման կարգավորումը հաճախորդում sysctl net.ipv4.ip_forward-ով, փոխարենը ենթադրելու տեղաբաշխման լռելյայն արժեքը։

Եթե այլ VPN հաճախորդներ պետք է հասնեն այդ ենթացանցին, դասավորությունը նորից մեծանում է. սերվերին պետք է client-to-client, և այդ հաճախորդները պետք է նախածանցը ուղղորդեն թունելով։ Դրանցից ոչինչ չի բխում սերվերի սեփական երթուղային աղյուսակից։

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