Jedna servisní IP na každém uzlu OpenVPN: co nedělá

Klient se připojí k jednomu z několika OpenVPN serverů a pak potřebuje malou službu, která běží na tomto uzlu: stavovou stránku, metriky, zálohovacího agenta. Když každý uzel dostane stejnou privátní servisní adresu, konfigurace klienta je stejná bez ohledu na to, na který server se dostal. Tato výhoda je skutečná a zároveň snadno přecenitelná: sdílená adresa vám řekne, na který uzel jste se dostali, ne že je něco nadbytečné.

Proč stejná adresa na každém uzlu funguje

Každý uzel adresu vlastní lokálně a odpovídá za ni, takže klient, který se k ní dostane svým aktuálním tunelem, získá službu na druhém konci tohoto tunelu. Mezi uzly se nic nekoordinuje a žádný provoz nepřechází z jednoho uzlu na druhý.

Adresa je lokální štítek, opakovaný, nikoli replikovaný. Každý uzel odpovídá jen za sebe a žádný z nich nepřeposílá provoz jménem adresy na jiném uzlu. To udržuje jednu klientskou konfiguraci platnou, zatímco servery zůstávají nezávislé. Proto také návrh nepotřebuje žádnou koordinaci mezi uzly.

Proto stejná konfigurace funguje na každém serveru bez směrovacího protokolu mezi nimi. Proto také návrh nic neříká o zdraví: adresa existuje na nezdravém uzlu stejně jako na zdravém, protože je vázaná na hostitele, nikoli na to, zda je služba užitečná.

Přiřaďte ji loopbacku, ne tunelu

Umístění adresy na loopback rozhraní ji odděluje od životnosti jakéhokoli tunelového zařízení, takže opětovné připojení nebo načtení konfigurace ji neodstraní. Adresa existuje tak dlouho jako hostitel.

Adresa na lo není filtr. Služba na ní stále musí naslouchat a firewall hostitele stále vyhodnocuje skutečnou příchozí cestu, která přichází přes tunelové rozhraní. Kdo předpokládá, že loopback znamená jen lokálně, nakonec buď blokuje legitimní klienty, nebo vystavuje něco, co nezamýšlel.

Zajistěte trvalost přiřazení přes síťovou konfiguraci hostitele, místo abyste ji znovu přidávali z hooku. Nastavovací hook se nespustí na uzlu, kde tunel nenaběhl, a servisní adresa by neměla záviset na aktivitě tunelu. Vložte adresu do konfigurace rozhraní, kterou vlastní vaše distribuce, poté jednou restartujte a ověřte ji. Restart je jediný test, který přežije pozdější změnu konfigurace.

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

Pošlete jednu trasu a myslete jedno cílové místo

Klient potřebuje hostitelskou trasu k adrese, kterou nabízí server, k němuž se připojuje. Protože každý server nabízí stejné cílové místo, profil se při přesunu klienta nemění.

Ověřte, co klient nainstaloval, než obviníte službu.

ip route get 10.250.0.1

Pro HTTP službu dejte adrese jméno a certifikát pro toto jméno. Sdílená IP není identita a neodstraňuje ověření TLS, ani neospravedlňuje kopírování jednoho privátního klíče na každý uzel. Jméno, které se překládá na sdílenou adresu, udržuje příběh certifikátu obyčejný a umožňuje vám ponechat identitu pro každý uzel, pokud ji potřebujete.

Co sdílená adresa neumí

Neposkytuje přepnutí při výpadku. Pokud vybraný uzel zemře, adresa zemře s ním a klient se musí připojit jinde.

Nemigruje živou TCP relaci, protože nové spojení končí na jiném hostiteli bez jakékoli znalosti toho starého.

Nevybírá zdravý uzel, nevyvažuje zátěž ani nesynchronizuje data mezi uzly. Každé z toho je samostatný mechanismus s vlastními režimy selhání, a předstírání, že trik s adresováním je pokrývá, je způsob, jakým jednoduchý návrh získá nezaslouženou reputaci odolnosti. Pokud jsou aktivní dva tunely současně, význam cíle se stane nejednoznačným, proto držte předpoklad jednoho aktivního tunelu explicitní.

Zachovejte identitu služby se jménem

Zapište, co adresa znamená: dostane se ke službě na uzlu, k němuž je klient právě připojen. Tato jediná věta zabrání většině nedorozumění, která tento vzor přitahuje.

Potom zdokumentujte části společně: adresu, rozhraní, na kterém žije, trasu, kterou server posílá, a jméno a certifikát, které služba předkládá. Čtyři malá fakta, která budoucí čtenář může ověřit, v pořadí, v jakém je bude kontrolovat.

Pokud je požadavkem stabilní cíl pro službu lokální na uzlu, vzor sedí a nestojí téměř nic.

Pokud je požadavkem dostupnost, posuňte se o vrstvu výš: vyvažovač zátěže, jméno služby s kontrolami zdraví nebo orchestrační systém, který už umí nahradit uzel.

Rozhodnutí učiněné brzy udrží sdílenou adresu tím, čím je, pohodlným štítkem, místo komponentou, od níž se tiše očekává práce, pro kterou nebyla nikdy navržena.