Dva OpenVPN klijenta na jednom Linux mrežnom prolazu: podijelite politiku

Dva OpenVPN demona mogu oba prijaviti uspješan tunel dok prolaz šalje svakog klijenta kroz isti. Ništa u rukovanju ne odlučuje koji tunel klijent koristi; to odlučuje kernel, paket po paket, prolazeći kroz pravila politike, a zatim kroz tabelu koju svako pravilo imenuje. Kad na to gledate tako, konfiguracija prestaje biti o opcijama OpenVPN-a i postaje matrica rutiranja s dva vlasnika.

Kernel odlučuje, ne demon

Proslijeđeni paket stiže na LAN interfejs i kod za rutiranje procjenjuje listu pravila po redu prioriteta. Prvo pravilo čiji birač odgovara imenuje tabelu, a rute te tabele biraju izlazni uređaj. Ako tabela nema odgovarajuću rutu, pretraga se nastavlja na sljedeće pravilo, i upravo taj detalj čini da nedovršena postavka pada tiho, a ne glasno.

Proces tunela nema riječi u tom prolasku. On stvara interfejs i može instalirati rute, ali da li paket određenog klijenta ulazi u taj interfejs zavisi isključivo od tabele u koju je poslan. Zato se dva tunela s identičnim uvezenim rutama takmiče, a posljednji pisac pobjeđuje za sve. Zato postavka može izgledati uravnoteženo u konfiguracijskim datotekama, a ipak slati sve klijente kroz jedan demon.

Dajte svakoj instanci vlastiti skup resursa

Počnite s imenima, jer ponovno korištena imena su način na koji dvije instance slučajno počnu dijeliti stanje. Dodijelite različite tunelske uređaje, različite konfiguracijske datoteke, različite akreditive i različite servisne jedinice. Zabilježite vanjsku krajnju točku i tunelsku adresu svake instance u istu tabelu kao i matricu politike, da kasnija promjena ima jedno mjesto za pogledati.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull drži rute koje server nameće izvan lokalne tabele, što je upravo ono što želite kada tabele politike treba da budu eksplicitne. Da li dati server nameće i opciju redirect-gateway i da li vaša verzija klijenta podržava oblik s filterom, vrijedi provjeriti u priručniku umjesto pretpostavljati.

Napišite matricu: izvor, tabela, uređaj

Za svaku grupu klijenata dodajte pravilo koje bira tabelu po adresi izvora, a zatim stavite željenu putanju u tu tabelu:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabela treba rute do odredišta koje grupa treba da ima, plus sve lokalne ili upravljačke izuzetke koji drže prolaz upotrebljivim. Tabela koja sadrži samo podrazumijevanu rutu je politika punog tunela za tu grupu, što može biti potpuno ispravno, ali to treba biti odluka, a ne propust.

Vlastiti transport tunela nije u grupi klijenata

Šifrirani paketi svakog demona nastaju na samom prolazu, upućeni vanjskom partneru. Pravilo koje odgovara samo prefiksu izvora klijenta ostavlja te pakete na miru, i zato su pravila ograničena na izvor sigurnija od pravila koja odgovaraju na sve. Pravilo bez birača može uhvatiti vlastiti transport tunela i poslati ga natrag kroz tunel, a veza tada pada na način koji izgleda kao problem provajdera.

Držite lokalnu upravljačku sesiju i putanju donjeg sloja izričito izvan tabela politike. Zapišite te izuzetke pored matrice; oni su dio dizajna, a ne zaobilazno rješenje koje treba ponovno otkriti tokom incidenta.

Odabir putanje ne daje dozvolu

Dozvola za prosljeđivanje je druga odluka donesena kasnije na putu. Firewall pravilo koje prihvata pakete koji izlaze kroz drugi tunel ne čini da ih kod za rutiranje odabere, a ispravna tabela ne daje dozvolu za prosljeđivanje. Oba moraju postojati, a test koji dokazuje samo jedno od njih zavest će vas u pogledu drugog. Kad jedna grupa radi a druga ne, provjerite ta dva koraka odvojeno umjesto da prepisujete tabele.

Prevođenje izvora je treća odluka i treba biti ograničeno na grupu izvora i tunelski uređaj koji je zaista nosi. Dodajte namjenski lanac za dvije instance umjesto da praznite postrouting lanac, jer nepovezane usluge mogu imati unose tamo i pražnjenje ih tiho uklanja.

Šta se dešava kad jedan tunel padne

Odluku o ponašanju pri kvaru donesite unaprijed. Kad tunelska tabela izgubi svoju rutu, pretraga pada na sljedeće pravilo i promet grupe nastavlja kroz drugi tunel ili obični uzlazni link bez ikakve greške. Ako to nije prihvatljivo, dodajte završno pravilo s nižim brojem prioriteta koje vraća nedostupni rezultat za taj izvor, da gubitak bude vidljiv umjesto da bude upijen.

Pošaljite novi zahtjev iz svake grupe izvora i zabilježite četiri činjenice: odabranu tabelu, izlazni uređaj, prevedeni izvor i da li se odgovor vratio istim putem. Zatim spustite jedan tunel i ponovite. Dva TUN uređaja na listi interfejsa dokazuju da su oba demona pokrenuta; ona ne govore ništa o tome koji je dati klijent koristio. Drugi prolaz, s jednim tunelom manje, je onaj koji pokazuje da li vaše rezervno pravilo radi ono što ste namjeravali.