Ինչպես կառուցել VPN-ի անցման քաղաքականություն երթուղիչում առանց արտահոսքերի

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

Որոշեք արդյունքը նախքան դետեկտոր ընտրելը

Սովորաբար սեղանին երեք արդյունք կա՝ տուժած հաճախորդներին ուղարկել պահուստային թունելով, թույլ տալ նրանց օգտվել սովորական WAN-ից, կամ արգելափակել նրանց ամբողջությամբ։ Գրեք, թե որն է վերաբերում որ VLAN-ին, SSID-ին կամ սարքերի դասին։ Մեկ հարթ «անցնել WAN-ին» կանոնն է պատճառը, որ վերևի ֆինանսական պանակը հայտնվեց հանրային ուղիում։

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

Համապատասխանեցրեք դետեկտորը այն խափանմանը, որից իրոք վախենում եք

Ձեռքսեղմման վիճակը, ինտերֆեյսի վիճակը և օգտագործելի փոխանցումը երեք տարբեր ազդանշաններ են, և օգտվողի համար կարևոր է միայն վերջինը։ WireGuard զույգը կարող է ցույց տալ վերջերս ձեռքսեղմում, մինչդեռ մատակարարի վերին հոսքը փաթեթները նետում է սև փոսը։ OpenVPN հաճախորդը կարող է մնալ «միացված» վիճակում այն բանից հետո, երբ նրա հրած երթուղին դադարել է լուծվել։

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

Կառուցեք խումբը այնպես, որ պահուստը մնա վերջին միջոց

Օգտագործեք աստիճաններ՝ մեկ հարթ անդամների ցանկի փոխարեն։ Հիմնականը 1-ին աստիճանում, պահուստային թունելը՝ 2-րդ աստիճանում, WAN-ը՝ 3-րդ աստիճանում միայն այն VLAN-ների համար, որոնց քաղաքականությունը դա թույլ է տալիս։ pfSense-ում սա գտնվում է System > Routing > Gateway Groups-ի տակ՝ ավելացրեք երկու դարպասները, տվեք նրանց տարբեր աստիճաններ, Trigger Level-ը դրեք member down plus packet loss, պահեք, ապա խումբը կիրառեք որպես ինտերֆեյսի լռելյայն կամ այն firewall-կանոնների Gateway դաշտում, որոնց դա պետք է։

pfSense 2.5 և ավելի նոր տարբերակներում OpenVPN հաճախորդի օրինակի համար օրինակի Default Gateway կարգավորումը որոշում է՝ արդյոք թունելը ընդհանրապես փոխարինում է համակարգի լռելյայն երթուղին։ Կանոնով քաղաքականության երթուղավորումն իրեն սպասվածի պես է պահում միայն այն ժամանակ, երբ ձեր ենթադրած երթուղին իսկապես տեղադրված է։ Փոփոխությունից հետո ստուգեք Status > Gateways-ը՝ թունելի կարգավիճակի պատկերակին վստահելու փոխարեն։

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

Փակեք այն ուղիները, որոնք թունելը երբեք չի ունեցել

Նախ DNS արտահոսքերը։ Լուծիչը շարունակում է պատասխանել WAN-ում և այնտեղից դուրս փոխանցել, ուստի անունները շարունակում են լուծվել ISP-ի միջով, մինչդեռ երթևեկությունը գամված է թունելին։ Սահմանափակեք լուծիչի ելքային ինտերֆեյսները, հրեք ներքին լուծիչը հաճախորդներին և արգելափակեք 53 պորտը մնացած ամեն ինչի համար միայն-VPN VLAN-ներում։

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

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

Փորձարկեք անկումը, թրթռոցը և վերադարձի ուղին

Քաշեք հիմնականը անվնաս երթևեկության ընթացքում, ապա կարդացեք չորս բան․ Status > Gateways խմբի անդամների վիճակների համար, pfctl -ss հին դարպասին դեռ գամված վիճակների համար, traceroute հաճախորդից ելքի ուղու համար, և լուծիչի հարցում՝ տեսնելու, թե որ սերվերն է պատասխանել։

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

Վերջում հաստատեք, որ դեռ կարող եք կառավարել երթուղիչը։ Պահեք ժապավենից դուրս ուղի, օրինակ՝ կոնսոլի մալուխ, կառավարման VLAN կամ բջջային մոդեմ։ Ձեզ դուրս փակող failover թեստը թեստ է, որը չեք կարող ավարտել, և անհասանելի երթուղիչը չի կարող ինքնուրույն վերադառնալ։

Նախքան քաղաքականությունը պատրաստ հայտարարելը, դուք պետք է կարողանաք պատասխանել չորս հարցի՝ առանց տերմինալ բացելու․ որ VLAN-ները կարող են օգտվել WAN-ից, քանի դեռ թունելը անջատված է, ինչ է հսկում դետեկտորը և որքան է սպասում, որ անվանասերվերներն ու IPv6 երթուղիները շարժվում են ուղիի հետ, և ինչպես եք վերադառնում, եթե պահուստը նույնպես ձախողվի։ Եթե որևէ պատասխան «ինչ լռելյայնն էր» է, քաղաքականությունը դեռ պատկանում է երթուղիչին, ոչ ձեզ։