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

To OpenVPN-dæmoner kan begge rapportere en vellykket tunnel, mens gatewayen sender hver klient ned ad den samme. Intet i håndtrykket afgør, hvilken tunnel en klient bruger; kernen afgør det, pakke for pakke, ved at gennemgå politikreglerne og derefter den tabel, hver regel navngiver. Når du ser på det sådan, holder konfigurationen op med at handle om OpenVPN-indstillinger og bliver en routingmatrix med to ejere.

Kernen bestemmer, ikke dæmonen

En videresendt pakke ankommer på LAN-interfacet, og routingkoden evaluerer regellisten i prioritetsrækkefølge. Den første regel, hvis selektor matcher, navngiver en tabel, og den tabels ruter vælger udgangsenheden. Hvis tabellen ikke har nogen matchende rute, fortsætter opslaget til den næste regel, og det er den detalje, der får et halvfærdigt opsæt til at fejle stille i stedet for højt.

Tunnelprocessen har ingen indflydelse på den gennemgang. Den opretter et interface og kan installere ruter, men om en bestemt klients pakke kommer ind i det interface, afhænger fuldstændigt af den tabel, den blev sendt til. To tunneler med identiske importerede ruter konkurrerer derfor, og den sidste skriver vinder for alle. Det er derfor, et opsæt kan se afbalanceret ud i konfigurationsfilerne og alligevel sende alle klienter gennem én dæmon.

Giv hver instans sit eget resursesæt

Begynd med navne, fordi genbrugte navne er måden, hvorpå de to instanser ved et uheld ender med at dele tilstand. Tildel forskellige tunneleenheder, forskellige konfigurationsfiler, forskellige legitimationsoplysninger og forskellige serviceenheder. Notér hver instans' ydre endepunkt og tunneladresse i samme tabel som politikmatricen, så en senere ændring har ét sted at kigge hen.

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

dev tun-lab
route-nopull

route-nopull holder en servers påskubbede ruter ude af den lokale tabel, hvilket er præcis det, du vil have, når politiktabellerne skal være eksplicitte. Om en given server også skubber en redirect-gateway-indstilling, og om din klientversion understøtter filterformen, er værd at tjekke i manualen i stedet for at antage.

Skriv matricen: kilde, tabel, enhed

Tilføj for hver klientgruppe en regel, der vælger en tabel efter kildeadresse, og læg derefter den tilsigtede vej i den 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

Tabellen skal have de destinationsruter, gruppen bør have, plus de lokale eller administrative undtagelser, der holder gatewayen brugbar. En tabel, der kun indeholder en standardrute, er en full-tunnel-politik for den gruppe, hvilket måske er helt rigtigt, men det bør være en beslutning frem for en udeladelse.

Tunnelens egen transport er ikke i en klientgruppe

Hver dæmons krypterede pakker udgår fra gatewayen selv og er adresseret til den ydre peer. En regel, der kun matcher et klientkilde-præfiks, lader disse pakker være i fred, og derfor er kildescopede regler sikrere end regler, der matcher alt. En regel uden selektor kan fange tunnelens egen transport og sende den tilbage gennem en tunnel, og forbindelsen fejler derefter på en måde, der ligner et udbyderproblem.

Hold den lokale administrationssession og underlagsstien eksplicit ude af politiktabellerne. Skriv de undtagelser ned ved siden af matricen; de er en del af designet, ikke en omvej, der skal genopdages under en hændelse.

At vælge en vej tillader den ikke

Tilladelse til videresendelse er en anden beslutning, der træffes senere på vejen. En firewallregel, der accepterer pakker, som forlader gennem den anden tunnel, får ikke routingkoden til at vælge den, og en korrekt tabel giver ikke tilladelse til at videresende. Begge skal være der, og en test, der kun beviser den ene, vil vildlede dig om den anden. Når én gruppe virker og den anden ikke, skal du kontrollere disse to trin hver for sig i stedet for at skrive tabellerne om.

Kildeoversættelse er en tredje beslutning, og den bør afgrænses til kildegruppen og den tunneleenhed, der faktisk bærer den. Tilføj en dedikeret kæde til de to instanser i stedet for at tømme postrouting-kæden, fordi ubeslægtede tjenester kan have poster der, og en tømning fjerner dem lydløst.

Hvad der sker, når en tunnel falder

Beslut fejladfærden på forhånd. Når en tunneltabel mister sin rute, falder opslaget igennem til den næste regel, og gruppens trafik fortsætter gennem den anden tunnel eller det almindelige uplink uden nogen fejl. Hvis det ikke er acceptabelt, skal du tilføje en afsluttende regel med et lavere prioritetsnummer, der returnerer et uopnåeligt resultat for den kilde, så tabet er synligt i stedet for at blive absorberet.

Send en frisk anmodning fra hver kildegruppe, og notér fire fakta: den valgte tabel, udgangsenheden, den oversatte kilde og om svaret kom tilbage ad samme vej. Sæt derefter en tunnel ned, og gentag. To TUN-enheder i en interfaceliste beviser, at begge dæmoner startede; de siger intet om, hvilken en given klient brugte. Den anden kørsel, med en tunnel væk, er den, der viser, om din fallback-regel gør, hvad du havde til hensigt.