Ali se lahko odjemalci na dveh strežnikih OpenVPN dosežejo med seboj?

Postavitev drugega OpenVPN strežnika vam da drugo mesto, kamor se odjemalci lahko povežejo, in nič več. Teh odjemalcev ne postavi v omrežje prvega strežnika, možnost z imenom client-to-client pa spremeni le posredovanje znotraj enega procesa strežnika. Bazena postaneta eno omrežje, ko med njima namerno usmerjate, z lastnikom za vsako smer. Vse spodaj predpostavlja način TUN v uporabniškem prostoru z izklopljenim tem notranjim posredovanjem, tako da odločitev sprejme jedro.

Mit: en seznam računov, eno omrežje

Preverjanje pristnosti in dosegljivost se zamenjujeta, ker oboje živi v konfiguraciji strežnika. Uporabnik, ki se lahko prijavi na katero koli od dveh prehodov, je od zunaj videti kot uporabnik enega sistema z dvojimi vrati. Znotraj vsak strežnik dodeljuje naslove iz svojega bazena in namešča poti le za odjemalce, ki jih zaključi. Zato odjemalec na prehodu A, ki pošlje paket odjemalcu na prehodu B, zahteva cilj, o katerem njegov lastni strežnik ni nikoli slišal. Paket gre na privzeto pot A, zapusti tunel in prispe do požarnega zidu, ki ni bil nikoli zaprošen, da bi ga prepustil.

Dodajanje drugega strežnika torej ne doda redundance, odkrivanja ali skupne oddajne domene. Doda usmerjeno omrežje, ki potrebuje načrt, in načrt se začne z naslavljanjem.

Vsakemu prehodu dajte svoj bazen in tranzitni naslov

Dva obsega, ki se ne smeta prekrivati z ničimer drugim, plus majhna tranzitna povezava med gostitelji, je celoten načrt naslovov. Tranzit držite na zasebnem segmentu, ki ga nadzorujete, in zapišite številke, preden kateri koli strežnik izda zakup.

Uprite se skušnjavi, da bi obema strežnikoma dali isti bazen, da bi profili ostali enaki. Pot jedra ne more povedati, kateri od dveh gostiteljev trenutno poseduje poljuben naslov v skupnem obsegu, zato bi usmerjevalna tabela kazala na en prehod, odjemalec pa bi bil lahko priključen na drugega. Imena vmesnikov so lokalne konvencije, ne skupno stanje. Oba gostitelja tukaj tunelsko napravo imenujeta tun0, tranzitno povezavo pa transit0, kar je v redu, ker noben paket ne nosi teh imen.

Namestite pot na obeh straneh

Vsak prehod potrebuje pot do bazena drugega prek tranzitnega naslova, posredovanje pa mora biti vklopljeno, da lahko kateri koli deluje kot skok. Najprej preverite trenutno tabelo, nato dodajte vnos in ga naredite trajnega prek omrežnega upravitelja gostitelja, ne prek kaveljčka za ponovno povezavo.

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

Zrcalite to na drugem gostitelju z zamenjanimi bazeni. Večkratno dodajanje iste poti iz nepovezane skripte je način, da gostitelj konča z več kopijami in skrivnostno spremembo, ko naslednjič kdo prebere tabelo. Če je tranzitna povezava sama tunel, pot kaže na topologijo tega tunela in skok mora preživeti njegovo ponovno povezavo. Tranzitni naslov, ki izgine za trideset sekund, s seboj vzame pot med bazenoma, kar je lastnost zasnove, ki jo je vredno izgovoriti, ne odkriti.

Potisnite pot odjemalca brez pretvarjanja lastništva

Odjemalci potrebujejo pot do oddaljenega bazena, sicer njihov lastni operacijski sistem pošlje paket na privzeti prehod in tunel ga nikoli ne vidi. Konfiguracija strežnika je naravno mesto za dostavo.

push "route 10.64.20.0 255.255.255.0"

V konfiguracijo drugega strežnika vstavite zrcalno vrstico, nato znova povežite preskusnega odjemalca in preberite njegovo tabelo. Odjemalec, ki ignorira potisnjene poti, potrebuje svojo odobreno konfiguracijo, pot, ki nikoli ne prispe, pa ni nadzor dostopa. Odjemalcu ne dajte iroute za celoten bazen drugega prehoda. Ta direktiva obstaja za podomrežje za enim povezanim odjemalcem, njena uporaba za prekrivanje manjkajoče poti med prehodi pa ustvari strežnik, ki verjame, da ima naslove, do katerih ne more priti.

Dokažite eno zahtevo in zavrnite drugo

Izberite resnično operacijo, na primer HTTPS od odjemalca na 10.64.10.21 do storitve na 10.64.20.37, in na obeh gostiteljih dovolite točno to. Vsak požarni zid prepusti zahtevo na vhodni strani in sledeni odgovor na povratni; politika same ciljne storitve jo mora še vedno sprejeti.

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

Pri vzajemnih poteh je izvorni NAT nepotreben in tukaj dejaven škodljiv: prevajanje izvora skrije, kateri odjemalec je poslal zahtevo, in uniči politiko na podlagi izvora na strani cilja. Preverite, da obstoječe pravilo masquerade za izhod v internet ne ujame tudi te poti. Nato preskusite zavrnitev. Storitev, ki mora ostati lokalna v bazenu B, mora ostati nedosegljiva iz bazena A, preskusiti pa je treba tudi pare odjemalcev na istem prehodu, saj politika posredovanja, ki ste jo pravkar spremenili, velja tudi zanje.

Še en popravek miselnega modela: tranzitna povezava prenaša dešifrirane notranje pakete, zato je meja zaupanja in ne zasebno jamstvo. Če prečka omrežje, ki ga ne nadzorujete, zaščitite ta skok z odobrenim šifriranim tunelom in usmerjajte po njegovi resnični topologiji. TLS od konca do konca še vedno sam preverja aplikacijo, zato naj notranja storitev to še naprej uporablja.