Kan klientar på to OpenVPN-tenarar nå kvarandre?

Å setje opp ein OpenVPN-tenar gir deg ein annan stad klientane kan kople til, og ikkje noko meir. Han set ikkje desse klientane på nettverket til den første tenaren, og valet som heiter client-to-client endrar berre vidaresending inne i éin tenarprosess. Dei to bassenga vert eitt nettverk når du rutar mellom dei, med vilje, med ein eigar for kvar retning. Alt nedanfor føreset TUN-modus i brukarrommet med den interne vidaresendinga avslått, slik at kjernen tek avgjerda.

Myten: éi kontoliste, eitt nettverk

Autentisering og tilgjengelegheit vert blanda saman fordi begge bur i tenarkonfigurasjonen. Ein brukar som kan logge på kva som helst av dei to gatewayane ser, frå utsida, ut som ein brukar på eitt system med to dører. Innsida deler kvar tenar ut adresser frå sitt eige basseng og installerer berre ruter for klientane han avsluttar. Så ein klient på gateway A som sender ein pakke til ein klient på gateway B, ber om ein destinasjon som hans eigen tenar aldri har høyrt om. Pakken går til standardruta til A, forlèt tunnelen og kjem til ein brannmur som aldri vart beden om å tillate han.

Å leggje til ein andre tenar gir derfor ikkje redundans, oppdaging eller eit delt kringkastingsdomene. Det gir eit ruta nettverk som treng ein plan, og planen byrjar med adressering.

Gje kvar gateway sitt eige basseng og transitadresse

To område som ikkje kan overlappe noko anna, pluss ei lita transitlenkje mellom vertane, er heile adresseplanen. Hald transienten på eit privat segment du kontrollerer, og skriv ned tala før nokon av tenarane deler ut ein lease.

Motstå freistinga til å gje begge tenarane same basseng slik at profilane vert identiske. Ei kjernerute kan ikkje seie kva av to vertar som for tida eig ein vilkårleg adresse innanfor eit delt område, så rutetabellen ville peike på éin gateway og klienten kan vere kopla til den andre. Grensesnittnamn er lokale konvensjonar, ikkje delt tilstand. Begge vertane her kallar tunneleininga tun0 og transitlenkja transit0, noko som er greitt fordi ingen pakke ber desse namna.

Installer ruta på begge sider

Kvar gateway treng ei rute til bassenget til den andre via transitadressa, og vidaresending må vere på for at nokon av dei skal fungere som hopp. Stadfest gjeldande tabell først, legg så til oppføringa og gjer ho varig gjennom nettverkshandsamaren til verten i staden for ein krok for attkopling.

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

Spegl dette på den andre verten med bassenga bytte om. Å leggje til den same ruta gong på gong frå eit urelatert skript er korleis ein vert endar opp med fleire kopiar og ei mystisk endring neste gong nokon les tabellen. Viss transitlenkja sjølv er ein tunnel, peikar ruta på topologien til den tunnelen, og hoppet må overleve attkoplinga. Ei transitadresse som forsvinn i tretti sekund tek vegen mellom bassenga med seg, noko som er ein designeigenskap det er verdt å seie høgt i staden for å oppdage.

Skyv klientruta utan å late som eigarskap

Klientar treng ei rute til det eksterne bassenget, elles sender deira eige operativsystem pakken til standardgatewayen og tunnelen ser han aldri. Tenarkonfigurasjonen er den naturlege staden å levere ho.

push "route 10.64.20.0 255.255.255.0"

Set speglingslinja i konfigurasjonen til den andre tenaren, kople så til ein testklient på nytt og les tabellen hans. Ein klient som ignorerer skyvde ruter treng sin eigen godkjende konfigurasjon, og ei rute som aldri kjem er ikkje tilgangskontroll. Ikkje gje ein klient iroute for heile bassenget til den andre gatewayen. Det direktivet finst for eit subnett bak éin tilkopla klient, og å bruke det til å dekkje over ei manglande rute mellom gatewayane gir ein tenar som trur han eig adresser han ikkje kan nå.

Prov éin førespurnad og avvis ein annan

Vel ei reell handling, til dømes HTTPS frå ein klient på 10.64.10.21 til ein teneste på 10.64.20.37, og tillat nøyaktig det på begge vertane. Kvar brannmur slepp førespurnaden inn på inngåande side og det spora svaret på retursida; tenestepolitikken til destinasjonen må framleis godta 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 gjensidige ruter er kjelde-NAT unødvendig og aktivt skadeleg her: å omsetje kjelda skjuler kva klient som sende førespurnaden og undergrev kjeldebasert politikk på destinasjonssida. Sjekk at ei eksisterande masquerade-regel for internett-utgang ikkje òg fangar denne vegen. Test så avvisinga. Ei teneste som skal halde seg lokal i basseng B må vere utilgjengeleg frå basseng A, og klientpar på same gateway må òg testast, sidan vidaresendingspolitikken du nettopp endra gjeld dei òg.

Éi retting til av den mentale modellen: transitlenkja fraktar dekrypterte indre pakkar, så ho er ei tillitsgrense og ikkje ein privat garanti. Viss ho kryssar eit nettverk du ikkje kontrollerer, vern det hoppet med ein godkjend kryptert tunnel og rut gjennom den verkelege topologien. Ende-til-ende-TLS autentiserer framleis applikasjonen på eiga hand, og derfor bør den indre tenesta halde fram med å bruke det.