Kinne klanten op twa OpenVPN-tsjinners elkoar berikke?

In twadde OpenVPN tsjinner opsette jout jo in twadde plak dêr’t klanten ferbine kinne, en net mear. It set dy klanten net op it netwurk fan de earste tsjinner, en de opsje mei de namme client-to-client feroaret allinnich trochstjoering binnen ien tsjinnerproses. De twa pools wurde ien netwurk as jo mei opsetsin tusken har rûtearje, mei in eigner foar elke rjochting. Alles hjirûnder giet út fan TUN-modus yn brûkersromte mei dy ynterne trochstjoering útskeakele, sadat de kernel it beslút nimt.

De myte: ien akkountlist, ien netwurk

Autentikaasje en berikberens wurde trochinoar helle om’t beide yn ’e tsjinnerkonfiguraasje libje. In brûker dy’t by ien fan de twa poarten ynlogge kin, liket fan bûten op in brûker op ien systeem mei twa doarren. Binnen jouwt elke tsjinner adressen út syn eigen pool en ynstallearret er allinnich rûtes foar de klanten dy’t er beëiniget. Sa freget in klant op poarte A dy’t in pakket nei in klant op poarte B stjoert om in bestimming dêr’t syn eigen tsjinner nea fan heard hat. It pakket giet nei de standertrûte fan A, ferlitet de tunnel en komt oan by in firewall dy’t nea frege is om it ta te litten.

In twadde tsjinner tafoegje foegt dus gjin oerstalligens, ûntdekking of dield broadcast-domein ta. It foegt in rûtearre netwurk ta dat in plan nedich hat, en it plan begjint mei adressearring.

Jou elke poarte syn eigen pool en transitadres

Twa berikken dy’t neat oars oerlaapje meie, plus in lytse transitferbining tusken de hosts, is it hiele adresplan. Hâld de transit op in priveesegmint dat jo beheare, en skriuw de sifers op foardat ien tsjinner in lease jout.

Wjerstean de ferlieding om beide tsjinners deselde pool te jaan sadat profilen identyk bliuwe. In kernelrûte kin net sizze hokker fan twa hosts op dit stuit in willekeurich adres binnen in dield berik hat, dus de rûtearingstabel soe nei ien poarte wize en de klant kin oan de oare keppele wêze. Ynterface-nammen binne lokale konvinsjes, net dielde steat. Beide hosts hjir neame it tunnelapparaat tun0 en de transitferbining transit0, wat goed is om’t gjin pakket dy nammen draacht.

Ynstallearje de rûte oan beide kanten

Elke poarte hat in rûte nedich foar de pool fan de oare fia it transitadres, en trochstjoering moat oan wêze om ien fan beiden as hop fungearje te litten. Befêstigje earst de hjoeddeiske tabel, foegje dan de ynfier ta en meitsje it duorsum fia de netwurkbehearder fan de host yn stee fan in werferbyningshaak.

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

Spegelje dat op de oare host mei de pools omwiksele. It hieltyd wer tafoegjen fan deselde rûte út in net besibbe skript is hoe’t in host mei ferskate kopyen en in riedseleftige feroaring einiget de folgjende kear as ien de tabel lêst. As de transitferbining sels in tunnel is, wiist de rûte nei de topology fan dy tunnel en de hop moat syn werferbining oerlibje. In transitadres dat tritich sekonden ferdwynt, nimt it paad tusken de pools mei, wat in ûntwerpeigenskip is dy’t it wurdich is om te ferklearjen yn stee fan te ûntdekken.

Skop de klantrûte troch sûnder eigendom te ferfalskjen

Klanten hawwe in rûte nedich foar de fiere pool, oars stjoert har eigen bestjoeringssysteem it pakket nei syn standertpoarte en de tunnel sjocht it nea. De tsjinnerkonfiguraasje is it natuerlike plak om dat te leverjen.

push "route 10.64.20.0 255.255.255.0"

Set de spegelrigel yn ’e konfiguraasje fan de oare tsjinner, ferbynje dan in testklant opnij en lês syn tabel. In klant dy’t skopte rûtes negearret hat syn eigen goedkarde konfiguraasje nedich, en in rûte dy’t nea oankomt is gjin tagongskontrôle. Jou in klant gjin iroute foar de hiele pool fan de oare poarte. Dy rjochtline bestiet foar in subnet efter ien ferbûne klant, en it brûken derfan om in ûntbrekkende rûte tusken poarten te bedekken produsearret in tsjinner dy’t mient adressen te besitten dy’t er net berikke kin.

Bewiis ien fersyk en wegerje in oar

Kies in echte operaasje, bygelyks HTTPS fan in klant op 10.64.10.21 nei in tsjinst op 10.64.20.37, en stean krekt dat ta op beide hosts. Elke firewall nimit it fersyk oan syn ynkommende kant en it folge antwurd oan ’e weromkant oan; it eigen tsjinstbelied fan de bestimming moat it noch altyd akseptearje.

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

Mei wjersidige rûtes is boarne-NAT oerstallich en hjir aktyf skealik: it oersetten fan de boarne ferberget hokker klant it fersyk dien hat en ûndergraaft boarne-basearre belied oan ’e bestimmingskant. Kontrolearje dat in besteande masquerade-regel foar ynternetútgong dit paad ek net fangt. Test dan de wegering. In tsjinst dy’t lokaal by pool B bliuwe moat, moat ûnberikber bliuwe fan pool A, en klantpearen op deselde poarte moatte ek test wurde, om’t it trochstjoerbelied dat jo krekt feroare hawwe ek foar har jildt.

Noch ien korreksje op it mentale model: de transitferbining draacht ûntsifere ynterne pakketten, dus it is in fertrouwensgrins yn stee fan in priveegarânsje. As it in netwurk krúst dat jo net beheare, beskermje dy hop dan mei in goedkarde fersifere tunnel en rûtearje fia syn echte topology. End-to-end TLS autentisearret de applikaasje noch altyd op himsels, en dêrom moat de ynterne tsjinst it bliuwe brûken.