Un singur IP de serviciu pe fiecare nod OpenVPN: ce nu face

Un client se conectează la unul dintre mai multe servere OpenVPN și apoi are nevoie de un serviciu mic care rulează pe acel nod: o pagină de stare, un punct final de metrici, un agent de copii de siguranță. Dacă fiecare nod primește aceeași adresă privată de serviciu, configurația clientului rămâne identică indiferent pe ce server a ajuns. Acel confort este real și este la fel de ușor de suprainterpretat: adresa comună spune la ce nod ai ajuns, nu că ceva este redundant.

De ce aceeași adresă pe fiecare nod funcționează

Fiecare nod deține adresa local și răspunde pentru ea, așa că un client care o atinge prin tunelul său actual primește serviciul la celălalt capăt al acelui tunel. Nimic nu este coordonat între noduri și niciun trafic nu trece de la un nod la altul.

Adresa este o etichetă locală, repetată și nu replicată. Fiecare nod răspunde doar pentru sine, iar niciunul dintre ele nu redirecționează trafic pentru adresă în numele altui nod. Aceasta este ceea ce menține valabilă o singură configurație de client în timp ce serverele rămân independente. Este și motivul pentru care proiectarea nu are nevoie de nicio coordonare între noduri.

De aceea aceeași configurație funcționează pe fiecare server fără un protocol de rutare între ele. Este și motivul pentru care proiectarea nu spune nimic despre sănătate: adresa există pe un nod bolnav exact ca pe unul sănătos, pentru că este legată de gazdă și nu de faptul că serviciul este util.

Atribuie-o loopback-ului, nu tunelului

Punerea adresei pe o interfață loopback o decuplează de durata de viață a oricărui dispozitiv de tunel, astfel încât o reconectare sau o reîncărcare a configurației nu o elimină. Adresa există atât timp cât există gazda.

O adresă pe lo nu este un filtru. Serviciul tot trebuie să asculte pe ea, iar paravanul gazdei evaluează în continuare calea reală de intrare, care sosește pe interfața tunelului. Cine presupune că loopback înseamnă doar local ajunge fie să blocheze clienți legitimi, fie să expună ceva ce nu intenționa.

Fă atribuirea persistentă prin configurația de rețea a gazdei în loc să o adaugi din nou dintr-un hook. Un hook de instalare nu se declanșează pe un nod unde nu a urcat niciun tunel, iar adresa serviciului nu ar trebui să depindă de activitatea tunelului. Pune adresa în configurația interfeței pe care o administrează distribuția ta, apoi repornește o dată și verifică. O repornire este singurul test care supraviețuiește unei modificări ulterioare de configurație.

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

Împinge o singură rută și înțelege o singură destinație

Clientul are nevoie de o rută de gazdă pentru adresă, oferită de serverul la care se conectează. Deoarece fiecare server oferă aceeași destinație, profilul nu se schimbă când clientul se mută.

Verifică ce a instalat clientul înainte de a da vina pe serviciu.

ip route get 10.250.0.1

Pentru un serviciu HTTP, dă adresei un nume și un certificat pentru acel nume. IP-ul comun nu este o identitate și nu elimină verificarea TLS, nici nu justifică copierea unei chei private pe fiecare nod. Un nume care se rezolvă la adresa comună păstrează povestea certificatului obișnuită și îți permite să păstrezi o identitate pe nod dacă ai nevoie.

Ce nu poate face adresa comună

Nu oferă preluare în caz de defect. Dacă nodul ales moare, adresa moare odată cu el, iar clientul trebuie să se reconecteze în altă parte.

Nu migrează o sesiune TCP activă, pentru că o conexiune nouă se termină pe o altă gazdă care nu știe nimic despre cea veche.

Nu alege un nod sănătos, nu echilibrează încărcarea și nu sincronizează date între noduri. Fiecare dintre acestea este un mecanism separat cu propriile moduri de defectare, iar a pretinde că trucul de adresare le acoperă este felul în care o proiectare simplă dobândește o reputație nemeritată de rezistență. Dacă două tuneluri sunt active simultan, sensul destinației devine ambiguu, așa că păstrează explicit ipoteza unui singur tunel activ.

Păstrează identitatea serviciului împreună cu numele

Scrie ce înseamnă adresa: ajunge la serviciul de pe nodul la care clientul este conectat acum. Acea singură propoziție previne cea mai mare parte a neînțelegerii pe care o atrage acest model.

Apoi documentează piesele împreună: adresa, interfața pe care trăiește, ruta pe care o împinge serverul și numele și certificatul pe care le prezintă serviciul. Patru fapte mici pe care un cititor viitor le poate verifica, în ordinea în care le va controla.

Dacă cerința este o destinație stabilă pentru un serviciu local nodului, modelul se potrivește și nu costă aproape nimic.

Dacă cerința este disponibilitatea, urcă un strat: un balansator de încărcare, un nume de serviciu cu verificări de sănătate sau un sistem de orchestrare care știe deja cum să înlocuiască un nod.

A decide asta devreme păstrează adresa comună ceea ce este, o etichetă comodă, în locul unei componente de la care se așteaptă în tăcere o muncă pentru care nu a fost niciodată proiectată.