Երկու OpenVPN հաճախորդ միացնել մեկ Linux հոսթում fwmark-ով

Մեկ Linux հոսթում երկրորդ OpenVPN հաճախորդ ավելացնելը ձախողվում է երկու տեղերից մեկում: Կա՛մ ներքին հաճախորդը չի կարող հասնել իր սերվերին, որովհետև արտաքին թունելը գրավել է այդ տրանսպորտը, կա՛մ երկրորդ հաճախորդը վերագրում է երթուղիների աղյուսակը, և առաջին թունելը դադարում է աշխատել: Երկու խնդիրներն էլ երթուղավորման մեջ են, ոչ գաղտնագրման, և երկուսն էլ լուծվում են նախքան նոր թունելը կտեղափոխի որևէ հավելվածային տրաֆիկ: Այստեղ հասցեները օրինակ են. tun0-ը արտաքին թունելն է, 203.0.113.9-ը՝ ներքին սերվերը, իսկ TCP 9999-ը՝ այն հոսքը, որը պետք է օգտագործի ներքին ուղին:

Ձախողման երկու եղանակ, մեկ երթուղային աղյուսակ

Ներքին հաճախորդը UDP սոքեթ է բացում դեպի իր սերվերը, և այդ սոքեթը հետևում է ընթացիկ երթուղային աղյուսակին ինչպես ցանկացած ուրիշը: Եթե արտաքին թունելն արդեն տիրում է լռելյայնին, ձեռքսեղմման փաթեթները մտնում են արտաքին թունել: Դա աշխատում է միայն այն ժամանակ, երբ արտաքին սերվերը կարող է հասնել ներքին սերվերին, և հակառակ կողմը համաձայնում է կրել հոսքը. հակառակ դեպքում ձեռքսեղմումը կանգ է առնում, և հաճախորդը նորից փորձում է:

Երկրորդ ձախողումը գալիս է սերվերի push-ից: Սովորական push-ը redirect-gateway def1-ն է, որը տեղադրում է 0.0.0.0/1 և 128.0.0.0/1՝ լռելյայն երթուղին փոխարինելու փոխարեն: Ուստի երկու հաճախորդ, որոնցից յուրաքանչյուրը տեղադրում է իր /1 զույգը, բախվում են, և ամենանոր զույգը հաղթում է գրեթե ամեն նպատակակետի համար: Նայեք այդ երկու նախածանցերին աղյուսակում, երբ թունելը մեռնում է երկրորդի միանալուց հետո, որովհետև լռելյայն երթուղին ինքը գուցե երբեք չի փոխվել:

Նշեք հոսքը և տվեք նրան աղյուսակ

Ուղղորդեք ընտրված տրաֆիկը՝ նշելով այն mangle աղյուսակում և համապատասխանեցնելով նշանը քաղաքականության կանոնում: Կանոնը ցույց է տալիս հատուկ աղյուսակի, որի լռելյայն երթուղին ներքին սարքն է, այնպես որ միայն նշված փաթեթներն են գնում ներքին ուղիով:

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Այս կանոնների հավաքածուի ձախողումների մեծ մասը գալիս է երկու սխալից: Firewall-ի սահմանած նշանի արժեքը և կանոնի համապատասխանեցրած արժեքը պետք է նույնը լինեն, որովհետև անհամապատասխանությունը ոչ սխալ է տալիս, ոչ ազդեցություն: Իսկ PREROUTING-ը տեսնում է միայն դրսից եկող փաթեթները, այնպես որ այս հոսթում սկսված կապը պահանջում է նույն համապատասխանությամբ OUTPUT կանոն, նախքան այն ընդհանրապես կնշվի:

Խլեք երթուղիների սեփականությունը երկրորդ հաճախորդից

Երկու տարբերակ թույլ չեն տալիս երկրորդ հաճախորդին խմբագրել աղյուսակը, և նրանք գործում են տարբեր կետերում: route-nopull-ը անտեսում է push-ված երթուղային ընտրանքները, այնպես որ ոչինչ չի տեղադրվում: route-noexec-ը ընդունում է push-ված ընտրանքները հաճախորդի միջավայրում, բայց աղյուսակի փոփոխությունը թողնում է hook-ին, ինչը հենց այն է, ինչ ուզում եք, երբ պետք է տեսնեք, թե ինչ առաջարկեց սերվերը:

Hook-ը գործարկվում է push-ված արժեքներով իր միջավայրում, և այն պետք է ավելացնի միայն ձեր հաստատած գրառումները: Դարձրեք այն idempotent. դատարկեք նրա պատկանող աղյուսակը նախքան վերակառուցելը, և մի՛ ենթադրեք, որ նախորդ գործարկումը մաքուր վիճակ է թողել: Վերամիացումը կրկին կանչում է hook-ը, և առանց մաքրման ավելացնող hook-ը կուտակում է կրկնվող երթուղիներ:

Ընտրեք մեկ սեփականատեր և գրի առեք այն: Պրոֆիլը, որը սահմանում է երկու ընտրանքն էլ, կամ hook-ը, որը մրցում է ձեռքով սկրիպտի հետ, ստեղծում է աղյուսակ, որը ոչ ոք հետագայում չի կարող բացատրել:

Ամրացրեք երկու սերվերների հասցեները

Ներքին սերվերին պետք է հոսթ-երթուղի արտաքին սարքի միջով, նախքան ներքին հաճախորդը կմիանա: Հենց այդ գրառումն է պահում ներքին տրանսպորտը արտաքին թունելի ներսում՝ թույլ չտալով, որ այն հետևի լռելյայնին:

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Ավելացրեք համապատասխան հոսթ-երթուղի նաև արտաքին սերվերի համար հիմնական աղյուսակում, այլապես վերամիացումը կարող է արտաքին հաճախորդի սեփական տրանսպորտը երթուղավորել իր իսկ թունելի մեջ: Հերթականությունը պարտադիր է. ավելացրեք այս գրառումները այն բանից հետո, երբ համապատասխան ինտերֆեյսը գոյություն ունի, այսինքն՝ hook կամ սկրիպտ, որը գործարկվում է միացումից հետո: Անջատված սարքին ուղղված երթուղին հեռացվում է կամ անտեսվում, ուստի բեռնման ժամանակ գրված գրառումը չի դիմանում ձեր ենթադրած հաջորդականությանը:

Ստուգեք որոնումը՝ ամբողջ աղյուսակը կարդալու փոխարեն: Երթուղու որոնման ելքը նշում է սարքը և աղբյուրի հասցեն, որը կօգտագործի kernel-ը, և դա հենց այն է, ինչ հաճախորդը ստանում է, երբ բացում է իր սոքեթը:

Փորձեք շղթան և տեսանելի դարձրեք ձախողումը

Գրավեք արտաքին ինտերֆեյսում, մինչ ներքին հաճախորդը միանում է: Ներքին ձեռքսեղմումը պետք է երևա որպես գաղտնագրված բեռ արտաքին թունելի ներսում. եթե այն երևում է որպես սովորական UDP դեպի 203.0.113.9, ապա հոսթ-երթուղին բացակայում է, և շղթան երբեք չի կառուցվել:

Ամենավատ արդյունքն այն շղթան է, որը լուռ վերադառնում է ֆիզիկական uplink-ին, որովհետև ինտերֆեյսի վիճակը ոչինչ չի հայտարարում, և ներքին տրաֆիկը դուրս է գալիս սխալ աղբյուրի հասցեից: Եթե երկրորդ հաճախորդը կարող է ուղղակիորեն վերամիանալ, երբ արտաքին թունելը ընկնում է, անջատեք այդ ուղին կամ կապեք այն արտաքին ինտերֆեյսին, որպեսզի ձախողումը տեսանելի լինի:

Ավարտեք երկու հոսքով և կանոնների մեկ արտածմամբ. նշված և չնշված կապերը պետք է տարբեր ուղիներ անցնեն, և ip rule show-ը պետք է թվարկի ձեր նախատեսած առաջնահերթությունը: Եթե երկու հոսքերն էլ նույն ուղին են անցնում, նշանը չի կիրառվում այնտեղ, որտեղ դուք կարծում եք: