Access Server-ի դարպասի օգտատեր։ հաճախորդի մասնաճյուղի LAN-ի երթուղավորում

Կարող եք ping անել OpenVPN հաճախորդի թունելի հասցեն և այնուամենայնիվ չհասնել նրա հետևում գտնվող LAN-ի ոչ մի հոսթի։ Access Server-ը հաճախորդին տալիս է հասցե VPN լողավազանից, և լողավազանի հասցեն այն ամենն է, ինչ սերվերը գիտի որպես իրենը։ Մասնաճյուղի նախածանցը առանձին փաստ է, որը պետք է հայտարարել, և նույնիսկ դրանից հետո մասնաճյուղին պետք է փոխանցիչ, իսկ կենտրոնական գրասենյակին՝ վերադարձի ուղի։ Սխալ տեղում գրված երթուղին թվում է լուծում և ոչինչ չի փոխում։

Երկու հասցե, սեփականության երկու տարբեր պահանջ

Երբ հաճախորդը միանում է, Access Server-ը նրան հասցե տալիս կարգավորված VPN լողավազանից, օրինակ 10.90.0.0/24։ Այդ հատկացումը վարձակալություն է մեկ հոսթի համար։ Միացման մեջ ոչինչ չի ասում, որ նույն հաճախորդը կանգնած է նև 10.60.0.0/24-ի առջևում, և սերվերը չի գուշակի։ LAN նախածանցը հասանելի է կոնկրետ հաճախորդի միջոցով միայն այն դեպքում, երբ ադմինիստրատորը հայտարարում է այն։

Դրա համար էլ չի աշխատում մեկ այլ մեքենայի վրա ստատիկ երթուղին։ Երթուղին ասում է՝ ուղարկիր 10.60.0.0/24-ը այս հասցեին, բայց եթե հասցեն պատկանում է հաճախորդին, որը երբեք չի նշվել որպես դարպաս, սերվերը պատճառ չունի այդ փաթեթները այնտեղ հասցնելու, և հաճախորդի ստեկը կարող է դեն նետել դրանք։ Հայտարարությունը և երթուղին մեկ մեխանիզմի երկու կեսերն են։

Ինչ է իրոք տեղադրում դարպասի կարգավորումը

Admin Web UI-ում հայտարարությունը օգտատիրոջի հատկություն է։ միացրեք Configure VPN gateway-ը connector օգտատիրոջի վրա և մուտքագրեք մասնաճյուղի իրական նախածանցը Network on the VPN client side-ում։ Այդ օգտատերը նույնականացվում է ինչպես ցանկացածը, ուստի նրան պետք է անհսկող սարքի համար հարմար հավատարմագրային քաղաքականություն, և նրա ավտոմատ մուտքի պրոֆիլը գաղտնիք է, ոչ հարմարության ֆայլ։

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

Սեղման ֆայլում տեղադրված Community ոճով հրահանգը չի մասնակցում այս մոդելին։ Արտադրանքը տիրապետում է այն երթուղային աղյուսակին, որը ուղարկում է։ ձեքով խմբագրված տողը հաջորդ գեներացիյում վերագրվում է կամ անտեսվում։

Ավարտեք երկու ցանցերի վերադարձի ուղիները

Կոնկրետ պլան։ կենտրոնական գրասենյակ 10.40.0.0/24, մասնաճյուղ 10.60.0.0/24, VPN լողավազան 10.90.0.0/24, և Access Server-ը հասանելի է մասնավոր հասցեով կենտրոնական գրասենյակի կողմից։ Կենտրոնական գրասենյակի երթուղիչին պետք են երթուղիներ մասնաճյուղի նախածանցի և լողավազանի համար, երկուսնը՝ դեպի Access Server։ Առանց դրանց թունելը տանում է հարցումը, և պատասխանը դուրս է գալիս լռելյային դարպասով, ինչը տալիս է դասական կիսաբաց միացումը։

Մասնաճյուղում connector-ը պետք է փոխանցի իրեն չուղշված փաթեթները։ IP փոխանցում իր օպերացիոն համակարգում եւ թունելի և LAN ինտերֆեյսներով սահմանափակված փոխանցման թույլտվություն։ Linux-ում դա net.ipv4.ip_forward=1-ն է forward շղթայի կանոնների հետ, Windows-ում՝ routing and remote access։ Այնուհետև մասնաճյուղի հոսթերին պետր է վերադարձի ուղի։ կամ connector-ը նրանց լռելյային դարպասն է, կամ գոյություն ունեցող դարպասը կրում է հատուկ երթուղիներ կենտրոնական գրասենյակի և լողավազանի նախածանցների համար։

Connector-ի սեփական երթուղային աղյուսակը չի վերակարգավորում մասնաճյուղի LAN-ի յուրաքանչյուրք հոսթին։ Եթե հոսթերը մատնանշում են մեկ այլ երթուղիչի, վերադարձի երթուղիները այնտեղ են, և նա պետք է ընդունի, որ իր տեսած աղբյուրի հասցեն տեղական ենթացանցի հարևան չէ։

Խափանումը կարդացեք որպես ուղի, ոչ որպես թույլտվություն

Փորձարկեք ֆիքսված հերթով։ Նախ Access Server-ից մասնաճյուղի հոսթ հասնող թույլատրված ծառայություն, ապա նույն ծառայությունը կենտրոնական գրասենյակի սովորական հոսթից, ապա հակառուղղությունը, եթե քաղաքականությունը թույլ տալիս։ Եթե առաջինը անցնում է, իսկ երկրորդը՝ ոչ, խնդիրը ուղարկված երթուղիներն են կամ մուտքի կանոնները։ Եթե երկուսնէլ անցնում են, բայց պատասխան չի գալիս, ստուգեք փոխանցումը մասնաճյուղում և վերադարձի երթուղին կենտրոնական գրասենյակում։

Հոսթի firewall-ը հաջորդ կասկածյալն է, քանի երթուղավորված մուտքի դեպքում նպատակը որպես աղբյուր տեսնում է կենտրոնական գրասենյակի կամ լողավազանի հասցե։ Տեղական ենթացանցի համար գրված կանոնը չի համապատասխանի, և փաթեթը դեն է նետվում այն բանից հետո, երբ երթուղավորումը կատարյալ աշխատեց։

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

Access Server-ի site-to-site ձեռնարկը նույն կարգավորումները թվարկում է արտադրանքի հերթով։ արժանի է մեկ անգամ հետևել դրան, նախքան ձևավորումը հարմարեք ձեր նախածանցներին։