Kan kliënte op twee OpenVPN-bedienerjies mekaar bereik?

Om ’n tweede OpenVPN-bediener op te stel gee jou ’n tweede plek waar kliënte kan aansluit, en niks meer nie. Dit plaas nie daardie kliënte op die eerste bediener se netwerk nie, en die opsie genaamd client-to-client verander slegs aanstuur binne ’n enkele bedienerproses. Die twee poele word een netwerk wanneer jy doelbewus tussen hulle roeteer, met ’n eienaar vir elke rigting. Alles hieronder aanvaar gebruikersruimte-TUN-modus met daardie interne aanstuur afgeskakel, sodat die kern die besluit neem.

Die mite: een rekeninglys, een netwerk

Verifikasie en bereikbaarheid word verwar omdat albei in die bedienerkonfigurasie woon. ’n Gebruiker wat by enige van die twee poorte kan aanmeld, lyk van buite soos ’n gebruiker op een stelsel met twee deure. Binne deel elke bediener adresse uit sy eie poel uit en installeer slegs roetes vir die kliënte wat hy beëindig. Dus vra ’n kliënt op poort A wat ’n pakket na ’n kliënt op poort B stuur, na ’n bestemming waarvan sy eie bediener nog nooit gehoor het nie. Die pakket gaan na A se verstekroete, verlaat die tonnel en arriveer by ’n firewall wat nooit gevra is om dit toe te laat nie.

Om ’n tweede bediener by te voeg, voeg dus nie oortolligheid, ontdekking of ’n gedeelde uitsaaidomein by nie. Dit voeg ’n geroteerde netwerk by wat ’n plan nodig het, en die plan begin met adressering.

Gee elke poort sy eie poel en deurvoeradres

Twee reekse wat niks anders mag oorvleuel nie, plus ’n klein deurvoerskakel tussen die gashere, is die hele adresplan. Hou die deurvoer op ’n private segment wat jy beheer, en skryf die nommers neer voordat enige bediener ’n huurkontrak uitreik.

Weerstaan die versoeking om albei bedieners dieselfde poel te gee sodat profiele identies bly. ’n Kernroete kan nie sê watter van twee gashere tans ’n willekeurige adres binne ’n gedeelde reeks besit nie, so die roetertabel sou na een poort wys en die kliënt kan aan die ander gekoppel wees. Koppelvlakname is plaaslike konvensies, nie gedeelde toestand nie. Albei gashere hier noem die tonneltoestel tun0 en die deurvoerskakel transit0, wat goed is omdat geen pakket daardie name dra nie.

Installeer die roete aan albei kante

Elke poort het ’n roete nodig vir die ander se poel deur die deurvoeradres, en aanstuur moet aan wees sodat enigeen as ’n hop kan optree. Bevestig eers die huidige tabel, voeg dan die inskrywing by en hou dit vol via die gasheer se netwerkbestuurder eerder as ’n heraansluitingshaak.

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

Spieël dit op die ander gasheer met die poele omgeruil. Om dieselfde roete herhaaldelik vanuit ’n onverwante script by te voeg, is hoe ’n gasheer met verskeie kopieë en ’n raaiselagtige verandering eindig die volgende keer dat iemand die tabel lees. As die deurvoerskakel self ’n tonnel is, wys die roete na daardie tonnel se topologie en die hop moet sy heraansluiting oorleef. ’n Deurvoeradres wat vir dertig sekondes verdwyn, neem die pad tussen poele saam met hom, wat ’n ontwerpeienskap is wat die moeite werd is om te stel eerder as om te ontdek.

Stuur die kliëntroete sonder om eienaarskap te veins

Kliënte het ’n roete vir die afgeleë poel nodig, anders stuur hulle eie bedryfstelsel die pakket na sy verstekpoort en die tonnel sien dit nooit. Die bedienerkonfigurasie is die natuurlike plek om dit te lewer.

push "route 10.64.20.0 255.255.255.0"

Plaas die spieëlreël in die ander bediener se konfigurasie, heraansluit dan ’n toetskliënt en lees sy tabel. ’n Kliënt wat gestuurde roetes ignoreer, het sy eie goedgekeurde konfigurasie nodig, en ’n roete wat nooit arriveer nie, is nie ’n toegangsbeheer nie. Moenie aan ’n kliënt ’n iroute gee vir die ander poort se hele poel nie. Daardie richtlijn bestaan vir ’n subnet agter een gekoppelde kliënt, en om dit te gebruik om ’n ontbrekende roete tussen poorte te bedek, produseer ’n bediener wat glo hy besit adresse wat hy nie kan bereik nie.

Bewys een versoek en weier ’n ander

Kies ’n werklike bewerking, byvoorbeeld HTTPS van ’n kliënt by 10.64.10.21 na ’n diens op 10.64.20.37, en laat presies dit op albei gashere toe. Elke firewall aanvaar die versoek aan sy inkomende kant en die gevolgde antwoord aan die terugkeerkant; die bestemming se eie diensbeleid moet dit steeds aanvaar.

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

Met wedersydse roetes is bron-NAT onnodig en hier aktief skadelik: om die bron te vertaal verberg watter kliënt die versoek gemaak het en verydel brongebaseerde beleid aan die bestemmingskant. Kontroleer dat ’n bestaande maskerade-reël vir internetuitgang nie ook hierdie pad vang nie. Toets dan die weiering. ’n Diens wat plaaslik by poel B moet bly, moet onbereikbaar bly vanaf poel A, en kliëntpare op dieselfde poort moet ook getoets word, aangesien die aanstuurbeleid wat jy pas verander het, ook op hulle van toepassing is.

Nog een regstelling aan die mentale model: die deurvoerskakel dra ontsyferde interne pakkette, dus is dit ’n vertrouensgrens eerder as ’n private waarborg. As dit ’n netwerk kruis wat jy nie beheer nie, beskerm daardie hop met ’n goedgekeurde geënkripteerde tonnel en roeteer deur sy werklike topologie. End-tot-end TLS verifieer steeds die toepassing op sy eie, en daarom moet die interne diens dit bly gebruik.