Kan klienter på to OpenVPN-servere nå hinanden?

At rejse en anden OpenVPN server giver dig endnu et sted, hvor klienter kan forbinde, og ikke mere. Det sætter ikke de klienter på den første servers netværk, og indstillingen client-to-client ændrer kun videresendelse inde i én serverproces. De to puljer bliver ét netværk, når du bevidst ruter mellem dem, med en ejer for hver retning. Alt nedenfor forudsætter TUN-tilstand i brugerniveau med den interne videresendelse slået fra, så kernen træffer beslutningen.

Myten: én kontoliste, ét netværk

Godkendelse og tilgængelighed blandes sammen, fordi begge bor i serverkonfigurationen. En bruger, der kan logge ind på en af de to gateways, ser udefra ud som en bruger på ét system med to døre. Indeni uddeler hver server adresser fra sin egen pulje og installerer kun ruter for de klienter, den afslutter. Så en klient på gateway A, der sender en pakke til en klient på gateway B, beder om en destination, som dens egen server aldrig har hørt om. Pakken går til standardruten for A, forlader tunnelen og ankommer til en firewall, der aldrig er blevet bedt om at tillade den.

At tilføje en anden server giver derfor ikke redundans, opdagelse eller et delt broadcast-domæne. Det tilføjer et rutet netværk, der kræver en plan, og planen begynder med adressering.

Giv hver gateway sin egen pulje og transitadresse

To områder, der ikke må overlappe noget andet, plus et lille transitlink mellem værterne, er hele adresseplanen. Hold transit på et privat segment, du kontrollerer, og skriv tallene ned, før nogen server uddeler en lease.

Modstå fristelsen til at give begge servere samme pulje, så profilerne forbliver identiske. En kernelrute kan ikke sige, hvilken af to værter der i øjeblikket ejer en vilkårlig adresse i et delt område, så routingtabellen ville pege på én gateway, og klienten kan være knyttet til den anden. Interface-navne er lokale konventioner, ikke delt tilstand. Begge værter her kalder tunneleenheden tun0 og transitlinket transit0, hvilket er fint, fordi ingen pakke bærer de navne.

Installer ruten på begge sider

Hver gateway har brug for en rute til den andens pulje gennem transitadressen, og videresendelse skal være slået til, for at nogen kan fungere som hop. Bekræft først den aktuelle tabel, tilføj derefter posten, og gør den varig via værtens netværksadministrator i stedet for et genopkoblingshook.

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

Spejl det på den anden vært med puljerne byttet om. Gentagne tilføjelser af samme rute fra et uvedkommende script er, hvordan en vært ender med flere kopier og en mystisk ændring, næste gang nogen læser tabellen. Hvis transitlinket selv er en tunnel, peger ruten på den tunnels topologi, og hoppet skal overleve dens genopkobling. En transitadresse, der forsvinder i tredive sekunder, tager vejen mellem puljerne med sig, hvilket er en designegenskab, der er værd at erklære i stedet for at opdage.

Skub klientruten uden at foregive ejerskab

Klienter har brug for en rute til den fjerne pulje, ellers sender deres eget styresystem pakken til sin standardgateway, og tunnelen ser den aldrig. Serverkonfigurationen er det naturlige sted at levere det.

push "route 10.64.20.0 255.255.255.0"

Sæt spejllinjen i den anden servers konfiguration, genopkobl derefter en testklient og læs dens tabel. En klient, der ignorerer skubbede ruter, har brug for sin egen godkendte konfiguration, og en rute, der aldrig ankommer, er ikke adgangskontrol. Giv ikke en klient en iroute for den anden gateways hele pulje. Den direktiv findes til et undernet bag én tilsluttet klient, og at bruge den til at dække over en manglende rute mellem gateways frembringer en server, der tror, den ejer adresser, den ikke kan nå.

Bevis én anmodning og afvis en anden

Vælg en rigtig handling, for eksempel HTTPS fra en klient på 10.64.10.21 til en tjeneste på 10.64.20.37, og tillad præcis det på begge værter. Hver firewall accepterer anmodningen på sin indgående side og det sporede svar på retursiden; destinationens egen tjenestepolitik skal stadig acceptere 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 gensidige ruter er kilde-NAT unødvendigt og her aktivt skadeligt: at oversætte kilden skjuler, hvilken klient der sendte anmodningen, og underminerer kildebaseret politik på destinationssiden. Kontroller, at en eksisterende masquerade-regel til internetudgang ikke også fanger denne vej. Test derefter afvisningen. En tjeneste, der skal forblive lokal i pulje B, skal forblive utilgængelig fra pulje A, og klientpar på samme gateway skal også testes, da den videresendelsespolitik, du netop har ændret, også gælder for dem.

Endnu en rettelse til den mentale model: transitlinket bærer dekrypterede indre pakker, så det er en tillidsgrænse snarere end en privat garanti. Hvis det krydser et netværk, du ikke kontrollerer, beskyt det hop med en godkendt krypteret tunnel, og rut gennem dens reelle topologi. End-to-end TLS godkender stadig applikationen på egen hånd, og derfor bør den indre tjeneste blive ved med at bruge det.