Twa OpenVPN-klanten op ien Linux-poarte: ferdiel it belied

Twa OpenVPN-daemons kinne beide in suksesfolle tunnel melde wylst de poarte elke klant by deselde del stjoert. Neat yn ’e hânskud beslúdt hokker tunnel in klant brûkt; de kearn beslúdt, pakket foar pakket, troch de beliedsregels en dan de tabel te rinnen dy’t elke regel neamt. Ienris’t jo it sa besjogge, giet de konfiguraasje net mear oer OpenVPN-opsjes en wurdt it in routingmatriks mei twa eigners.

De kearn beslúdt, net de daemon

In trochstjoerd pakket komt op ’e LAN-ynterface oan en de routingkoade evaluearret de regellist yn prioriteitsfolchoarder. De earste regel wêrfan’t de selektor past, neamt in tabel, en de rûtes fan dy tabel kieze it útfiereapparaat. As de tabel gjin passende rûte hat, giet de syktocht troch nei de folgjende regel, en dat is it detail dat in healôffre set dy’t stil mislearret ynstee fan lûd.

It tunnelproses hat dêr gjin sizzen yn. It makket in ynterface en kin rûtes ynstallearje, mar oft it pakket fan in bepaald klant dy ynterface ynkomt, hinget folslein ôf fan ’e tabel dêr’t it nei stjoerd waard. Twa tunnels mei identike ymportearre rûtes konkurrearje dêrom, en de lêste skriuwer wint foar elkenien. Dêrom kin in set der yn ’e konfiguraasjefilen balansearre útsjen en dochs alle klanten troch ien daemon stjoere.

Jou elk eksimplaar syn eigen boarneset

Begjin mei nammen, want werbrûkte nammen binne de manier wêrop’t de twa eksimplaren by ûngelok steat diele. Jou aparte tunnelapparaten, aparte konfiguraasjefilen, aparte legitimearrings en aparte tsjinst-ienheden. Skriuw it bûtenste einpunt en tunneladres fan elk eksimplaar yn deselde tabel as de beliedsmatriks, sadat in lettere wiziging ien plak hat om te sjen.

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

dev tun-lab
route-nopull

route-nopull hâldt de rûtes dy’t in server skoot bûten de lokale tabel, en dat is krekt wat jo wolle as de beliedstabellen eksplisyt wêze moatte. Oft in bepaalde server ek in redirect-gateway-opsje skoot, en oft jo klantferzje de filterfoarm stipet, is it wurdich yn ’e hânlieding nei te gean ynstee fan oan te nimmen.

Skriuw de matriks: boarne, tabel, apparaat

Foar elke klantgroep, foegje in regel ta dy’t in tabel by boarneyndres kiest, en set dan it bedoelde paad yn dy tabel:

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

De tabel hat de bestimmingsrûtes nedich dy’t de groep hawwe moat, plus hokker lokale of behearskregele útsûnderingen ek de poarte brûkber hâlde. In tabel mei allinne in standertrûte is in foltunnelbelied foar dy groep, wat miskien krekt goed is, mar it soe in beslissing wêze moatte en net in weglitting.

It eigen ferfier fan ’e tunnel is net yn in klantgroep

De fersifere pakketten fan elke daemon ûntsteane op ’e poarte sels, rjochte op ’e bûtenste peer. In regel dy’t allinne in klantboarneprefiks past, lit dy pakketten gewurde, en dêrom binne boarnebeheinde regels feiliger as regels dy’t alles passe. In regel sûnder selektor kin it eigen ferfier fan ’e tunnel fange en it weromstjoere troch in tunnel, en dan mislearret de ferbining op in manier dy’t op in providerprobleem liket.

Hâld de lokale behearsesje en it paad fan ’e ûnderlaach eksplisyt bûten de beliedstabellen. Skriuw dy útsûnderingen njonken de matriks; se binne diel fan it ûntwerp, net in omwei dy’t by in ynsidint werûntdekt wurde moat.

In paad kieze tastiet it net

Tastimming foar trochstjoeren is in twadde beslissing dy’t letter yn it paad nommen wurdt. In fjoerwâlregel dy’t pakketten akseptearret dy’t troch de twadde tunnel fuortgeane, makket net dat de routingkoade dy kiest, en in korrekte tabel jout gjin tastimming om troch te stjoeren. Beide moatte bestean, en in test dy’t mar ien fan beide bewissiget, sil jo oer de oare misliede. As ien groep wurket en de oare net, kontrolearje dy twa stappen apart ynstee fan ’e tabellen te werskriuwen.

Boarnefertarring is in tredde beslissing, en it soe beheind wurde moatte ta de boarnegroep en it tunnelapparaat dat it echt draacht. Foegje in wijdde keatling ta foar de twa eksimplaren ynstee fan ’e postrouting-keatling te leegjen, want net besibbe tsjinsten kinne dêr yngongen hawwe en in leegje hellet se stil fuort.

Wat bart der as ien tunnel falt

Beslis it faalgedrach foarôf. As in tunneltabel syn rûte ferliest, falt de syktocht troch nei de folgjende regel, en it ferkear fan ’e groep giet troch de oare tunnel of de gewoane boppelink sûnder ienige flater. As dat net akseptabel is, foegje in ôfslutende regel ta mei in leger prioriteitsnûmer dy’t foar dy boarne in ûnberikber resultaat weromjout, sadat it ferlies sichtber is ynstee fan opsocht te wurden.

Stjoer in nij fersyk fan elke boarnegroep en skriuw fjouwer feiten op: de keazen tabel, it útfiereapparaat, de fertaalde boarne, en oft it antwurd weromkaam troch itselde paad. Set dan ien tunnel del en werhelje. Twa TUN-apparaten yn in ynterfacelist bewize dat beide daemons start binne; se sizze neat oer hokker ien in bepaald klant brûkt hat. De twadde run, mei ien tunnel fuort, is dy’t sjen lit oft jo fallbackregel docht wat jo bedoelden.