En tjänstadress på varje OpenVPN-nod: vad den inte gör

En klient ansluter till en av flera OpenVPN-servrar och behöver sedan en liten tjänst som körs på den noden: en statussida, en metrikendpunkt, en säkerhetskopieringsagent. Att ge varje nod samma privata tjänstadress gör klientens konfiguration identisk oavsett vilken server den landade på. Den bekvämligheten är verklig, och den är också lätt att övertolka: den delade adressen säger vilken nod du nådde, inte att något är redundant.

Varför samma adress på varje nod fungerar

Varje nod äger adressen lokalt och svarar för den, så en klient som når den genom sin nuvarande tunnel får tjänsten i andra änden av den tunneln. Ingenting samordnas mellan noderna och ingen trafik går från en nod till en annan.

Adressen är en lokal etikett, upprepad och inte replikerad. Varje nod svarar bara för sig själv, och ingen av dem vidarebefordrar trafik för adressen å någon annan nods vägnar. Det är detta som håller en klientkonfiguration giltig medan servrarna förblir oberoende. Det är också skälet till att designen inte behöver någon samordning mellan noderna.

Därför fungerar samma konfiguration på varje server utan ett routingprotokoll mellan dem. Det är också skälet till att designen inte säger något om hälsa: adressen finns på en sjuk nod precis som på en frisk, eftersom den är bunden till värden och inte till att tjänsten är användbar.

Tilldela den till loopback, inte till tunneln

Att lägga adressen på ett loopback-gränssnitt kopplar den från livstiden för varje tunnelenhet, så en återanslutning eller en omladdning av konfigurationen tar inte bort den. Adressen finns så länge värden finns.

En adress på lo är inte ett filter. Tjänsten måste fortfarande lyssna på den, och värdens brandvägg utvärderar fortfarande den verkliga inkommande vägen, som anländer på tunnelgränssnittet. Den som antar att loopback bara betyder lokalt slutar antingen med att blockera legitima klienter eller att exponera något de inte avsåg.

Gör tilldelningen varaktig genom värdens nätverkskonfiguration i stället för att lägga till den igen från en hook. En setup-hook utlöses inte på en nod där ingen tunnel kom upp, och tjänstadressen bör inte bero på tunnelaktivitet. Lägg adressen i gränssnittskonfigurationen som din distribution äger, starta sedan om en gång och kontrollera den. En omstart är det enda test som överlever en senare konfigurationsändring.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Pusha en rutt och mena en destination

Klienten behöver en värdrutt för adressen, erbjuden av den server den ansluter till. Eftersom varje server erbjuder samma destination ändras inte profilen när klienten flyttar sig.

Kontrollera vad klienten installerade innan du skyller på tjänsten.

ip route get 10.250.0.1

För en HTTP-tjänst, ge adressen ett namn och ett certifikat för det namnet. Den delade IP-adressen är inte en identitet, och den tar inte bort TLS-verifieringen, och den rättfärdigar inte heller att kopiera en privat nyckel till varje nod. Ett namn som löser till den delade adressen håller certifikathistorien ordinär och låter dig behålla en identitet per nod om du behöver det.

Vad den delade adressen inte kan

Den ger ingen överkoppling. Om den valda noden dör, dör adressen med den, och klienten måste ansluta igen någon annanstans.

Den migrerar inte en levande TCP-session, eftersom en ny anslutning avslutas på en annan värd som inte vet något om den gamla.

Den väljer inte en frisk nod, balanserar inte last och synkroniserar inte data mellan noder. Var och en av dessa är en separat mekanism med sina egna fellägen, och att låtsas att adresseringstricket täcker dem är hur en enkel design får ett oförtjänt rykte om robusthet. Om två tunnlar är aktiva samtidigt blir destinationens betydelse tvetydig, så håll antagandet om en aktiv tunnel explicit.

Håll tjänstens identitet samman med namnet

Skriv ned vad adressen betyder: den når tjänsten på den nod klienten är ansluten till just nu. Den enda meningen förhindrar det mesta av det missförstånd som mönstret drar till sig.

Dokumentera sedan delarna tillsammans: adressen, gränssnittet den lever på, rutten servern pushar, och namnet och certifikatet tjänsten presenterar. Fyra små fakta som en framtida läsare kan verifiera, i den ordning den kommer att kontrollera dem.

Om kravet är en stabil destination för en nodlokal tjänst passar mönstret och kostar nästan ingenting.

Om kravet är tillgänglighet, flytta ett lager upp: en lastbalanserare, ett tjänstenamn med hälsokontroller, eller ett orkestreringssystem som redan vet hur en nod ersätts.

Att avgöra det tidigt håller den delade adressen till det den är, en praktisk etikett, i stället för en komponent som tyst förväntas utföra arbete den aldrig designades för.