Kan klienter på två OpenVPN-servrar nå varandra?

Att sätta upp en andra OpenVPN server ger dig en andra plats där klienter kan ansluta, och inget mer. Den sätter inte de klienterna på den första serverns nätverk, och alternativet som heter client-to-client ändrar bara vidarebefordran inom en enda serverprocess. De två poolerna blir ett nätverk när du routar mellan dem, med avsikt, med en ägare för varje riktning. Allt nedan förutsätter TUN-läge i användarutrymmet med den interna vidarebefordran avstängd, så att kärnan fattar beslutet.

Myten: en kontolista, ett nätverk

Autentisering och nåbarhet blandas ihop eftersom båda bor i serverkonfigurationen. En användare som kan logga in på endera av de två gatewayerna ser, utifrån, ut som en användare på ett system med två dörrar. Inuti delar varje server ut adresser från sin egen pool och installerar bara rutter för de klienter den avslutar. Så en klient på gateway A som skickar ett paket till en klient på gateway B frågar efter en destination som dess egen server aldrig har hört talas om. Paketet går till A:s standardrutt, lämnar tunneln och anländer till en brandvägg som aldrig ombads tillåta det.

Att lägga till en andra server adderar därför inte redundans, upptäckt eller en delad broadcastdomän. Det adderar ett routat nätverk som behöver en plan, och planen börjar med adressering.

Ge varje gateway en egen pool och transitadress

Två intervall som inte får överlappa något annat, plus en liten transitlänk mellan värdarna, är hela adressplanen. Håll transit på ett privat segment som du kontrollerar, och skriv ned talen innan någon av servrarna delar ut ett lån.

Motstå frestelsen att ge båda servrarna samma pool så att profilerna förblir identiska. En kärnrutt kan inte säga vilken av två värdar som för närvarande äger en godtycklig adress inom ett delat intervall, så routingtabellen skulle peka på en gateway och klienten kan vara ansluten till den andra. Gränssnittsnamn är lokala konventioner, inte delat tillstånd. Båda värdarna här kallar tunnelenheten tun0 och transitlänken transit0, vilket är okej eftersom inget paket bär dessa namn.

Installera rutten på båda sidor

Varje gateway behöver en rutt till den andras pool via transitadressen, och vidarebefordran måste vara på för att någon av dem ska fungera som hopp. Bekräfta först den aktuella tabellen, lägg sedan till posten och gör den beständig via värdens nätverkshanterare i stället för en återanslutningskrok.

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

Spegla detta på den andra värden med poolerna ombytta. Att upprepat lägga till samma rutt från ett orelaterat skript är hur en värd hamnar med flera kopior och en mystisk ändring nästa gång någon läser tabellen. Om transitlänken själv är en tunnel pekar rutten på den tunnelns topologi och hoppet måste överleva dess återanslutning. En transitadress som försvinner i trettio sekunder tar vägen mellan poolerna med sig, vilket är en designegenskap som är värd att säga högt i stället för att upptäcka.

Skjut klientrutten utan att låtsas äga den

Klienter behöver en rutt till den avlägsna poolen, annars skickar deras eget operativsystem paketet till standardgatewayen och tunneln ser det aldrig. Serverkonfigurationen är den naturliga platsen att leverera den.

push "route 10.64.20.0 255.255.255.0"

Sätt spegellinjen i den andra serverns konfiguration, återanslut sedan en testklient och läs dess tabell. En klient som ignorerar skjutna rutter behöver sin egen godkända konfiguration, och en rutt som aldrig kommer är inte åtkomstkontroll. Ge inte en klient iroute för hela poolen hos den andra gatewayen. Det direktivet finns för ett subnät bakom en ansluten klient, och att använda det för att dölja en saknad rutt mellan gatewayerna ger en server som tror att den äger adresser den inte kan nå.

Bevisa en begäran och avvisa en annan

Välj en verklig operation, till exempel HTTPS från en klient på 10.64.10.21 till en tjänst på 10.64.20.37, och tillåt exakt det på båda värdarna. Varje brandvägg släpper in begäran på sin inkommande sida och det spårade svaret på retursidan; destinationens egen tjänstepolicy måste fortfarande acceptera det.

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

Med ömsesidiga rutter är käll-NAT onödigt och här aktivt skadligt: att översätta källan döljer vilken klient som gjorde begäran och undergräver källbaserad policy på destinationssidan. Kontrollera att en befintlig masquerade-regel för internetutgång inte också fångar denna väg. Testa sedan avvisandet. En tjänst som ska stanna lokalt i pool B måste förbli onåbar från pool A, och klientpar på samma gateway måste också testas, eftersom vidarebefordringspolicyn du just ändrade gäller dem också.

Ännu en korrigering av den mentala modellen: transitlänken bär dekrypterade inre paket, så den är en förtroendegräns och inte en privat garanti. Om den korsar ett nätverk du inte kontrollerar, skydda det hoppet med en godkänd krypterad tunnel och routa genom dess verkliga topologi. End-to-end-TLS autentiserar fortfarande applikationen själv, vilket är varför den inre tjänsten bör fortsätta använda det.