Ar klientai dviejuose OpenVPN serveriuose gali pasiekti vienas kitą?

Antro OpenVPN serverio pastatymas duoda antrą vietą klientams jungtis, ir nieko daugiau. Jis nekelia tų klientų į pirmojo serverio tinklą, o parinktis client-to-client keičia tik persiuntimą viename serverio procese. Du telkiniai tampa vienu tinklu, kai tarp jų maršrutizuojate sąmoningai, kiekvienai krypčiai turint atsakingą asmenį. Viskas žemiau daro prielaidą, kad naudojamas vartotojo erdvės TUN režimas ir tas vidinis persiuntimas išjungtas, todėl sprendimą priima branduolys.

Mitas: vienas paskyrų sąrašas, vienas tinklas

Autentifikavimas ir pasiekiamumas painiojami, nes abu gyvena serverio konfigūracijoje. Vartotojas, kuris gali prisijungti prie bet kurių vartų, iš išorės atrodo kaip vienos sistemos su dvejomis durimis vartotojas. Viduje kiekvienas serveris dalija adresus iš savo telkinio ir instaliuoja maršrutus tik tiems klientams, kurių sesiją užbaigia. Taigi klientas prie vartų A, siųsdamas paketą klientui prie vartų B, prašo paskirties, apie kurią jo paties serveris niekada negirdėjo. Paketas eina numatytuoju A maršrutu, palieka tunelį ir pasiekia užkardą, kurios niekada nebuvo paprašyta jį praleisti.

Todėl antro serverio pridėjimas neprideda pertekliaus, aptikimo ar bendro transliacijos domeno. Jis prideda maršrutizuotą tinklą, kuriam reikia plano, o planas prasideda adresavimu.

Duokite kiekvieniems vartams savo telkinį ir tranzito adresą

Du diapazonai, kurie negali persidengti su niekuo kitu, ir nedidelė tranzito jungtis tarp hostų – tai visas adresų planas. Laikykite tranzitą privačiame segmente, kurį kontroliuojate, ir užsirašykite skaičius prieš bet kuriam serveriui išduodant nuomą.

Atsispirkite pagundai duoti abiem serveriams tą patį telkinį, kad profiliai liktų vienodi. Branduolio maršrutas negali pasakyti, kuris iš dviejų hostų šiuo metu valdo savavališką adresą bendrame diapazone, todėl maršrutų lentelė rodytų į vienus vartus, o klientas galėjo būti prijungtas prie kitų. Sąsajų pavadinimai yra vietinės konvencijos, o ne bendra būsena. Abiejų hostų tunelio įrenginys čia vadinamas tun0, o tranzito jungtis – transit0, ir tai gerai, nes joks paketas neneša šių pavadinimų.

Įdiekite maršrutą abiejose pusėse

Kiekvieni vartai turi turėti maršrutą į kito telkinį per tranzito adresą, o persiuntimas turi būti įjungtas, kad bet kurie galėtų veikti kaip šuolis. Pirmiausia patvirtinkite dabartinę lentelę, tada pridėkite įrašą ir padarykite jį nuolatinį per hosto tinklo tvarkyklę, o ne perjungimo kabliuką.

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

Pakartokite tai kitame hoste su sukeistais telkiniais. Pakartotinis to paties maršruto pridėjimas iš nesusijusio scenarijaus yra būdas, kuriuo hostas įgauna kelias kopijas ir paslaptingą pokytį, kai kitą kartą kas nors perskaito lentelę. Jei tranzito jungtis pati yra tunelis, maršrutas rodo į to tunelio topologiją, o šuolis turi išgyventi jo perjungimą. Tranzito adresas, dingstantis trisdešimčiai sekundžių, pasiima ir kelią tarp telkinių, ir tai yra projektavimo savybė, kurią verta deklaruoti, o ne atrasti.

Stumkite kliento maršrutą neapsimetinėdami nuosavybės

Klientams reikia maršruto į nuotolinį telkinį, kitaip jų pačių operacinė sistema siunčia paketą į numatytuosius vartus, ir tunelis jo niekada nemato. Serverio konfigūracija yra natūrali vieta tai pristatyti.

push "route 10.64.20.0 255.255.255.0"

Įdėkite veidrodinę eilutę į kito serverio konfigūraciją, tada iš naujo prijunkite bandymo klientą ir perskaitykite jo lentelę. Klientui, kuris nepaiso stumiamų maršrutų, reikia savo patvirtintos konfigūracijos, o maršrutas, kuris niekada neatvyksta, nėra prieigos kontrolė. Neduokite klientui iroute visam kitų vartų telkiniui. Ši direktyva skirta potinkliui už vieno prijungto kliento, o naudojant ją trūkstamam maršrutui tarp vartų uždengti sukuriamas serveris, kuris tiki valdantis adresus, kurių negali pasiekti.

Įrodykite vieną užklausą ir atmeskite kitą

Pasirinkite realią operaciją, pavyzdžiui, HTTPS iš kliento adresu 10.64.10.21 į paslaugą adresu 10.64.20.37, ir leiskite būtent tai abiejuose hostuose. Kiekviena užkarda priima užklausą savo įeinančioje pusėje ir sekamą atsakymą grįžimo pusėje; paskirties paslaugos politika vis tiek turi ją priimti.

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

Esant abipusiams maršrutams, šaltinio NAT nereikalingas ir čia aktyviai žalingas: šaltinio vertimas paslepia, kuris klientas pateikė užklausą, ir sugriauna šaltiniu pagrįstą politiką paskirties pusėje. Patikrinkite, ar esama maskavimo taisyklė interneto išėjimui nepažymi ir šio kelio. Tada išbandykite atmetimą. Paslauga, kuri turi likti vietinė telkiniui B, turi likti nepasiekiama iš telkinio A, o klientų poras prie tų pačių vartų taip pat reikia išbandyti, nes ką tik pakeista persiuntimo politika galioja ir joms.

Dar vienas pataisymas mąstymo modelyje: tranzito jungtis perneša iššifruotus vidinius paketus, tad tai yra pasitikėjimo riba, o ne privati garantija. Jei ji kerta tinklą, kurio nekontroliuojate, apsaugokite tą šuolį patvirtintu šifruotu tuneliu ir maršrutizuokite per jo tikrąją topologiją. Ištisinis TLS vis tiek pats autentifikuoja programą, todėl vidinė paslauga turėtų ir toliau juo naudotis.