Mogu li se klijenti na dva OpenVPN servera međusobno dosegnuti?

Podizanje drugog OpenVPN servera daje ti drugo mjesto na koje se klijenti mogu povezati, i ništa više. Ne stavlja te klijente na mrežu prvog servera, a opcija nazvana client-to-client mijenja samo prosljeđivanje unutar jednog serverskog procesa. Ta dva skupa postaju jedna mreža kada između njih rutiraš namjerno, s vlasnikom za svaki smjer. Sve ispod pretpostavlja TUN način u korisničkom prostoru s isključenim tim unutrašnjim prosljeđivanjem, tako da odluku donosi kernel.

Mit: jedna lista računa, jedna mreža

Autentifikacija i dostupnost se miješaju jer oboje živi u konfiguraciji servera. Korisnik koji se može prijaviti na bilo koji od dva gatewaya izgleda, izvana, kao korisnik na jednom sustavu s dvoje vrata. Iznutra svaki server dijeli adrese iz svog skupa i instalira rute samo za klijente koje prekida. Zato klijent na gatewayu A koji šalje paket klijentu na gatewayu B traži odredište za koje njegov vlastiti server nikada nije čuo. Paket ide na zadanu rutu A, napušta tunel i stiže do firewalla koji nikada nije bio zamoljen da ga propusti.

Dodavanje drugog servera zato ne dodaje redundanciju, otkrivanje ni zajedničku broadcast domenu. Dodaje rutiranu mrežu kojoj treba plan, a plan počinje adresiranjem.

Daj svakom gatewayu vlastiti skup i tranzitnu adresu

Dva raspona koja se ne smiju preklapati ni s čim drugim, plus mala tranzitna veza između hostova, cijeli je plan adresa. Drži tranzit na privatnom segmentu koji kontroliraš i zapiši brojeve prije nego bilo koji server izda lease.

Odupri se napasti da oba servera dobiju isti skup kako bi profili ostali identični. Kernel ruta ne može reći koji od dva hosta trenutačno posjeduje proizvoljnu adresu unutar zajedničkog raspona, pa bi tablica usmjeravanja pokazivala na jedan gateway, a klijent bi mogao biti spojen na drugi. Nazivi sučelja lokalne su konvencije, ne zajedničko stanje. Oba hosta ovdje tunelski uređaj zovu tun0, a tranzitnu vezu transit0, što je u redu jer nijedan paket ne nosi ta imena.

Instaliraj rutu na obje strane

Svakom gatewayu treba ruta do skupa onog drugog kroz tranzitnu adresu, a prosljeđivanje mora biti uključeno da bi bilo koji mogao djelovati kao hop. Prvo potvrdi trenutačnu tablicu, zatim dodaj unos i učini ga trajnim kroz mrežnog upravitelja hosta, a ne kroz kuku za ponovno povezivanje.

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

Preslikaj to na drugom hostu sa zamijenjenim skupovima. Ponovno dodavanje iste rute iz nepovezane skripte način je na koji host završi s nekoliko kopija i tajanstvenom promjenom sljedeći put kad netko pročita tablicu. Ako je tranzitna veza sama tunel, ruta pokazuje na topologiju tog tunela i hop mora preživjeti njegovo ponovno povezivanje. Tranzitna adresa koja nestane na trideset sekundi nosi sa sobom put između skupova, što je svojstvo dizajna koje vrijedi izgovoriti umjesto otkriti.

Gurni rutu klijenta bez lažnog vlasništva

Klijentima treba ruta do udaljenog skupa, inače njihov vlastiti operacijski sustav šalje paket na zadani gateway i tunel ga nikada ne vidi. Konfiguracija servera prirodno je mjesto da ju dostavi.

push "route 10.64.20.0 255.255.255.0"

Stavi zrcalni redak u konfiguraciju drugog servera, zatim ponovno spoji testnog klijenta i pročitaj njegovu tablicu. Klijent koji ignorira gurnute rute treba vlastitu odobrenu konfiguraciju, a ruta koja nikada ne stigne nije kontrola pristupa. Ne daj klijentu iroute za cijeli skup drugog gatewaya. Ta direktiva postoji za podmrežu iza jednog spojenog klijenta, a njezino korištenje da se prekrije nedostajuća ruta između gatewaya stvara server koji vjeruje da posjeduje adrese do kojih ne može doći.

Dokaži jedan zahtjev i odbij drugi

Odaberi stvarnu operaciju, na primjer HTTPS s klijenta na 10.64.10.21 prema servisu na 10.64.20.37, i dopusti točno to na obama hostovima. Svaki firewall propušta zahtjev na ulaznoj strani i praćeni odgovor na povratnoj; politika samog odredišnog servisa još ga mora prihvatiti.

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

Uz uzajamne rute, izvorni NAT je ovdje nepotreban i aktivno štetan: prevođenje izvora skriva koji je klijent poslao zahtjev i ruši politiku temeljenu na izvoru na strani odredišta. Provjeri da postojeće masquerade pravilo za izlaz u internet ne hvata i ovu stazu. Zatim testiraj odbijanje. Servis koji mora ostati lokalni u skupu B mora ostati nedostupan iz skupa A, a parove klijenata na istom gatewayu također treba testirati, jer se promijenjena politika prosljeđivanja odnosi i na njih.

Još jedna ispravka mentalnog modela: tranzitna veza prenosi dešifrirane unutarnje pakete, pa je granica povjerenja, a ne privatno jamstvo. Ako prelazi mrežu koju ne kontroliraš, zaštiti taj hop odobrenim šifriranim tunelom i rutiraj kroz njegovu stvarnu topologiju. End-to-end TLS i dalje sam autentificira aplikaciju, zato bi unutarnji servis trebao nastaviti koristiti ga.