Mogu li se klijenti na dva OpenVPN poslužitelja međusobno dosegnuti?

Postavljanje drugog OpenVPN poslužitelja daje vam drugo mjesto na koje se klijenti mogu povezati i ništa više. Ono ne stavlja te klijente na mrežu prvog poslužitelja, a opcija client-to-client mijenja samo prosljeđivanje unutar jednog procesa poslužitelja. Dva skupa postaju jedna mreža kada između njih namjerno usmjeravate, s vlasnikom za svaki smjer. Sve u nastavku pretpostavlja TUN način u korisničkom prostoru s isključenim tim unutarnjim prosljeđivanjem, pa odluku donosi kernel.

Mit: jedan popis računa, jedna mreža

Autentifikacija i dostupnost se miješaju jer oboje žive u konfiguraciji poslužitelja. Korisnik koji se može prijaviti na bilo koji od dva pristupa izvana izgleda kao korisnik na jednom sustavu s dvoje vrata. Iznutra svaki poslužitelj dijeli adrese iz svog skupa i instalira rute samo za klijente koje prekida. Zato klijent na pristupu A koji šalje paket klijentu na pristupu B traži odredište za koje njegov poslužitelj nikada nije čuo. Paket ide na zadanu rutu A, napušta tunel i stiže do vatrozida od kojeg nikada nije zatraženo da ga propusti.

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

Dajte svakom pristupu vlastiti skup i tranzitnu adresu

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

Oduprite se iskušenju da oba poslužitelja 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 pristup, a klijent bi mogao biti priključen na drugi. Imena 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.

Instalirajte rutu na obje strane

Svakom pristupu treba ruta za skup onog drugog preko tranzitne adrese, a prosljeđivanje mora biti uključeno da bi bilo koji mogao djelovati kao skok. Najprije potvrdite trenutačnu tablicu, zatim dodajte unos i održite ga 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

Zrcalite to na drugom hostu uz zamijenjene skupove. 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 skok mora preživjeti njegovo ponovno povezivanje. Tranzitna adresa koja nestane na trideset sekundi odnosi sa sobom put između skupova, što je svojstvo dizajna koje vrijedi izjaviti, a ne otkriti.

Pošaljite rutu klijenta bez lažnog vlasništva

Klijentima treba ruta za udaljeni skup, inače njihov vlastiti operacijski sustav šalje paket na zadanu adresu pristupa i tunel ga nikada ne vidi. Konfiguracija poslužitelja prirodno je mjesto da se to dostavi.

push "route 10.64.20.0 255.255.255.0"

Stavite zrcalni redak u konfiguraciju drugog poslužitelja, zatim ponovno povežite probnog klijenta i pročitajte njegovu tablicu. Klijent koji ignorira poslane rute treba vlastitu odobrenu konfiguraciju, a ruta koja nikada ne stigne nije kontrola pristupa. Ne dajte klijentu iroute za cijeli skup drugog pristupa. Ta direktiva postoji za podmrežu iza jednog povezanog klijenta, a njezino korištenje da se prekrije nedostajuća ruta između pristupa stvara poslužitelj koji vjeruje da posjeduje adrese do kojih ne može doći.

Dokažite jedan zahtjev i odbijte drugi

Odaberite stvarnu operaciju, na primjer HTTPS s klijenta na 10.64.10.21 prema usluzi na 10.64.20.37, i dopustite točno to na oba hosta. Svaki vatrozid prihvaća zahtjev na svojoj ulaznoj strani i praćeni odgovor na povratnoj strani; vlastita politika usluge na odredištu to još 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 nepotreban i ovdje aktivno škodljiv: prevođenje izvora skriva koji je klijent poslao zahtjev i pobjeđuje politiku temeljenu na izvoru na strani odredišta. Provjerite ne hvata li i ovaj put postojeće pravilo maskiranja za izlaz na internet. Zatim testirajte odbijanje. Usluga koja mora ostati lokalna za skup B mora ostati nedostupna iz skupa A, a parove klijenata na istom pristupu također treba testirati, jer politika prosljeđivanja koju ste upravo promijenili vrijedi i za njih.

Još jedna ispravka mentalnog modela: tranzitna veza nosi dešifrirane unutarnje pakete, pa je granica povjerenja, a ne privatno jamstvo. Ako prelazi mrežu koju ne kontrolirate, zaštitite taj skok odobrenim šifriranim tunelom i usmjeravajte kroz njegovu stvarnu topologiju. End-to-end TLS i dalje sam provjerava aplikaciju, zato unutarnja usluga treba nastaviti koristiti ga.