Կարո՞ղ են երկու OpenVPN սերվերների հաճախորդները հասնել միմյանց։

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

Առասպելը՝ մեկ հաշիվների ցանկ, մեկ ցանց

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

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

Տվեք յուրաքանչյուր դարպասի իր լողավազանը և տրանզիտային հասցեն

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

Դիմադրեք գայթակղությանը տալ երկու սերվերին նույն լողավազանը, որպեսզի պրոֆիլները մնան նույնական։ Միջուկի երթուղին չի կարող ասել, թե երկու հոսթերից որն է ներկայումս տիրապետում ընդհանուր տիրույթի ներսում կամայական հասցեի, ուստի երթուղային աղյուսակը կմատնանշեր մեկ դարպասի, իսկ հաճախորդը կարող էր կցված լինել մյուսին։ Ինտերֆեյսի անունները տեղական պայմանավորվածություններ են, ոչ թե ընդհանուր վիճակ։ Այստեղ երկու հոսթերն էլ թունելային սարքը կոչում են tun0, իսկ տրանզիտային կապը՝ transit0, ինչը նորմալ է, քանի որ ոչ մի փաթեթ չի կրում այդ անունները։

Տեղադրեք երթուղին երկու կողմերում

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

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

Հաճախորդներին պետք է երթուղի դեպի հեռավոր լողավազանը, այլապես նրանց սեփական օպերացիոն համակարգը փաթեթն ուղարկում է իր լռելյայն դարպասին, և թունելը երբեք չի տեսնում այն։ Սերվերի կազմաձևը դա հասցնելու բնական տեղն է։

push "route 10.64.20.0 255.255.255.0"

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

Ապացուցեք մեկ հարցում և մերժեք մյուսը

Ընտրեք իրական գործողություն, օրինակ՝ HTTPS 10.64.10.21-ի հաճախորդից դեպի 10.64.20.37-ի ծառայություն, և թույլատրեք հենց դա երկու հոսթերում։ Յուրաքանչյուր պատնեշ ընդունում է հարցումն իր ներքին կողմում և հետևված պատասխանը՝ վերադարձի կողմում. նպատակակետի սեփական ծառայության քաղաքականությունը դեռ պետք է ընդունի այն։

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

Եվս մեկ ուղղում մտավոր մոդելին. տրանզիտային կապը կրում է գաղտնազերծված ներքին փաթեթներ, ուստի այն վստահության սահման է, ոչ թե մասնավոր երաշխիք։ Եթե այն անցնում է ձեր չվերահսկվող ցանցով, պաշտպանեք այդ ցատկը հաստատված գաղտնագրված թունելով և երթուղավորեք նրա իրական տոպոլոգիայով։ Ծայրից ծայր TLS-ը դեռ ինքն է վավերացնում հավելվածը, այդ պատճառով ներքին ծառայությունը պետք է շարունակի օգտագործել այն։