Én tjenesteadresse på hver OpenVPN-node: hvad den ikke gør

En klient forbinder til en af flere OpenVPN-servere og har derefter brug for en lille tjeneste, der kører på netop den node: en statusside, et metrics-endpoint, en backup-agent. At give hver node den samme private tjenesteadresse gør klientens konfiguration identisk, uanset hvilken server den landede på. Den bekvemmelighed er reel, og den er også let at overfortolke: den delte adresse fortæller, hvilken node du nåede, ikke at noget er redundant.

Hvorfor den samme adresse på hver node virker

Hver node ejer adressen lokalt og svarer for den, så en klient, der når den gennem sin nuværende tunnel, får tjenesten i den anden ende af netop den tunnel. Intet koordineres mellem noderne, og ingen trafik går fra en node til en anden.

Adressen er en lokal etiket, gentaget snarere end replikeret. Hver node svarer kun for sig selv, og ingen af dem videresender trafik for adressen på en anden nodes vegne. Det er det, der holder én klientkonfiguration gyldig, mens serverne forbliver uafhængige. Det er også derfor, designet ikke kræver koordinering mellem noderne.

Det er derfor, den samme konfiguration virker på hver server uden en routingprotokol mellem dem. Det er også derfor, designet intet siger om sundhed: adressen findes på en usund node præcis som på en sund, fordi den er bundet til værten og ikke til, at tjenesten er brugbar.

Tildel den til loopback, ikke til tunnelen

At lægge adressen på en loopback-interface afkobler den fra levetiden for enhver tunnelenhed, så en genopkobling eller en konfigurationsgenindlæsning ikke fjerner den. Adressen findes, så længe værten gør.

En adresse på lo er ikke et filter. Tjenesten skal stadig lytte på den, og værtens firewall vurderer stadig den reelle indgående vej, som ankommer på tunneleinterfacet. Enhver, der antager, at loopback betyder kun-lokalt, ender med enten at blokere legitime klienter eller at eksponere noget, de ikke havde tænkt sig.

Gør tildelingen varig gennem værtens netværkskonfiguration i stedet for at tilføje den igen fra en hook. En opsætningshook udløses ikke på en node, hvor ingen tunnel kom op, og tjenesteadressen bør ikke afhænge af tunnelaktivitet. Læg adressen i den interfacekonfiguration, din distribution ejer, og genstart derefter én gang og kontroller den. En genstart er den eneste test, der overlever en senere konfigurationsændring.

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

Push én rute og ment ét mål

Klienten har brug for en værtsrute til adressen, tilbudt af den server, den forbinder til. Fordi hver server tilbyder samme mål, ændrer profilen sig ikke, når klienten flytter sig.

Kontrollér, hvad klienten installerede, før du giver tjenesten skylden.

ip route get 10.250.0.1

Til en HTTP-tjeneste skal du give adressen et navn og et certifikat til det navn. Den delte IP er ikke en identitet, og den fjerner ikke TLS-verifikation, og den berettiger heller ikke til at kopiere én privat nøgle til hver node. Et navn, der peger på den delte adresse, holder certifikathistorien almindelig og lader dig beholde en identitet per node, hvis du har brug for en.

Hvad den delte adresse ikke kan

Den giver ikke failover. Hvis den valgte node dør, dør adressen med den, og klienten må genopkoble et andet sted.

Den migrerer ikke en levende TCP-session, fordi en ny forbindelse afsluttes på en anden vært uden kendskab til den gamle.

Den vælger ikke en sund node, afbalancerer ikke last og synkroniserer ikke data mellem noder. Hver af disse er en separat mekanisme med sine egne fejltilstande, og at lade som om adressetrickset dækker dem, er hvordan et enkelt design får et ufortjent ry for robusthed. Hvis to tunneler er aktive samtidig, bliver målets betydning tvetydig, så hold antagelsen om én aktiv tunnel eksplicit.

Hold tjenesteidentiteten sammen med navnet

Skriv ned, hvad adressen betyder: den når tjenesten på den node, klienten aktuelt er forbundet til. Den ene sætning forhindrer det meste af den misforståelse, dette mønster tiltrækker.

Dokumentér derefter delene sammen: adressen, det interface den lever på, ruten serveren pusher, og det navn og certifikat tjenesten præsenterer. Fire små fakta, som en fremtidig læser kan efterprøve, i den rækkefølge de vil kontrollere dem.

Hvis kravet er et stabilt mål for en node-lokal tjeneste, passer mønstret og koster næsten intet.

Hvis kravet er tilgængelighed, flyt et lag op: en load balancer, et servicenavn med health checks eller et orkestreringssystem, der allerede ved, hvordan man erstatter en node.

At beslutte det tidligt holder den delte adresse, hvad den er, en bekvem etiket, i stedet for en komponent, der stille forventes at udføre arbejde, den aldrig blev designet til.