Ինչու է OpenVPN հաճախորդի հետևում գտնվող ենթացանցը անհասանելի?

ping-երը դեպի սերվերի թունելային հասցեն հաջողվում են, հաճախորդի սեփական երթուղիների աղյուսակը ճիշտ է թվում, և այդ հաճախորդի հետևում գտնվող LAN-ը դեռ անհասանելի է։ Հաճախորդի երթուղիների աղյուսակը ճիշտ է թվում, սերվերն ունի դեպի թունելը ուղղված երթուղի, և փաթեթները դեռ անհետանում են։ Սա layer-3 թունելի դասական ախտանիշն է, որը չգիտի, որ իր հաճախորդներից մեկը նաև դարպաս է։

tun ինտերֆեյսը չունի հաջորդ ցատկ յուրաքանչյուր հաճախորդի համար։ Միջուկը տեսնում է մեկ ինտերֆեյս՝ բազմաթիվ գործընկերներով, ուստի հեռավոր LAN-ի համար որ հաճախորդը պետք է ստանա փաթեթը, այդ որոշումը պետք է կայացվի OpenVPN գործընթացի ներսում։ Այդ որոշումը կարգավորվում է iroute-ով, և առանց դրա փաթեթը տեղ չունի գնալու։

Սերվերը երթուղավորում է ըստ հաճախորդի, ոչ ըստ ինտերֆեյսի

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

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

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

Գրել iroute գրառումը, որը նշում է հաճախորդին

iroute-ը ապրում է հաճախորդին հատուկ կարգավորումների ֆայլում, ոչ սերվերի հիմնական կարգավորումում։ Ուղղեք սերվերը դեպի պանակ client-config-dir ընտրանքով, ապա ստեղծեք ֆայլ, որի անունը հաճախորդի վկայագրի ընդհանուր անունն է, և նախածանցը դրեք դրա մեջ։

Մասնաճյուղի համար, որի LAN-ը 10.20.0.0/24 է, իսկ վկայագրի ընդհանուր անունը՝ branch-router, այդ ուղու ֆայլը պարունակում է տող, ինչպիսին է iroute 10.20.0.0 255.255.255.0-ը։ Հիմնական կարգավորմանը պետք է միայն պանակի ընտրանքը, նախածանցը ապրում է հաճախորդի մոտ։

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

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

Վերադարձի ուղու կառուցումը երկու ուղղություններով

Փաթեթները հեռավոր LAN հասցնելը գործի կեսն է։ Հաճախորդը պետք է նաև այդ LAN-ի երթևեկությունը ուղարկի թունել, ինչը սովորաբար արվում է հաճախորդին երթուղի հրելով՝ push "route 10.8.0.0 255.255.255.0"-ի նման տողը յուրաքանչյուր հաճախորդի ասում է, թե ինչպես հասնել սերվերի կողմի ցանցին։ Մասնաճյուղի համար համարժեք երթուղին ուղղված է թունելին այն ամենի համար, ինչին այն պետք է հասնի սերվերի կողմում։

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

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

Հասանելիության ստուգումը ճիշտ զոնդերով

Փորձարկեք շերտերով՝ հեռավոր ծայրը ping անելու և գուշակելու փոխարեն։ Սերվերից ստուգեք, որ նախածանցի ներքին քարտեզագրումը գոյություն ունի, և միջուկի երթուղին ուղղված է թունելին։ Հաճախորդից հաստատեք, որ հրված երթուղին տեղադրված է, և որ LAN հասցեի համար նրա լռելյայն ուղին թունելն է։

Ապա դիտեք փաթեթները։ Թունելի ինտերֆեյսում որսումը ցույց է տալիս, թե արդյոք սերվերը հաղորդում է դեպի հաճախորդը, իսկ LAN ինտերֆեյսում որսումը ցույց է տալիս, թե արդյոք այն փոխանցում է։ Եթե առաջինը փաթեթներ է ցույց տալիս, իսկ երկրորդը ոչինչ, խնդիրը փոխանցման կամ զտիչի մեջ է, եթե ոչ մեկը ոչինչ չի ցույց տալիս, որոնումը ձախողվել է ավելի վաղ։

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