Առանձին ելք՝ VPN լողավազան usb0-ի վրա, դարպասի երթևեկությունը՝ eth0-ի

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

Համոզվեք, որ աղբյուրի հասցեն պահպանվում է մինչև երթուղավորման որոշումը

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

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

Սկսեք գրի առնել իրական արժեքները՝ լողավազանի նախածանցը, այն կրող թունելի միջերեսը, երկրորդ WAN-ի հասցեն և հաջորդ ցատկը, և այն աղյուսակի համարը, որը մտադիր եք օգտագործել։ Մաքրեք նախորդ ցանկացած փորձի հին կանոնները նախքան նորերը ավելացնելը, քանի որ տարբեր առաջնահերթություններով կրկնվող կանոնները առաջացնում են պատահական թվացող խափանումներ։

Կառուցեք ընտրված աղյուսակ, որը ամբողջական է

Աղյուսակը լռելյայն ուղի չէ ընկերոջ հետ։ Դրան բավականաչափ ուղիներ են պետք, որպեսզի յուրաքանչյուր որոնում լուծվի դրա ներսում, ներառյալ WAN ենթացանցի միացված ուղին, որպեսզի հաջորդ ցատկը հասանելի լինի։ tun1-ի վրա 10.77.0.0/24 լողավազանի, 203.0.113.1 հաջորդ ցատկով 203.0.113.20/24 WAN հասցեի և 600 աղյուսակի համար՝

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Կանոնը նստում է ավելի ցածր առաջնահերթությամբ, քան գոյություն ունեցող ցանկացած ամեն ինչ բռնող կանոն, ուստի համապատասխան հաճախորդները նախ հարվածում են 600 աղյուսակին, իսկ մնացած ամեն ինչ ընկնում է հիմնական աղյուսակ։ ip-rule-ի տեղեկագիրը ամբողջությամբ նկարագրում է կարգավորված որոնման մոդելը և ընտրիչի շարահյուսությունը։

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

Պահեք լսողի սեփական երթևեկությունը քաղաքականությունից դուրս

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

Հակադարձ ուղու զտումը նույն պատճառով ուշադրության արժանի է։ Երբ հաճախորդներին պատասխանները դուրս են գալիս usb0-ով, մինչ հարցումը եկել է այլ կապով, խիստ rp_filter կարգավորումը կարող է գցել փաթեթներ, որոնք երթուղավորման քաղաքականությունը վավեր է համարում։ Ստուգեք երկու միջերեսների գործող sysctl արժեքները նախքան եզրակացնելը, որ կանոնը ձախողվել է։

Հերթականությունը նույնպես կարևոր է սարքի մնացած ամեն ինչի նկատմամբ։ Docker-ի կամուրջները, երկրորդ VPN-ը և մատակարարի պատկերից արդեն գոյություն ունեցող ցանկացած կանոն ավելացնում են առաջնահերթություններ, ուստի կարդացեք կանոնների ամբողջ ցանկը՝ փոխարենը չենթադրելով, որ 100 առաջնահերթությունը մենակ է։

Համապատասխանեցրեք փոխանցումը և թարգմանությունը ուղու հետ

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

Եթե երկրորդ WAN-ը մասնավոր լողավազանը ձեզ մոտ հետ չի երթուղավորի, թարգմանեք աղբյուրը այդ ելքում։ Դինամիկ հասցեով միջերեսի համար սովորական ընտրություն է նեղ masquerade կանոնը՝ սահմանափակված լողավազանով և միջերեսով:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

Թունելի ծախսվածությունը նույնպես ուշադրություն է պահանջում, երբ ուղիները տարբերվում են։ Եթե հաճախորդները բանակցում են մեծ TCP MSS, իսկ այլընտրանքային WAN-ն ունի ավելի ցածր MTU կամ իր ներսում թունել, ապա մեծ սեգմենտները կանգ են առնում, մինչ փոքրերը աշխատում են։ Փոխանցման ուղու վրա MSS-ի սեղմումը դա դարձնում է կանխատեսելի վարքագիծ՝ ընդհատվող կախվելու փոխարեն։

Որոշեք, թե ինչ է լինում, երբ usb0-ն անհետանում է

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

Որտեղ այդ հետընկնումն անընդունելի է, 600 աղյուսակում ավելացրեք բացահայտ տերմինալ ուղի, օրինակ՝ blackhole լռելյայն, կամ միջերեսն անջատված ժամանակ լողավազանը գցեք հրապատում։ Երկուսից ցանկացածը որոշում է, որը կարող եք գրի առնել. լռությունը՝ ոչ։

Կայունությունը վերջին կետն է։ Ով էլ տիրապետի երկու կապերին՝ լինի դա ցանցի կառավարիչ, ուղարկող սկրիպտ, թե կապի կենսացիկլ, պետք է յուրաքանչյուր վերամիացման ժամանակ վերստեղծի ուղիներն ու կանոնը՝ առանց կրկնօրինակներ ավելացնելու։ Ստուգեք իրական հաճախորդի հարցումով և դարպասից առանձին հարցումով, հաստատեք դիտված ելքը երկուսում, ապա քաշեք երկրորդ WAN-ը և տեսեք, թե ձեր նախագծած երկու արդյունքներից որն է իրականում տեղի ունենում։ IPv6-ին պետք է իր աղյուսակը, կանոնը և թարգմանությունը. վերևի IPv4 կանոնը դրա մասին ոչինչ չի ասում։