To OpenVPN-klienter på én Linux-gateway: del politikken

To OpenVPN-demoner kan begge rapportere en vellykket tunnel mens gatewayen sender hver klient ned den samme. Ingenting i håndtrykket avgjør hvilken tunnel en klient bruker; kjernen avgjør, pakke for pakke, ved å gå gjennom politikkreglene og deretter tabellen hver regel navngir. Når du ser det slik, slutter konfigurasjonen å handle om OpenVPN-valg og blir en rutematrise med to eiere.

Kjernen bestemmer, ikke demonen

En videresendt pakke ankommer LAN-grensesnittet, og rutekoden vurderer regellisten i prioritetsrekkefølge. Den første regelen der velgeren samsvarer, navngir en tabell, og rutene i den tabellen velger utgangsenheten. Hvis tabellen ikke har noen samsvarende rute, fortsetter oppslaget til neste regel, og det er denne detaljen som får et halvferdig oppsett til å feile stille i stedet for høyt.

Tunnelprosessen har ingenting å si i den gjennomgangen. Den oppretter et grensesnitt og kan installere ruter, men om pakken fra en bestemt klient kommer inn i det grensesnittet, avhenger helt av tabellen den ble sendt til. To tunneler med identiske importerte ruter konkurrerer derfor, og den siste som skriver vinner for alle. Derfor kan et oppsett se balansert ut i konfigurasjonsfilene og likevel sende alle klienter gjennom én demon.

Gi hver instans sitt eget ressurssett

Begynn med navn, fordi gjenbrukte navn er måten de to instansene ved et uhell ender med å dele tilstand. Tildel separate tunneleenheter, separate konfigurasjonsfiler, separate legitimasjoner og separate tjenesteenheter. Noter hver instans' ytre endepunkt og tunneladresse i samme tabell som politikkmatrisen, slik at en senere endring har ett sted å se.

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

dev tun-lab
route-nopull

route-nopull holder rutene en server skyver utenfor den lokale tabellen, og det er nettopp det du vil når politikktabellene skal være eksplisitte. Om en gitt server også skyver et redirect-gateway-alternativ, og om klientversjonen din støtter filterformen, er verdt å sjekke i håndboken i stedet for å anta.

Skriv matrisen: kilde, tabell, enhet

For hver klientgruppe, legg til en regel som velger en tabell etter kildeadresse, og legg deretter den tiltenkte veien 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 trenger destinasjonsrutene gruppen skal ha, pluss eventuelle lokale eller administrative unntak som holder gatewayen brukbar. En tabell som bare inneholder en standardrute er en full-tunnel-politikk for den gruppen, noe som kan være helt riktig, men det bør være en beslutning og ikke en utelatelse.

Tunnelens egen transport er ikke i en klientgruppe

Hver demons krypterte pakker oppstår på gatewayen selv, adressert til den ytre parten. En regel som bare samsvarer med et klientkilde-prefiks, lar disse pakkene være i fred, og derfor er kildescopede regler tryggere enn regler som samsvarer med alt. En regel uten velger kan fange tunnelens egen transport og sende den tilbake gjennom en tunnel, og forbindelsen feiler da på en måte som ser ut som et leverandørproblem.

Hold den lokale administrasjonssesjonen og underlagsstien eksplisitt utenfor politikktabellene. Skriv disse unntakene ved siden av matrisen; de er en del av designet, ikke en omvei som må gjenoppdages under en hendelse.

Å velge en vei tillater den ikke

Tillatelse til videresending er en annen beslutning som tas senere på veien. En brannmurregel som godtar pakker som forlater gjennom den andre tunnelen, får ikke rutekoden til å velge den, og en korrekt tabell gir ikke tillatelse til å videresende. Begge må finnes, og en test som bare beviser én av dem vil villede deg om den andre. Når én gruppe virker og den andre ikke, sjekk disse to trinnene hver for seg i stedet for å skrive om tabellene.

Kildeoversettelse er en tredje beslutning, og den bør avgrenses til kildegruppen og tunneleenheten som faktisk bærer den. Legg til en dedikert kjede for de to instansene i stedet for å tømme postrouting-kjeden, fordi urelaterte tjenester kan ha oppføringer der, og en tømming fjerner dem lydløst.

Hva som skjer når én tunnel faller

Bestem feilatferden på forhånd. Når en tunneltabell mister ruten sin, faller oppslaget gjennom til neste regel, og gruppens trafikk fortsetter gjennom den andre tunnelen eller den vanlige opplenken uten noen feil. Hvis det ikke er akseptabelt, legg til en avsluttende regel med lavere prioritetsnummer som returnerer et uoppnåelig resultat for den kilden, slik at tapet er synlig i stedet for å bli absorbert.

Send en ny forespørsel fra hver kildegruppe og noter fire fakta: tabellen som ble valgt, utgangsenheten, den oversatte kilden og om svaret kom tilbake samme vei. Senk deretter én tunnel og gjenta. To TUN-enheter i en grensesnittliste beviser at begge demonene startet; de sier ingenting om hvilken en gitt klient brukte. Den andre kjøringen, med én tunnel borte, er den som viser om reserve-regelen din gjør det du hadde tenkt.