Kaks OpenVPN klienti ühel Linuxi lüüsil: jagage poliitika

Kaks OpenVPN deemonit võivad mõlemad teatada õnnestunud tunnelist, samal ajal kui lüüs saadab iga kliendi sama tunneli kaudu. Käepigistuses ei otsusta miski, millist tunnelit klient kasutab; seda otsustab tuum, pakett-paketi haaval, käies läbi poliitikareeglid ja seejärel tabeli, mille iga reegel nimetab. Kui seda nii vaadata, ei ole konfiguratsioon enam OpenVPN-i valikute küsimus, vaid marsruutimismaatriks kahe omanikuga.

Otsustab tuum, mitte deemon

Edastatav pakett saabub LAN-liidesele ja marsruutimiskood hindab reeglite loendit prioriteedi järjekorras. Esimene reegel, mille selektor sobib, nimetab tabeli, ja selle tabeli marsruudid valivad väljundseadme. Kui tabelis pole sobivat marsruuti, jätkub otsing järgmise reegliga, ja just see detail paneb poolelioleva seadistuse vaikselt, mitte valjult ebaõnnestuma.

Tunneliprotsessil ei ole selles läbimises sõnaõigust. See loob liidese ja võib marsruute paigaldada, kuid see, kas konkreetse kliendi pakett sellesse liidesesse siseneb, sõltub täielikult tabelist, kuhu see saadeti. Seega võistlevad kaks identsete imporditud marsruutidega tunnelit ja viimane kirjutaja võidab kõigi jaoks. Sellepärast võib seadistus konfiguratsioonifailides tasakaalukas välja näha ja siiski saata kõik kliendid ühe deemoni kaudu.

Andke igale eksemplarile oma ressursikomplekt

Alustage nimedest, sest korduvkasutatud nimed on viis, kuidas kaks eksemplari kogemata olekut jagama hakkavad. Määrake erinevad tunneliseadmed, erinevad konfiguratsioonifailid, erinevad volitused ja erinevad teenuseüksused. Kirjutage iga eksemplari väline lõpp-punkt ja tunneli aadress samasse tabelisse kui poliitikamaatriks, et hilisemal muudatusel oleks üks koht, kuhu vaadata.

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

dev tun-lab
route-nopull

route-nopull hoiab serveri lükatud marsruudid kohalikust tabelist väljas, mis on täpselt see, mida soovite, kui poliitikatabelid peaksid olema selged. Kas antud server lükkab ka redirect-gateway valiku ja kas teie kliendi versioon toetab filtreerimisvormi, tasub kontrollida käsiraamatust, mitte eeldada.

Kirjutage maatriks: allikas, tabel, seade

Lisage igale kliendigrupile reegel, mis valib tabeli allika aadressi järgi, ja asetage seejärel kavandatud tee sellesse tabelisse:

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

Tabel vajab sihtkoha marsruute, mis grupil peaksid olema, pluss kõik kohalikud või halduslikud erandid, mis hoiavad lüüsi kasutatavana. Ainult vaikimisi marsruuti sisaldav tabel on selle grupi jaoks täistunneli poliitika, mis võib olla täpselt õige, kuid see peaks olema otsus, mitte väljajätt.

Tunneli enda transport ei ole kliendigrupis

Iga deemoni krüpteeritud paketid tekivad lüüsil endal ja on adresseeritud välisele partnerile. Reegel, mis sobib ainult kliendi allika prefiksiga, jätab need paketid rahule, mistõttu on allikapõhised reeglid turvalisemad kui reeglid, mis sobivad kõigega. Ilma selektorita reegel võib tunneli enda transpordi kinni püüda ja selle tunneli kaudu tagasi saata, ja siis ebaõnnestub ühendus viisil, mis näeb välja nagu pakkuja probleem.

Hoidke kohalik haldusseanss ja aluskihi tee selgelt poliitikatabelitest väljas. Kirjutage need erandid maatriksi kõrvale; need on osa disainist, mitte ajutine lahendus, mida tuleb intsidendi ajal uuesti avastada.

Tee valimine ei luba seda

Edastusluba on teine otsus, mis tehakse teel hiljem. Tulemüürireegel, mis aktsepteerib teise tunneli kaudu väljuvaid pakette, ei pane marsruutimiskoodi seda valima, ja õige tabel ei anna edastusluba. Mõlemad peavad olema olemas, ja test, mis tõestab ainult ühte, eksitab teid teise suhtes. Kui üks grupp töötab ja teine mitte, kontrollige neid kahte sammu eraldi, selle asemel et tabeleid ümber kirjutada.

Allika tõlkimine on kolmas otsus ja see tuleks piirata allikagrupi ja tunneliseadmega, mis seda tegelikult kannab. Lisage kahe eksemplari jaoks eraldi ahel, selle asemel et postrouting-ahelat tühjendada, sest mitteseotud teenused võivad seal kirjeid omada ja tühjendamine eemaldab need vaikselt.

Mis juhtub, kui üks tunnel kukub

Otsustage rikke käitumine ette. Kui tunnelitabel kaotab oma marsruudi, langeb otsing läbi järgmisele reeglile ja grupi liiklus jätkub teise tunneli või tavalise üleslingi kaudu ilma ühegi veata. Kui see ei ole vastuvõetav, lisage madalama prioriteedinumbriga lõpetav reegel, mis tagastab selle allika jaoks kättesaamatu tulemuse, et kaotus oleks nähtav, mitte alla neelatud.

Saatke igast allikagrupist värske päring ja kirjutage üles neli fakti: valitud tabel, väljundseade, tõlgitud allikas ja kas vastus tuli tagasi sama teed. Seejärel laske üks tunnel alla ja korrake. Kaks TUN-seadet liideste loendis tõestavad, et mõlemad deemonid käivitusid; need ei ütle midagi selle kohta, millist konkreetne klient kasutas. Teine jooks, kus üks tunnel on kadunud, on see, mis näitab, kas teie varureegel teeb seda, mida kavatsesite.