Twee OpenVPN-clients op één Linux-gateway: verdeel het beleid

Twee OpenVPN-daemons kunnen allebei een geslaagde tunnel melden terwijl de gateway elke client via dezelfde stuurt. Niets in de handshake bepaalt welke tunnel een client gebruikt; de kernel beslist, pakket voor pakket, door de beleidsregels en daarna de tabel die elke regel noemt te doorlopen. Zo bekeken gaat de configuratie niet meer over OpenVPN-opties maar wordt het een routeringsmatrix met twee eigenaren.

De kernel beslist, niet de daemon

Een doorgestuurd pakket komt binnen op de LAN-interface en de routeringscode beoordeelt de regellijst in prioriteitsvolgorde. De eerste regel waarvan de selector overeenkomt, noemt een tabel, en de routes van die tabel kiezen het uitvoerapparaat. Als de tabel geen overeenkomende route heeft, gaat de opzoeking verder naar de volgende regel, en dat detail zorgt ervoor dat een half afgemaakte opzet stil faalt in plaats van luid.

Het tunnelproces heeft in die gang niets te zeggen. Het maakt een interface aan en kan routes installeren, maar of het pakket van een bepaalde client die interface binnenkomt, hangt volledig af van de tabel waarnaar het is gestuurd. Twee tunnels met identieke geïmporteerde routes concurreren daarom, en de laatste schrijver wint voor iedereen. Daarom kan een opzet in de configuratiebestanden uitgebalanceerd lijken en toch alle clients via één daemon sturen.

Geef elke instantie zijn eigen ressursset

Begin met namen, want hergebruikte namen zijn de manier waarop de twee instanties per ongeluk toestand gaan delen. Wijs afzonderlijke tunnelapparaten, afzonderlijke configuratiebestanden, afzonderlijke inloggegevens en afzonderlijke service-eenheden toe. Leg het buitenste eindpunt en tunneladres van elke instantie vast in dezelfde tabel als de beleidsmatrix, zodat een latere wijziging één plek heeft om te kijken.

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

dev tun-lab
route-nopull

route-nopull houdt de routes die een server duwt buiten de lokale tabel, en dat is precies wat je wilt wanneer de beleidstabellen expliciet horen te zijn. Of een bepaalde server ook een redirect-gateway-optie duwt, en of je clientversie de filtervorm ondersteunt, is het waard in de handleiding na te kijken in plaats van aan te nemen.

Schrijf de matrix: bron, tabel, apparaat

Voeg voor elke clientgroep een regel toe die een tabel op bronadres kiest, en zet daarna het bedoelde pad in die 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 heeft de bestemmingsroutes nodig die de groep hoort te hebben, plus eventuele lokale of beheeruitzonderingen die de gateway bruikbaar houden. Een tabel met alleen een standaardroute is een full-tunnelbeleid voor die groep, wat precies goed kan zijn, maar het hoort een beslissing te zijn en geen weglating.

Het eigen transport van de tunnel zit niet in een clientgroep

De versleutelde pakketten van elke daemon ontstaan op de gateway zelf, gericht aan de buitenste peer. Een regel die alleen overeenkomt met een bronprefix van een client laat die pakketten met rust, en daarom zijn bronbeperkte regels veiliger dan regels die met alles overeenkomen. Een regel zonder selector kan het eigen transport van de tunnel vangen en het via een tunnel terugsturen, en dan faalt de verbinding op een manier die op een providerprobleem lijkt.

Houd de lokale beheersessie en het pad van de onderlaag expliciet buiten de beleidstabellen. Schrijf die uitzonderingen naast de matrix; ze horen bij het ontwerp en zijn geen omweg die tijdens een incident opnieuw moet worden ontdekt.

Een pad kiezen staat het niet toe

Doorstuurrecht is een tweede beslissing die later in het pad wordt genomen. Een firewallregel die pakketten accepteert die via de tweede tunnel vertrekken, zorgt er niet voor dat de routeringscode die tunnel kiest, en een correcte tabel geeft geen toestemming om door te sturen. Beide moeten bestaan, en een test die er maar één bewijst, zal je over de andere misleiden. Wanneer de ene groep werkt en de andere niet, controleer die twee stappen dan apart in plaats van de tabellen te herschrijven.

Brontranslatie is een derde beslissing, en die hoort beperkt te blijven tot de brongrupp en het tunnelapparaat dat hem werkelijk draagt. Voeg een aparte keten voor de twee instanties toe in plaats van de postrouting-keten te legen, want niet-verwante diensten kunnen daar vermeldingen hebben en leegmaken haalt ze stil weg.

Wat er gebeurt als één tunnel wegvalt

Beslis het faalgedrag vooraf. Als een tunneltabel zijn route verliest, valt de opzoeking door naar de volgende regel, en het verkeer van de groep gaat zonder enige fout verder via de andere tunnel of de gewone uplink. Als dat niet acceptabel is, voeg dan een afsluitende regel met een lager prioriteitsnummer toe die voor die bron een onbereikbaar resultaat teruggeeft, zodat het verlies zichtbaar is in plaats van geabsorbeerd.

Stuur een nieuw verzoek vanuit elke brongrupp en noteer vier feiten: de gekozen tabel, het uitvoerapparaat, de vertaalde bron en of het antwoord via hetzelfde pad terugkwam. Haal daarna één tunnel neer en herhaal. Twee TUN-apparaten in een interfacelijst bewijzen dat beide daemons zijn gestart; ze zeggen niets over welke een bepaalde client gebruikte. De tweede run, met één tunnel minder, is degene die laat zien of je terugvalregel doet wat je bedoelde.