Du OpenVPN-klientoj sur unu Linux-pordego: disigu la politikon

Du OpenVPN-demonoj povas ambaŭ raporti sukcesan tunelon dum la pordego sendas ĉiun klienton tra la sama. Nenio en la manpremo decidas, kiun tunelon kliento uzas; la kerno decidas, paketo post paketo, trairante la politikajn regulojn kaj poste la tabelon, kiun ĉiu regulo nomas. Kiam vi rigardas ĝin tiel, la agordo ĉesas temi pri OpenVPN-opcioj kaj fariĝas enkursiga matrico kun du posedantoj.

La kerno decidas, ne la demono

Plusendita paketo alvenas ĉe la LAN-interfaco, kaj la enkursiga kodo taksas la regulan liston laŭ prioritata ordo. La unua regulo, kies selektilo kongruas, nomas tabelon, kaj la vojoj de tiu tabelo elektas la eligan aparaton. Se la tabelo havas neniun kongruan vojon, la serĉo daŭras al la sekva regulo, kaj ĝuste tiu detalo igas duonpretan agordon malsukcesi silente anstataŭ laŭte.

La tunela procezo havas neniun direton en tiu trairado. Ĝi kreas interfacon kaj povas instali vojojn, sed ĉu la paketo de aparta kliento eniras tiun interfacon tute dependas de la tabelo, al kiu ĝi estis sendita. Du tuneloj kun identaj importitaj vojoj do konkurencas, kaj la lasta skribanto gajnas por ĉiuj. Tial agordo povas aspekti ekvilibra en la agordaj dosieroj kaj tamen sendi ĉiujn klientojn tra unu demono.

Donu al ĉiu instanco sian propran rimedaron

Komencu per nomoj, ĉar reuzitaj nomoj estas la maniero, kiel la du instancoj hazarde komencas kunhavigi staton. Asignu apartajn tunelajn aparatojn, apartajn agordajn dosierojn, apartajn akreditaĵojn kaj apartajn servajn unuojn. Notu la eksteran finpunkton kaj tunelan adreson de ĉiu instanco en la sama tabelo kiel la politika matrico, por ke posta ŝanĝo havu unu lokon por rigardi.

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

dev tun-lab
route-nopull

route-nopull tenas la puŝitajn vojojn de servilo ekster la loka tabelo, kio estas ĝuste tio, kion vi volas, kiam la politikaj tabeloj devus esti eksplicitaj. Ĉu donita servilo ankaŭ puŝas opcion redirect-gateway, kaj ĉu via klienta versio subtenas la filtran formon, indas kontroli en la manlibro anstataŭ supozi.

Skribu la matricon: fonto, tabelo, aparato

Por ĉiu klienta grupo, aldonu regulon, kiu elektas tabelon laŭ fonta adreso, poste metu la celitan vojon en tiun tabelon:

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

La tabelo bezonas la celajn vojojn, kiujn la grupo devus havi, plus iujn lokajn aŭ administrajn esceptojn, kiuj tenas la pordegon uzebla. Tabelo enhavanta nur defaŭltan vojon estas plentunela politiko por tiu grupo, kio eble estas ĝuste ĝusta, sed ĝi devus esti decido anstataŭ preterlaso.

La propra transporto de la tunelo ne estas en klienta grupo

La ĉifritaj paketoj de ĉiu demono originas sur la pordego mem, adresitaj al la ekstera samtavolano. Regulo, kiu kongruas nur kun klienta fonta prefikso, lasas tiujn paketojn trankvile, tial font-limigitaj reguloj estas pli sekuraj ol reguloj, kiuj kongruas kun ĉio. Regulo sen selektilo povas kapti la propran transporton de la tunelo kaj resendi ĝin tra tunelo, kaj tiam la konekto malsukcesas tiel, ke ĝi aspektas kiel provizanta problemo.

Tenu la lokan administran sesion kaj la suban vojon eksplicite ekster la politikaj tabeloj. Skribu tiujn esceptojn apud la matrico; ili estas parto de la dezajno, ne provizora solvo por remalkovri dum incidento.

Elekti vojon ne permesas ĝin

Permeso por plusendado estas dua decido farita pli poste sur la vojo. Fajromura regulo, kiu akceptas paketojn elirantajn tra la dua tunelo, ne igas la enkursigan kodon elekti ĝin, kaj ĝusta tabelo ne donas permeson plusendi. Ambaŭ devas ekzisti, kaj testo, kiu pruvas nur unu el ili, misgvidos vin pri la alia. Kiam unu grupo funkcias kaj la alia ne, kontrolu tiujn du paŝojn aparte anstataŭ reskribi la tabelojn.

Fonta tradukado estas tria decido, kaj ĝi devus esti limigita al la fonta grupo kaj la tunela aparato, kiu fakte portas ĝin. Aldonu dediĉitan ĉenon por la du instancoj anstataŭ malplenigi la postrouting-ĉenon, ĉar nerilataj servoj povas posedi enskribojn tie, kaj malplenigo forigas ilin silente.

Kio okazas, kiam unu tunelo falas

Decidu la fiaskokonduton anticipe. Kiam tunela tabelo perdas sian vojon, la serĉo falas al la sekva regulo, kaj la trafiko de la grupo daŭras tra la alia tunelo aŭ la ordinara suprenligo sen ajna eraro. Se tio ne estas akceptebla, aldonu finantan regulon kun pli malalta prioritata numero, kiu redonas neatingeblan rezulton por tiu fonto, por ke la perdo estu videbla anstataŭ sorbita.

Sendu novan peton el ĉiu fonta grupo kaj notu kvar faktojn: la elektitan tabelon, la eligan aparaton, la tradukitan fonton kaj ĉu la respondo revenis tra la sama vojo. Poste mallevu unu tunelon kaj ripetu. Du TUN-aparatoj en interfaca listo pruvas, ke ambaŭ demonoj startis; ili diras nenion pri tio, kiun aparta kliento uzis. La dua rulo, kun unu tunelo malaperinta, estas tiu, kiu montras, ĉu via rezerva regulo faras tion, kion vi intencis.