Ĉu klientoj sur du OpenVPN-serviloj povas atingi unu la alian?

Starigi duan OpenVPN servilon donas al vi duan lokon por klientaj konektoj, kaj nenion pli. Ĝi ne metas tiujn klientojn en la reton de la unua servilo, kaj la opcio nomata client-to-client nur ŝanĝas plusendadon ene de unu servila procezo. La du klientaroj fariĝas unu reto kiam vi intence enkursigas inter ili, kun posedanto por ĉiu direkto. Ĉio sube supozas TUN-reĝimon en uzantspaco kun tiu interna plusendado malŝaltita, do la kerno faras la decidon.

La mito: unu kontolisto, unu reto

Aŭtentigo kaj atingeblo konfuziĝas ĉar ambaŭ loĝas en la servila agordo. Uzanto, kiu povas ensaluti ĉe ajna el la du enirejoj, de ekstere aspektas kiel uzanto sur unu sistemo kun du pordoj. Interne, ĉiu servilo disdonas adresojn el sia propra klientaro kaj instalas vojojn nur por la klientoj, kiujn ĝi finas. Do kliento ĉe enirejo A, kiu sendas paketon al kliento ĉe enirejo B, petas celon, pri kiu ĝia propra servilo neniam aŭdis. La paketo iras al la kutima vojo de A, forlasas la tunelon kaj alvenas ĉe fajroŝirmilo, kiun oni neniam petis permesi ĝin.

Aldoni duan servilon do ne aldonas redundon, malkovron aŭ komunan dissendan domajnon. Ĝi aldonas enkursigitan reton, kiu bezonas planon, kaj la plano komenciĝas per adresado.

Donu al ĉiu enirejo sian propran klientaron kaj transitan adreson

Du gamoj, kiuj ne povas interkovri ion alian, plus malgranda transita ligo inter la gastigantoj, estas la tuta adresa plano. Tenu la transiton sur privata segmento, kiun vi kontrolas, kaj skribu la nombrojn antaŭ ol ajna servilo donos luon.

Rezistu la tenton doni al ambaŭ serviloj la saman klientaron, por ke la profiloj restu identaj. Kerna vojo ne povas diri, kiu el du gastigantoj nun posedas arbitran adreson ene de komuna gamo, do la enkursiga tabelo montrus al unu enirejo kaj la kliento povus esti ligita al la alia. Interfacaj nomoj estas lokaj konvencioj, ne komuna stato. Ambaŭ gastigantoj ĉi tie nomas la tunelan aparaton tun0 kaj la transitan ligon transit0, kio estas en ordo ĉar neniu paketo portas tiujn nomojn.

Instalu la vojon ambaŭflanke

Ĉiu enirejo bezonas vojon al la klientaro de la alia tra la transita adreso, kaj plusendado devas esti ŝaltita por ke iu ajn agu kiel salto. Unue konfirmu la nunan tabelon, poste aldonu la eron kaj daŭrigu ĝin per la retadministrilo de la gastiganto anstataŭ per rekonekta hoko.

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

Spegulu tion sur la alia gastiganto kun interŝanĝitaj klientaroj. Ripete aldoni la saman vojon el nerrilata skripto estas kiel gastiganto finas kun pluraj kopioj kaj mistera ŝanĝo la venontan fojon, kiam iu legas la tabelon. Se la transita ligo mem estas tunelo, la vojo montras al la topologio de tiu tunelo kaj la salto devas travivi ĝian rekonekton. Transita adreso, kiu malaperas dum tridek sekundoj, kunportas la vojon inter la klientaroj, kio estas dezajna eco inda je deklaro anstataŭ malkovro.

Puŝu la klientan vojon sen ŝajnigi posedon

Klientoj bezonas vojon al la fora klientaro, alie ilia propra operaciumo sendas la paketon al sia kutima enirejo kaj la tunelo neniam vidas ĝin. La servila agordo estas la natura loko por liveri tion.

push "route 10.64.20.0 255.255.255.0"

Metu la spegulan linion en la agordon de la alia servilo, poste rekonektu testan klienton kaj legu ĝian tabelon. Kliento, kiu ignoras puŝitajn vojojn, bezonas sian propran aprobitan agordon, kaj vojo, kiu neniam alvenas, ne estas alirkontrolo. Ne donu al kliento iroute por la tuta klientaro de la alia enirejo. Tiu direktivo ekzistas por subreto malantaŭ unu konektita kliento, kaj uzi ĝin por kovri mankan vojon inter enirejoj produktas servilon, kiu kredas posedi adresojn, kiujn ĝi ne povas atingi.

Pruvu unu peton kaj rifuzu alian

Elektu realan operacion, ekzemple HTTPS de kliento ĉe 10.64.10.21 al servo ĉe 10.64.20.37, kaj permesu precize tion sur ambaŭ gastigantoj. Ĉiu fajroŝirmilo akceptas la peton sur sia envena flanko kaj la spuritan respondon sur la reena flanko; la propra serva politiko de la celo ankoraŭ devas akcepti ĝin.

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

Kun reciprokaj vojoj, fonta NAT estas nenecesa kaj ĉi tie aktive malutila: traduki la fonton kaŝas, kiu kliento faris la peton, kaj venkas fontbazitan politikon ĉe la cela flanko. Kontrolu, ke ekzistanta maskadregulo por interreta eliro ankaŭ ne kaptas ĉi tiun vojon. Poste testu la rifuzon. Servo, kiu devas resti loka al klientaro B, devas resti neatingebla el klientaro A, kaj ankaŭ klientparoj ĉe la sama enirejo bezonas testadon, ĉar la plusenda politiko, kiun vi ĵus ŝanĝis, validas ankaŭ por ili.

Ankoraŭ unu korekto al la mensa modelo: la transita ligo portas malĉifritajn internajn paketojn, do ĝi estas fido-limo, ne privata garantio. Se ĝi transiras reton, kiun vi ne kontrolas, protektu tiun salton per aprobita ĉifrita tunelo kaj enkursigu tra ĝia reala topologio. End-to-end TLS ankoraŭ aŭtentigas la aplikaĵon mem, tial la interna servo devus daŭre uzi ĝin.