OpenVPN remote-random: przetasowana kolejność, jeden tunel

Założenie jest takie, że dodanie remote-random zamienia profil w rotującą pulę, więc każde połączenie wychodzi z innego adresu. W rzeczywistości dyrektywa robi coś innego: raz tasuje listę remote'ów, gdy klient zaczyna się łączyć, a potem próbuje ich w tej nowej kolejności. Tunel, który ostatecznie powstaje, nadal kończy się na jednym punkcie końcowym i pozostaje tam przez cały czas życia sesji.

Ta różnica ma znaczenie zarówno dla testów, jak i dla twierdzeń o prywatności.

Co opcja zmienia w momencie połączenia

Profil klienta może zawierać kilka wierszy remote, każdy z własną nazwą hosta i portem. Bez dyrektywy są próbowane w kolejności pliku; z nią lista jest raz permutowana na początku sesji i wygrywa pierwszy adres, który odpowie. Reszta pozostaje opcją zapasową dla tej próby, a nie równoległymi ścieżkami. Profil z jednym remote daje dyrektywie nic do tasowania, a to najszybszy sposób, by sprawdzić, czy może to mieć znaczenie.

Podręcznik OpenVPN dokumentuje opcję jako wpływającą na kolejność prób połączenia i dokładnie takiego zakresu należy się spodziewać w zachowaniu.

Ponowne połączenie rozpoczyna nowy cykl wyboru, więc późniejsza sesja może wylądować gdzie indziej. Aktywny tunel nie przemieszcza się, dopóki stoi.

Mit: każde żądanie dostaje nowy serwer

Po nawiązaniu tunel przenosi cały ruch tej sesji do wybranego peera. Nie ma ponownego wyboru na każde żądanie, a dyrektywa nie jest balanserem obciążenia dla pojedynczych połączeń: tasuje kandydatów, nie rozdziela pakietów. Każda aplikacja współdzieląca ten tunel współdzieli tego samego peera. Cokolwiek przeglądarka zgłasza na temat swojego wyjścia, należy do sesji, a nie do pojedynczego żądania.

Jeśli test pokazuje dwa różne wyjścia, szukaj dwóch osobnych sesji, a nie jednej sprytnej opcji. Ta różnica wyjaśnia też, dlaczego test przeglądarki i test pobierania mogą się różnić, gdy między nimi doszło do ponownego połączenia.

Do czego służy remote-random-hostname

Druga dyrektywa o podobnej nazwie zmienia nazwę hosta używaną do rozwiązywania, a nie kolejność listy remote. Istnieje dla wdrożeń, w których nazwa jest rozwiązywana na kilka adresów przez round-robin DNS, i powinna być używana tylko wtedy, gdy usługa jest do tego zbudowana. Zmienia się tylko krok rozwiązywania; kolejność listy kandydatów nie.

Włączanie jej, bo nazwy wyglądają na powiązane, to częsty błąd. Certyfikat wieloznaczny lub układ DNS, który nie oczekuje zmienionej nazwy, po prostu nie rozwiąże lub nie zweryfikuje.

Odczytaj wybrany punkt końcowy z logu

Zapisz, jakiego peera sesja rzeczywiście użyła, zanim wyciągniesz wnioski. Szczegółowe wyjście podaje próbowany adres, a sam profil pokazuje, ilu jest kandydatów. Porównaj tę liczbę z adresem w logu, zanim obwinisz tasowanie.

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

Do porównania wydajności przypnij punkt końcowy, komentując pozostałe remote'y, aby testowaną zmienną był protokół lub klient, a nie ścieżka. W kwestii prywatności oceń tożsamość usługi i jej logowanie jako całość; przetasowany pierwszy wybór nie usuwa plików cookie, nie usuwa logowania do konta i nie czyni dwóch operatorów równoważnymi.

Trzymaj razem dostarczony materiał zaufania i obsługiwany zbiór punktów końcowych. Ponowne tasowanie zmienia tylko kolejność, w jakiej ten zbiór jest próbowany.