pfSense-ում OpenVPN-ի անցման երեք տեսակ, երեք մեխանիզմ

«OpenVPN failover»-ը pfSense-ում ընդգրկում է առնվազն երեք իրարից անկախ նախագիծ, և դրանցից յուրաքանչյուրը պահանջում է այլ մեխանիզմ։ Թունելը պահուստային ինտերնետ կապուղու միջոցով կենդանի պահելը, այլ սերվերի վերակապակցվելը և LAN թրաֆիկը մեկ այլ արդեն հաստատված թունել ուղղելը մեկ գործառույթի տարբերակներ չեն։ Ընտրեք այն խափանումը, որից պաշտպանվում եք, նախքան գեյթվեյ խումբը կառուցելը։ Այն խումբը, որը շտկում է դրանցից մեկը, ոչինչ չի անում մյուս երկուսի համար։

Անվանեք խափանումը, նախքան խումբ կառուցելը

Գրեք այն նախադասությունը, որը ցանկանում եք ճշմարիտ տեսնել ընդհատման ընթացքում։ «Թունելը վերակապակցվում է պահուստային WAN-ի միջոցով» և «մասնաճյուղը շարունակում է հասնել հավելվածին մյուս թունելի միջոցով» տարբեր նախադասություններ են։ Միայն առաջինն է տրանսպորտի մասին։

Այնուհետև կապեք այն մեխանիզմի հետ։ Տեղական WAN-ի կորուստը ինտերֆեյսի ընտրության խնդիր է, մեռած հեռավոր վերջնակետը՝ կապերի ցանկի խնդիր, իսկ հաստատված թունելի ներսում անօգտագործելի ուղին՝ երթուղավորման և քաղաքականության խնդիր։

Տեղական WAN՝ տեղափոխել տրանսպորտը

pfSense-ի OpenVPN հաճախորդի համար աջակցվող բազմակի WAN դասավորությունն ընտրում է համապատասխան գեյթվեյ խումբ որպես ինտերֆեյս, որին կապվում է հաճախորդը։ Հենց դա է թույլ տալիս արտաքին կապին դուրս գալ պահուստային կապուղով, երբ առաջնայինը ձախողվում է։ Ինքնին այն չի փոխում, թե ինչպես է երթուղավորվում ներքին թրաֆիկը։

Նույն նախագծի սերվերի կողմը առանձին է։ OpenVPN սերվերին, որը պետք է հասանելի լինի մի քանի հանրային հասցեներով, անհրաժեշտ է լսող և մուտքային քաղաքականություն այդ գրառումներից յուրաքանչյուրի համար, ոչ միայն հաճախորդ, որը կարող է զանգահարել երկու կապուղով։ Մեկ աշխատող հանրային գրառումը վկայություն չէ, որ երկրորդը կարգավորված է։

Փոխանցվող LAN փաթեթների համար քաղաքականության վրա հիմնված երթուղավորման կանոնը այն պարամետրը չէ, որը տեղափոխում է տեղում ստեղծված VPN տրանսպորտային կապը։ Դրանք երկու տարբեր որոնումներ են, և մեկի փոփոխությունը չի փոխում մյուսը։

Հեռավոր վերջնակետ՝ այլ սերվեր

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

Յուրաքանչյուր թեկնածու պետք է լինի իսկական փոխարինող՝ համատեղելի նույնականացում, համատեղելի հաճախորդի քաղաքականություն և հասանելիություն նույն մասնավոր ռեսուրսներին։ Երկրորդ հոսթի անունը, որը վերածվում է նույն խափանված ենթակառուցվածքի, պահուստ չէ։ Սերվերը առանց պահանջվող երթուղու նույնպես չէ, որքան էլ առողջ տեսք ունենա նրա ձեռքսեղմումը։

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

Թունելի ուղին՝ ընտրել այլ ելք

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

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

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

Մոնիտորներ, NAT և fail-closed կանոնը

Մոնիտորը պետք է ստուգի մի բան, ինչ թունելը պետք է մատակարարի։ Թիրախը, որը պատասխանում է թունելի գործընկերոջից, բայց ոչ նրա հետևում գտնվող հավելվածի ցանցից, կհայտնի առողջ վիճակ, մինչ օգտագործողները ոչինչ չեն տեսնում։ Անհասանելի ախտորոշիչ թիրախը կհայտնի մեռած վիճակ, մինչ ուղին կարգին է։ Ընտրեք հասցեն դիտավորյալ և հաստատեք, որ այն հասանելի է միայն նախատեսված թունելով։

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

Այնուհետև որոշեք, թե ինչ է լինում այն թրաֆիկի հետ, որը երբեք չպետք է օգտագործի WAN։ pfSense-ը սահմանված վարք ունի այն կանոնների համար, որոնց ընտրված գեյթվեյը ընկել է, և ավելի ուշ լայն թույլատրող կանոնը կամ լռելյայն երթուղին կարող են չեղարկել ձեր մտադրությունը։ Գրեք արգելափակված արդյունքը որպես պահանջ, ապա ստուգեք այն՝ անջատելով ուղին։

Փորձարկեք կորուստն ու վերականգնումը առանձին, ձեզ թույլատրված թրաֆիկով, և միաժամանակ հետևեք երեք բանի՝ արտաքին կապը կրող WAN-ին, հավելվածի հարցումը կրող թունելին և այն ուղուն, որով գնում է պատասխանը։ Զույգ կանաչ գեյթվեյ ցուցիչ այդ երեքից մեկը չէ։ Netgate-ի բազմակի WAN ուղեցույցը նկարագրում է տրանսպորտի կապակցումը և արտահանված հաճախորդի այլընտրանքները, որոնց վրա հիմնված է սա։