To OpenVPN-klientar på éin Linux-gateway: del politikken

To OpenVPN-demonar kan begge rapportere ein vellukka tunnel medan gatewayen sender kvar klient ned den same. Ingenting i handtrykket avgjer kva tunnel ein klient brukar; kjernen avgjer, pakke for pakke, ved å gå gjennom politikkreglane og deretter tabellen kvar regel namngjev. Når ein ser det slik, sluttar konfigurasjonen å handle om OpenVPN-val og blir ei rutematrise med to eigarar.

Kjernen avgjer, ikkje demonen

Ei vidaresend pakke kjem inn på LAN-grensesnittet, og rutekoden vurderer regellista i prioritetsrekkjefølgje. Den første regelen der veljaren samsvarar, namngjev ein tabell, og rutene i den tabellen vel utgangseininga. Viss tabellen ikkje har noka samsvarande rute, held oppslaget fram til neste regel, og det er denne detaljen som gjer at eit halvferdig oppsett feilar stille i staden for høgt.

Tunnelprosessen har ingenting å seie i den gjennomgangen. Han opprettar eit grensesnitt og kan installere ruter, men om pakka frå ein bestemt klient kjem inn i det grensesnittet, kjem heilt an på tabellen ho vart send til. To tunnelar med identiske importerte ruter konkurrerer derfor, og den siste som skriv vinn for alle. Derfor kan eit oppsett sjå balansert ut i konfigurasjonsfilene og likevel sende alle klientar gjennom éin demon.

Gje kvar instans sitt eige ressurssett

Byrj med namn, fordi gjenbrukte namn er måten dei to instansane ved eit uhell endar med å dele tilstand. Tildel særskilde tunneleiningar, særskilde konfigurasjonsfiler, særskilde legitimasjonar og særskilde tenesteeiningar. Noter det ytre endepunktet og tunneladressa til kvar instans i same tabell som politikkmatrisa, slik at ei seinare endring har éin stad å sjå.

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

dev tun-lab
route-nopull

route-nopull held rutene ein tenar skyv utanfor den lokale tabellen, og det er nettopp det du vil når politikktabellane skal vere eksplisitte. Om ein gitt tenar også skyv eit redirect-gateway-val, og om klientversjonen din støttar filterforma, er verdt å sjekke i handboka i staden for å gjette.

Skriv matrisa: kjelde, tabell, eining

For kvar klientgruppe, legg til ein regel som vel ein tabell etter kjeldeadresse, og legg deretter den tiltenkte vegen i den tabellen:

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

Tabellen treng destinasjonsrutene gruppa skal ha, pluss eventuelle lokale eller administrative unntak som held gatewayen brukbar. Ein tabell som berre inneheld ei standardrute er ein full-tunnel-politikk for den gruppa, noko som kan vere heilt rett, men det bør vere ei avgjerd og ikkje ei utelating.

Den eigen transporten til tunnelen er ikkje i ei klientgruppe

Dei krypterte pakkane til kvar demon oppstår på gatewayen sjølv, adresserte til den ytre parten. Ein regel som berre samsvarar med eit klientkjelde-prefiks, let desse pakkane vere i fred, og derfor er kjeldeavgrensa reglar tryggare enn reglar som samsvarar med alt. Ein regel utan veljar kan fange den eigen transporten til tunnelen og sende han tilbake gjennom ein tunnel, og sambandet feilar då på ein måte som ser ut som eit leverandørproblem.

Hald den lokale administrasjonssesjonen og underlagsvegen eksplisitt utanfor politikktabellane. Skriv desse unntaka ved sida av matrisa; dei er ein del av designet, ikkje ein omveg som må oppdagast på nytt under ei hending.

Å velje ein veg tillèt han ikkje

Løyve til vidaresending er ei anna avgjerd som blir teken seinare på vegen. Ein brannmurregel som godtek pakker som forlèt gjennom den andre tunnelen, får ikkje rutekoden til å velje han, og ein korrekt tabell gir ikkje løyve til å senda vidare. Begge må finnast, og ein test som berre provar éin av dei vil villede deg om den andre. Når éi gruppe verkar og den andre ikkje, sjekk desse to trinna kvar for seg i staden for å skrive om tabellane.

Kjeldeomsetjing er ei tredje avgjerd, og ho bør avgrensast til kjeldegruppa og tunneleininga som faktisk ber henne. Legg til ei eiga kjede for dei to instansane i staden for å tømme postrouting-kjeda, fordi urelaterte tenester kan ha oppføringar der, og ei tømming fjernar dei lydlaust.

Kva som skjer når éin tunnel fell

Avgjer feilåtferda på førehand. Når ein tunneltabell mistar ruta si, fell oppslaget gjennom til neste regel, og trafikken til gruppa held fram gjennom den andre tunnelen eller den vanlege opplenkja utan nokon feil. Viss det ikkje er akseptabelt, legg til ein avsluttande regel med lågare prioritetsnummer som returnerer eit uoppnåeleg resultat for den kjelda, slik at tapet er synleg i staden for å bli absorbert.

Send ei ny førespurnad frå kvar kjeldegruppe og noter fire fakta: tabellen som vart vald, utgangseininga, den omsette kjelda og om svaret kom tilbake same veg. Senk deretter éin tunnel og gjer det om att. To TUN-einingar i ei grensesnittliste provar at begge demonane starta; dei seier ingenting om kven ein gitt klient brukte. Den andre køyringa, med éin tunnel borte, er den som viser om reserve-regelen din gjer det du hadde tenkt.