Pääsevätkö kahden OpenVPN-palvelimen asiakkaat toistensa luo?

Toisen OpenVPN palvelimen pystyttäminen antaa asiakkaille toisen paikan yhdistää, eikä mitään muuta. Se ei tuo asiakkaita ensimmäisen palvelimen verkkoon, ja client-to-client-niminen asetus muuttaa vain edelleenlähetystä yhden palvelinprosessin sisällä. Kahdesta ryhmästä tulee yksi verkko, kun reitität niiden välillä tarkoituksella, omistaja kummallekin suunnalle. Kaikki alla olettaa käyttäjätilan TUN-tilan, jossa tuo sisäinen edelleenlähetys on pois päältä, joten ydin tekee päätöksen.

Myytti: yksi tuntilista, yksi verkko

Todennus ja tavoitettavuus sekoittuvat, koska molemmat asuvat palvelimen määrityksessä. Käyttäjä, joka voi kirjautua kumpaan tahansa yhdyskäytävään, näyttää ulkopuolelta yhden järjestelmän käyttäjältä, jossa on kaksi ovea. Sisällä kumpikin palvelin jakaa osoitteita omasta ryhmästään ja asentaa reitit vain niille asiakkaille, jotka se lopettaa. Niinpä yhdyskäytävällä A oleva asiakas, joka lähettää paketin yhdyskäytävällä B olevalle asiakkaalle, pyytää kohdetta, josta sen oma palvelin ei ole koskaan kuullut. Paketti menee A:n oletusreitille, poistuu tunnelista ja saapuu palomuuriin, jota ei koskaan pyydetty sallimaan sitä.

Toisen palvelimen lisääminen ei siis lisää redundanssia, löytämistä tai jaettua lähetysaluetta. Se lisää reititetyn verkon, joka tarvitsee suunnitelman, ja suunnitelma alkaa osoitteistuksesta.

Anna kummallekin yhdyskäytävälle oma ryhmä ja transit-osoite

Kaksi aluetta, jotka eivät voi mennä päällekkäin minkään muun kanssa, sekä pieni transit-linkki isäntien välillä – siinä koko osoitesuunnitelma. Pidä transit sellaisessa yksityisessä segmentissä, jota hallitset, ja kirjoita numerot muistiin ennen kuin mikään palvelin jakaa vuokran.

Vastusta kiusausta antaa molemmille palvelimille sama ryhmä, jotta profiilit pysyvät samanlaisina. Ytimen reitti ei voi kertoa, kumpi kahdesta isännästä tällä hetkellä omistaa mielivaltaisen osoitteen jaetun alueen sisällä, joten reititystaulu osoittaisi toiselle yhdyskäytävälle ja asiakas voisi olla kiinnitetty toiselle. Liitäntöjen nimet ovat paikallisia käytäntöjä, eivät jaettua tilaa. Molemmat isännät kutsuvat tunnelilaitetta tun0 ja transit-linkkiä transit0, mikä on kunnossa, koska mikään paketti ei kanna näitä nimiä.

Asenna reitti molemmille puolille

Kumpikin yhdyskäytävä tarvitsee reitin toisen ryhmään transit-osoitteen kautta, ja edelleenlähetyksen on oltava päällä, jotta kumpikin voi toimia hyppynä. Vahvista ensin nykyinen taulu, lisää sitten merkintä ja tee siitä pysyvä isännän verkkohallinnan kautta uudelleenyhdistämiskoukun sijaan.

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

Peilaa sama toiselle isännälle ryhmät vaihdettuina. Saman reitin toistuva lisääminen asiaankuulumattomasta skriptistä on tapa, jolla isäntä päätyy useisiin kopioihin ja seuraavalla taulun lukukerralla arvoitukselliseen muutokseen. Jos transit-linkki on itse tunneli, reitti osoittaa sen topologiaan ja hypyn on selvittävä sen uudelleenyhdistämisestä. Transit-osoite, joka katoaa kolmeksikymmeneksi sekunniksi, vie mukanaan ryhmien välisen polun, mikä on suunnitteluominaisuus, joka kannattaa julistaa eikä löytää.

Työnnä asiakkaan reitti teeskentelemättä omistusta

Asiakkaat tarvitsevat reitin etäryhmään, muuten heidän oma käyttöjärjestelmänsä lähettää paketin oletusyhdyskäytäväänsä eikä tunneli näe sitä koskaan. Palvelimen määritys on luonnollinen paikka toimittaa se.

push "route 10.64.20.0 255.255.255.0"

Laita peilirivi toisen palvelimen määritykseen, yhdistä sitten testiasiakas uudelleen ja lue sen taulu. Asiakas, joka jättää työnnetyt reitit huomiotta, tarvitsee oman hyväksytyn määrityksensä, eikä reitti, joka ei koskaan saavu, ole käyttöoikeuden valvontaa. Älä anna asiakkaalle iroute-direktiiviä toisen yhdyskäytävän koko ryhmälle. Se direktiivi on tarkoitettu yhden yhdistetyn asiakkaan takana olevalle aliverkolle, ja sen käyttäminen puuttuvan yhdyskäytävien välisen reitin peittämiseen tuottaa palvelimen, joka uskoo omistavansa osoitteita, joihin se ei pääse.

Todista yksi pyyntö ja hylkää toinen

Valitse todellinen toiminto, esimerkiksi HTTPS asiakkaalta osoitteessa 10.64.10.21 palveluun osoitteessa 10.64.20.37, ja salli täsmälleen se molemmilla isännillä. Kukin palomuuri hyväksyy pyynnön saapuvalla puolellaan ja seuratun vastauksen paluupuolella; kohteen oma palvelukäytäntö on silti hyväksyttävä se.

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

Vastavuoroisilla reiteillä lähde-NAT on tarpeeton ja tässä aktiivisesti haitallinen: lähteen kääntäminen kätkee, kuka asiakas pyynnön teki, ja kumoaa lähdeperusteisen käytännön kohdepuolella. Tarkista, ettei olemassa oleva internet-poistumisen masquerade-sääntö nappaa myös tätä polkua. Testaa sitten hylkäys. Palvelun, jonka pitäisi pysyä paikallisena ryhmässä B, on pysyttävä tavoittamattomana ryhmästä A, ja myös saman yhdyskäytävän asiakaspareja on testattava, koska juuri muuttamasi edelleenlähetyskäytäntö koskee myös niitä.

Vielä yksi korjaus mielen malliin: transit-linkki kuljettaa salattuja sisäisiä paketteja, joten se on luottamusraja eikä yksityinen tae. Jos se kulkee verkon läpi, jota et hallitse, suojaa tuo hyppy hyväksytyllä salatulla tunnelilla ja reititä sen todellisen topologian kautta. Päästä päähän -TLS todentaa sovelluksen edelleen itse, minkä vuoksi sisäisen palvelun kannattaa jatkaa sen käyttöä.