Jeden adres IP usługi na każdym węźle OpenVPN: czego nie robi

Klient łączy się z jednym z kilku serwerów OpenVPN, a następnie potrzebuje małej usługi działającej na tym węźle: strony statusu, punktu końcowego metryk, agenta kopii zapasowych. Przydzielenie każdemu węzłowi tego samego prywatnego adresu usługi sprawia, że konfiguracja klienta jest identyczna niezależnie od tego, na którym serwerze wylądował. Ta wygoda jest realna i łatwo ją przeczytać zbyt daleko: wspólny adres mówi, do którego węzła dotarłeś, a nie że cokolwiek jest nadmiarowe.

Dlaczego ten sam adres na każdym węźle działa

Każdy węzeł posiada adres lokalnie i odpowiada za niego, więc klient, który dociera do niego przez swój bieżący tunel, otrzymuje usługę na drugim końcu tego tunelu. Nic nie jest koordynowane między węzłami i żaden ruch nie przechodzi z jednego węzła do drugiego.

Adres jest lokalną etykietą, powtórzoną, a nie replikowaną. Każdy węzeł odpowiada tylko za siebie i żaden z nich nie przekazuje ruchu dla adresu w imieniu innego węzła. To utrzymuje jedną konfigurację klienta w mocy, podczas gdy serwery pozostają niezależne. To także powód, dla którego projekt nie potrzebuje żadnej koordynacji między węzłami.

Dlatego ta sama konfiguracja działa na każdym serwerze bez protokołu routingu między nimi. To także powód, dla którego projekt nic nie mówi o kondycji: adres istnieje na chorym węźle dokładnie tak jak na zdrowym, bo jest związany z hostem, a nie z tym, czy usługa jest użyteczna.

Przypisz go do loopback, a nie do tunelu

Umieszczenie adresu na interfejsie loopback odłącza go od czasu życia dowolnego urządzenia tunelowego, więc ponowne połączenie lub przeładowanie konfiguracji go nie usuwa. Adres istnieje tak długo, jak istnieje host.

Adres na lo nie jest filtrem. Usługa nadal musi na nim nasłuchiwać, a zapora hosta nadal ocenia rzeczywistą ścieżkę przychodzącą, która przychodzi przez interfejs tunelu. Kto zakłada, że loopback oznacza tylko lokalnie, kończy albo blokując legalnych klientów, albo wystawiając coś, czego nie zamierzał.

Uczyń przypisanie trwałym przez konfigurację sieci hosta, zamiast dodawać je ponownie z hooka. Hook instalacyjny nie uruchomi się na węźle, na którym nie podniósł się żaden tunel, a adres usługi nie powinien zależeć od aktywności tunelu. Umieść adres w konfiguracji interfejsu zarządzanej przez twoją dystrybucję, a następnie uruchom ponownie raz i sprawdź. Restart jest jedynym testem, który przetrwa późniejszą zmianę konfiguracji.

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

Wypchnij jedną trasę i miej na myśli jeden cel

Klient potrzebuje trasy hosta do adresu, oferowanej przez serwer, z którym się łączy. Ponieważ każdy serwer oferuje ten sam cel, profil nie zmienia się, gdy klient się przemieszcza.

Sprawdź, co zainstalował klient, zanim obwiniasz usługę.

ip route get 10.250.0.1

Dla usługi HTTP nadaj adresowi nazwę i certyfikat dla tej nazwy. Wspólny adres IP nie jest tożsamością i nie usuwa weryfikacji TLS, ani nie usprawiedliwia kopiowania jednego klucza prywatnego na każdy węzeł. Nazwa, która rozwiązuje się na wspólny adres, utrzymuje historię certyfikatu zwyczajną i pozwala zachować tożsamość na węzeł, jeśli jej potrzebujesz.

Czego wspólny adres nie potrafi

Nie zapewnia przełączenia awaryjnego. Jeśli wybrany węzeł umrze, adres umiera razem z nim, a klient musi połączyć się ponownie gdzie indziej.

Nie migruje żywej sesji TCP, ponieważ nowe połączenie kończy się na innym hoście, który nic nie wie o starym.

Nie wybiera zdrowego węzła, nie równoważy obciążenia i nie synchronizuje danych między węzłami. Każde z nich to osobny mechanizm z własnymi trybami awarii, a udawanie, że sztuczka z adresowaniem je pokrywa, jest sposobem, w jaki prosty projekt zyskuje niezasłużoną reputację odporności. Jeśli dwa tunele są aktywne naraz, znaczenie celu staje się niejednoznaczne, więc utrzymuj założenie o jednym aktywnym tunelu wprost.

Zachowaj tożsamość usługi przy nazwie

Zapisz, co oznacza adres: dociera do usługi na węźle, z którym klient jest aktualnie połączony. To jedno zdanie zapobiega większości nieporozumień, które przyciąga ten wzorzec.

Następnie udokumentuj części razem: adres, interfejs, na którym żyje, trasę wypychaną przez serwer oraz nazwę i certyfikat prezentowane przez usługę. Cztery małe fakty, które przyszły czytelnik może zweryfikować, w kolejności, w jakiej je sprawdzi.

Jeśli wymaganiem jest stabilny cel dla usługi lokalnej na węźle, wzorzec pasuje i prawie nic nie kosztuje.

Jeśli wymaganiem jest dostępność, przejdź warstwę wyżej: równoważnik obciążenia, nazwa usługi z kontrolami kondycji albo system orkiestracji, który już wie, jak wymienić węzeł.

Wczesne rozstrzygnięcie tego zachowuje wspólny adres tym, czym jest, wygodną etykietą, a nie komponentem, od którego po cichu oczekuje się pracy, do której nigdy go nie zaprojektowano.