Två OpenVPN-klienter på en Linux-gateway: dela upp policyn

Två OpenVPN-daemoner kan båda rapportera en lyckad tunnel medan gatewayen skickar varje klient ned genom samma. Inget i handskakningen avgör vilken tunnel en klient använder; kärnan avgör, paket för paket, genom att gå igenom policyreglerna och sedan tabellen som varje regel namnger. När man ser det så slutar konfigurationen handla om OpenVPN-alternativ och blir en routingmatris med två ägare.

Kärnan bestämmer, inte daemonen

Ett vidarebefordrat paket kommer in på LAN-gränssnittet och routingkoden utvärderar regellistan i prioritetsordning. Den första regeln vars selektor matchar namnger en tabell, och den tabellens rutter väljer utenheten. Om tabellen inte har någon matchande rutt fortsätter sökningen till nästa regel, och det är den detaljen som får en halvfärdig uppsättning att misslyckas tyst i stället för högt.

Tunnelprocessen har inget att säga i den genomgången. Den skapar ett gränssnitt och kan installera rutter, men om paketet från en viss klient kommer in i det gränssnittet beror helt på tabellen det skickades till. Två tunnlar med identiska importerade rutter konkurrerar därför, och den sista skrivaren vinner för alla. Därför kan en uppsättning se balanserad ut i konfigurationsfilerna och ändå skicka alla klienter genom en enda daemon.

Ge varje instans sin egen resursuppsättning

Börja med namn, eftersom återanvända namn är sättet de två instanserna av misstag börjar dela tillstånd. Tilldela separata tunnelenheter, separata konfigurationsfiler, separata inloggningsuppgifter och separata serviceenheter. Anteckna varje instans yttre ändpunkt och tunneladress i samma tabell som policymatrisen, så att en senare ändring har en plats att titta på.

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

dev tun-lab
route-nopull

route-nopull håller rutter som en server trycker ut utanför den lokala tabellen, och det är precis vad du vill när policytabellerna ska vara explicita. Om en viss server också trycker ut ett redirect-gateway-alternativ, och om din klientversion stöder filterformen, är värt att kontrollera i handboken i stället för att anta.

Skriv matrisen: källa, tabell, enhet

För varje klientgrupp, lägg till en regel som väljer en tabell efter källadress och lägg sedan den avsedda vägen 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 behöver de destinationsrutter gruppen bör ha, plus eventuella lokala eller administrativa undantag som håller gatewayen användbar. En tabell som bara innehåller en standardrutt är en full-tunnelpolicy för den gruppen, vilket kan vara precis rätt, men det bör vara ett beslut och inte en utelämning.

Tunnelns egen transport finns inte i en klientgrupp

Varje daemons krypterade paket uppstår på gatewayen själv, adresserade till den yttre parten. En regel som bara matchar ett klientkällprefix lämnar dessa paket i fred, och därför är källbegränsade regler säkrare än regler som matchar allt. En regel utan selektor kan fånga tunnelns egen transport och skicka tillbaka den genom en tunnel, och anslutningen misslyckas då på ett sätt som ser ut som ett leverantörsproblem.

Håll den lokala administrationssessionen och underlagsvägen uttryckligen utanför policytabellerna. Skriv ned dessa undantag bredvid matrisen; de är en del av designen, inte en kringlösning som måste upptäckas på nytt under en incident.

Att välja en väg tillåter den inte

Tillstånd att vidarebefordra är ett andra beslut som fattas senare på vägen. En brandväggsregel som accepterar paket som lämnar genom den andra tunneln får inte routingkoden att välja den, och en korrekt tabell ger inte tillstånd att vidarebefordra. Båda måste finnas, och ett test som bara bevisar det ena vilseleder dig om det andra. När en grupp fungerar och den andra inte, kontrollera dessa två steg separat i stället för att skriva om tabellerna.

Källöversättning är ett tredje beslut, och det bör begränsas till källgruppen och den tunnelenhet som faktiskt bär den. Lägg till en dedikerad kedja för de två instanserna i stället för att tömma postrouting-kedjan, eftersom orelaterade tjänster kan ha poster där och en tömning tar bort dem tyst.

Vad som händer när en tunnel faller

Bestäm felbeteendet i förväg. När en tunneltabell förlorar sin rutt faller sökningen igenom till nästa regel, och gruppens trafik fortsätter genom den andra tunneln eller den vanliga upplänken utan något fel. Om det inte är acceptabelt, lägg till en avslutande regel med lägre prioritetsnummer som returnerar ett oåtkomligt resultat för den källan, så att förlusten syns i stället för att absorberas.

Skicka en ny begäran från varje källgrupp och anteckna fyra fakta: den valda tabellen, utenheten, den översatta källan och om svaret kom tillbaka samma väg. Sänk sedan en tunnel och upprepa. Två TUN-enheter i en gränssnittslista bevisar att båda daemonerna startade; de säger inget om vilken en viss klient använde. Den andra körningen, med en tunnel borta, är den som visar om din reservregel gör det du avsåg.