İki OpenVPN serverindəki müştərilər bir-birinə çata bilərmi?

İkinci OpenVPN serveri qurmaq müştərilərin qoşulması üçün ikinci yer verir və başqa heç nə. O, bu müştəriləri birinci serverin şəbəkəsinə qoymur və client-to-client adlı seçim yalnız tək server prosesi daxilində yönləndirməni dəyişir. İki hovuz yalnız onlar arasında qəsdən marşrutlaşdırdıqda, hər istiqamət üçün bir sahiblə tək şəbəkəyə çevrilir. Aşağıdakıların hamısı istifadəçi fəzasında TUN rejimini və həmin daxili yönləndirmənin söndürülməsini fərz edir, beləliklə qərarı nüvə verir.

Mif: bir hesab siyahısı, bir şəbəkə

Autentifikasiya və əlçatanlıq qarışdırılır, çünki ikisi də server konfiqurasiyasında yaşayır. İki şlüzdən hər hansı birinə daxil ola bilən istifadəçi kənardan iki qapısı olan tək sistemdəki istifadəçi kimi görünür. İçəridə hər server öz hovuzundan ünvanlar paylayır və yalnız sonlandırdığı müştərilər üçün marşrutlar quraşdırır. Beləliklə, A şlüzündəki müştəri B şlüzündəki müştəriyə paket göndərdikdə öz serverinin heç vaxt eşitmədiyi ünvanı istəyir. Paket A-nın standart marşrutuna gedir, tuneldən çıxır və icazə vermək heç vaxt tələb olunmamış firewall-a çatır.

Deməli, ikinci server əlavə etmək artıqlıq, kəşf və ya ortaq yayım domeni əlavə etmir. O, plan tələb edən marşrutlaşdırılmış şəbəkə əlavə edir və plan ünvanlamadan başlayır.

Hər şlüzə öz hovuzunu və tranzit ünvanını verin

Başqa heç nə ilə üst-üstə düşməyən iki diapazon və hostlar arasında kiçik tranzit keçidi bütün ünvan planıdır. Tranziti nəzarət etdiyiniz özəl seqmentdə saxlayın və hər hansı server icarə versiyasından əvvəl nömrələri yazın.

Profillərin eyni qalması üçün hər iki serverə eyni hovuzu vermək cazibəsinə müqavimət göstərin. Nüvə marşrutu ortaq diapazon daxilində ixtiyari ünvanın hal-hazırda iki hostdan hansına aid olduğunu deyə bilməz, buna görə marşrut cədvəli bir şlüzü göstərərdi və müştəri digərinə qoşulmuş ola bilərdi. İnterfeys adları yerli konvensiyalardır, ortaq vəziyyət deyil. Buradakı hər iki host tunel cihazını tun0 və tranzit keçidini transit0 adlandırır, bu da qaydasındadır, çünki heç bir paket bu adları daşımır.

Marşrutu hər iki tərəfə quraşdırın

Hər şlüzə digərinin hovuzu üçün tranzit ünvanı vasitəsilə marşrut lazımdır və hər hansı birinin hop kimi çıxış etməsi üçün yönləndirmə aktiv olmalıdır. Əvvəlcə mövcud cədvəli təsdiqləyin, sonra qeydi əlavə edin və onu yenidən qoşulma qarmağı yerinə hostun şəbəkə meneceri vasitəsilə davamlı edin.

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

Hovuzları dəyişdirərək bunu digər hostda təkrarlayın. Eyni marşrutu əlaqəsiz skriptdən təkrar-təkrar əlavə etmək hostun bir neçə nüsxə və cədvəli növbəti dəfə oxuyan şəxs üçün sirrli dəyişikliklə qalmasının yoludur. Tranzit keçidi özü tuneldirsə, marşrut həmin tunelin topologiyasına yönəlir və hop onun yenidən qoşulmasına tab gətirməlidir. Otuz saniyə yoxa çıxan tranzit ünvanı hovuzlararası yolu da özü ilə aparır ki, bu da kəşf etmək əvəzinə bəyan etməyə dəyən dizayn xassəsidir.

Müştəri marşrutunu sahibliyi saxtalaşdırmadan ötürün

Müştərilərə uzaq hovuz üçün marşrut lazımdır, əks halda öz əməliyyat sistemi paketi standart şlüzünə göndərir və tunel onu heç görmür. Server konfiqurasiyası bunu çatdırmaq üçün təbii yerdir.

push "route 10.64.20.0 255.255.255.0"

Güzgü sətrini digər serverin konfiqurasiyasına qoyun, sonra test müştərisini yenidən qoşun və cədvəlini oxuyun. Ötürülən marşrutları nəzərə almayan müştəriyə öz təsdiqlənmiş konfiqurasiyası lazımdır və heç vaxt gəlməyən marşrut giriş nəzarəti deyil. Müştəriyə digər şlüzün bütün hovuzu üçün iroute verməyin. Bu direktiv bir qoşulmuş müştərinin arxasındakı alt şəbəkə üçündür və ondan çatışmayan şlüzlərarası marşrutu örtmək üçün istifadə etmək çata bilmədiyi ünvanlara sahib olduğuna inanan bir server yaradır.

Bir sorğunu sübut edin, digərini rədd edin

Real əməliyyat seçin, məsələn 10.64.10.21-dəki müştəridən 10.64.20.37-dəki xidmətə HTTPS və hər iki hostda məhz buna icazə verin. Hər firewall sorğunu giriş tərəfində, izlənən cavabı isə qayıdış tərəfində qəbul edir; təyinatın öz xidmət siyasəti hələ də onu qəbul etməlidir.

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

Qarşılıqlı marşrutlarla mənbə NAT lazımsızdır və burada aktiv şəkildə zərərlidir: mənbəni tərcümə etmək hansı müştərinin sorğu göndərdiyini gizlədir və təyinat tərəfində mənbəyə əsaslanan siyasəti məğlub edir. İnternet çıxışı üçün mövcud masquerade qaydasının bu yolu da tutmadığını yoxlayın. Sonra rəddi sınaqdan keçirin. B hovuzunda yerli qalmalı olan xidmət A hovuzundan əlçatmaz qalmalıdır və eyni şlüzdəki müştəri cütləri də sınaqdan keçirilməlidir, çünki yenicə dəyişdirdiyiniz yönləndirmə siyasəti onlara da aiddir.

Zehni modelə daha bir düzəliş: tranzit keçidi deşifrə edilmiş daxili paketləri daşıyır, yəni özəl zəmanətdən çox etimad sərhədidir. Nəzarət etmədiyiniz şəbəkədən keçirsə, həmin hopu təsdiqlənmiş şifrəli tunellə qoruyun və onun real topologiyası ilə marşrutlaşdırın. Uçdan uca TLS hələ də tətbiqi özü autentifikasiya edir, buna görə daxili xidmət ondan istifadə etməyə davam etməlidir.