Eén service-IP op elke OpenVPN-node: wat het niet doet

Een client verbindt met een van meerdere OpenVPN-servers en heeft dan een kleine dienst nodig die op die node draait: een statuspagina, een metrics-endpoint, een backup-agent. Elke node hetzelfde privé-serviceadres geven maakt de configuratie van de client identiek, ongeacht op welke server hij landde. Dat gemak is echt, en het is ook makkelijk te overinterpreteren: het gedeelde adres vertelt je welke node je bereikte, niet dat iets redundant is.

Waarom hetzelfde adres op elke node werkt

Elke node bezit het adres lokaal en antwoordt ervoor, zodat een client die het via zijn huidige tunnel bereikt de dienst aan de andere kant van die tunnel krijgt. Er wordt niets tussen nodes gecoördineerd, en er gaat geen verkeer van de ene node naar de andere.

Het adres is een lokaal label, herhaald in plaats van gerepliceerd. Elke node antwoordt alleen voor zichzelf, en geen van hen stuurt verkeer voor het adres door namens een andere node. Dat houdt één clientconfiguratie geldig terwijl de servers onafhankelijk blijven. Het is ook de reden waarom het ontwerp geen coördinatie tussen de nodes nodig heeft.

Daarom werkt dezelfde configuratie op elke server zonder routeringsprotocol ertussen. Het is ook de reden waarom het ontwerp niets zegt over gezondheid: het adres bestaat op een ongezonde node precies zoals op een gezonde, omdat het aan de host is gebonden en niet aan of de dienst nuttig is.

Wijs het toe aan loopback, niet aan de tunnel

Het adres op een loopback-interface zetten koppelt het los van de levensduur van elk tunnelapparaat, zodat een herverbinding of het herladen van de configuratie het niet verwijdert. Het adres bestaat zolang de host bestaat.

Een adres op lo is geen filter. De dienst moet er nog steeds op luisteren, en de firewall van de host beoordeelt nog steeds het echte inkomende pad, dat op de tunnel-interface aankomt. Wie aanneemt dat loopback alleen lokaal betekent, blokkeert uiteindelijk legitieme clients of stelt iets bloot dat hij niet van plan was.

Maak de toewijzing duurzaam via de netwerkconfiguratie van de host in plaats van haar opnieuw toe te voegen vanuit een hook. Een setup-hook wordt niet uitgevoerd op een node waar geen tunnel opkwam, en het serviceadres hoort niet van tunnelactiviteit afhankelijk te zijn. Zet het adres in de interfaceconfiguratie die je distributie beheert, herstart dan één keer en controleer het. Een herstart is de enige test die een latere configuratiewijziging overleeft.

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

Push één route en bedoel één bestemming

De client heeft een hostroute voor het adres nodig, aangeboden door de server waarmee hij verbindt. Omdat elke server dezelfde bestemming biedt, verandert het profiel niet wanneer de client beweegt.

Controleer wat de client heeft geïnstalleerd voordat je de dienst de schuld geeft.

ip route get 10.250.0.1

Geef het adres voor een HTTP-dienst een naam en een certificaat voor die naam. Het gedeelde IP is geen identiteit, en het haalt de TLS-verificatie niet weg, en het rechtvaardigt ook niet het kopiëren van één privésleutel naar elke node. Een naam die naar het gedeelde adres resolvet, houdt het certificaatverhaal gewoon en laat je een identiteit per node behouden als je die nodig hebt.

Wat het gedeelde adres niet kan

Het biedt geen failover. Als de gekozen node sterft, sterft het adres mee, en de client moet elders opnieuw verbinden.

Het migreert geen levende TCP-sessie, omdat een nieuwe verbinding eindigt op een andere host die niets van de oude weet.

Het kiest geen gezonde node, balanceert geen belasting en synchroniseert geen gegevens tussen nodes. Elk daarvan is een apart mechanisme met zijn eigen faalwijzen, en doen alsof de adresseringstruc ze dekt is hoe een eenvoudig ontwerp een onverdiende reputatie van veerkracht krijgt. Als twee tunnels tegelijk actief zijn, wordt de betekenis van de bestemming dubbelzinnig, dus houd de aanname van één actieve tunnel expliciet.

Houd de dienstidentiteit bij de naam

Schrijf op wat het adres betekent: het bereikt de dienst op de node waarmee de client nu verbonden is. Die ene zin voorkomt het grootste deel van het misverstand dat dit patroon aantrekt.

Documenteer daarna de onderdelen samen: het adres, de interface waarop het leeft, de route die de server pusht, en de naam en het certificaat die de dienst presenteert. Vier kleine feiten die een toekomstige lezer kan verifiëren, in de volgorde waarin hij ze zal controleren.

Als de eis een stabiele bestemming is voor een node-lokale dienst, past het patroon en kost het bijna niets.

Als de eis beschikbaarheid is, ga een laag hoger: een load balancer, een servicenaam met health checks, of een orkestratiesysteem dat al weet hoe een node vervangen wordt.

Dat vroeg beslissen houdt het gedeelde adres wat het is, een handig label, in plaats van een component waarvan stil wordt verwacht dat het werk doet waarvoor het nooit is ontworpen.