Wiele OpenVPN remote: lista failover, nie łączenie łączy

Dwie linie remote w jednym profilu wyglądają jak drugi pas; to druga próba. Gdy pierwszy endpoint przestaje odpowiadać, klient idzie dalej, a sesja nie staje się szersza. Nazwij listę failover wcześnie, inaczej będziesz kręcić niewłaściwym pokrętłem.

Co daje lista remote

Traktuj profil jako uporządkowany zbiór prób, a nie jako pulę pojemności. Każdy wpis dostaje swoją kolej na podniesienie tunelu, a sesja żyje na tym, który odpowiedział. Dłuższa lista poprawia szanse połączenia, a nie rozmiar rury.

Prawdziwa agregacja to inna maszyna. Podział jednego strumienia na kilka ścieżek wymaga oprogramowania po obu stronach, które rozdzieli i złoży ruch z powrotem w kolejności.

Dostawca obiecujący szybsze tunele z większej liczby serwerów sprzedaje właśnie ten drugi model, a nie dłuższą listę. Jeśli klient tylko po kolei próbuje endpointów, pięć wpisów zmienia twoje szanse i nic więcej. Obserwuj awarię: sesja spada i wraca gdzie indziej, co log pokazuje jako nowy endpoint, nigdy jako szerszą rurę.

Bloki, które trzymają ustawienia przy jednym endpoincie

Zwykła linia remote niesie adres, a czasem port i protokół. Gdy endpoint potrzebuje proxy albo transportu, którego reszta pliku nie używa, umieść te ustawienia w bloku połączenia, który trzyma je razem z nim. Bloki wbudowane działają też w jednym pliku .ovpn, i tak dostarczana jest większość profili.

Wszystko poza blokiem działa jako wartość domyślna dla wpisów, które go nie nadpisują. Dlatego jeden zbudowany blok i cztery zwykłe remote zachowują się w sposób, którego lista adresów nie potrafi wyjaśnić.

Usunięcie bloku, którego nie rozpoznajesz, nie jest kosmetyką. Endpoint, do którego należał, wraca do domyślnych wartości pliku, które mogą być innym transportem niż ten, na którym nasłuchuje. Usuń złe opakowanie, a jeden wpis zawiedzie, podczas gdy reszta działa, więc wygląda to na zły serwer, a nie zepsuty profil. Przeczytaj każdy remote wraz z jego transportem, portem i proxy przed edycją.

Kolejność ponownych prób i koszt remote-random

Kolejność ma znaczenie, bo każdy martwy wpis kosztuje czas przed następną próbą. Umieść żądany endpoint pierwszy, a resztę traktuj jako uszeregowane rezerwy.

remote-random tasuje początkową kolejność, co rozkłada obciążenie na równoważne serwery i mści się, gdy jeden endpoint jest wyraźnie główny. Tak czy inaczej, zapisz endpoint, który wybrał klient; nazwa profilu nic nie mówi, gdy połączenie wydaje się wolne. Grepowanie linii połączenia w szczegółowym logu pokazuje, gdzie wylądowała sesja.

Mieszanie operatorów łamie deklarację zaufania

Profil to także twierdzenie o tożsamości: te adresy to usługa, do której chciałeś dotrzeć, a przypięty certyfikat należy do niej. Wrzucenie darmowych publicznych serwerów do tego pliku łamie twierdzenie: ich certyfikaty i twój opisują różne usługi. Zwykły wynik to błąd tożsamości albo dane logowania oferowane hostowi poza siecią twojego dostawcy. Trzymaj alternatywy w zestawie dystrybuowanym przez operatora, z pasującymi danymi logowania i materiałem zaufania.

Jeśli potrzebujesz endpointów od dwóch dostawców, to routing, a nie edycja profilu. Rozwiąż to nad tunelem, gdzie możesz powiedzieć, który ruch idzie którą ścieżką.

Testuj każdy wpis zamiast zakładać

Po zatwierdzonej aktualizacji profilu połącz się celowo z każdym wymaganym endpointem i potwierdź, który transport wstał. Szczegółowe uruchomienie to pokazuje. Uruchom openvpn --config office.ovpn --verb 4 i przeczytaj linię połączenia dla oczekiwanego adresu. Potem sprawdź zasoby za tunelem; wpis może dokończyć uścisk dłoni i nadal nigdzie cię nie kierować.

Failover potrzebuje własnego testu, a nie nadziei. Zablokuj pierwszy endpoint w laboratorium, uruchom klienta i zmierz, ile zajmuje przejście dalej. Długa lista za wolnym pierwszym wpisem jest gorsza niż krótka, która dobrze startuje.

Sprawdzaj listę ponownie za każdym razem, gdy operator ją zmieni. Zaimportowany zestaw jest użyteczny tylko dopóki jego wpisy istnieją i mówią transportem, który opisują twoje bloki. Podręcznik OpenVPN 2.6 omawia tu dyrektywy remote, connection i random-order, i to jest wersja, którą warto sprawdzić, gdy składnia budzi wątpliwości.