Czy każdy peer OpenVPN potrzebuje linii remote? Niezupełnie

Dwie konfiguracje peera są porównywane obok siebie, jedna ma linię remote, a druga nie, i wniosek jest taki, że jedna z nich jest zepsuta. Ten wniosek jest wystarczająco często błędny, by warto go rozłożyć. Dyrektywa opisuje, dokąd należy wysłać pierwszy pakiet. Nie wybiera, czy proces działa jako klient inicjujący, czy jako brama oczekująca, i nie decyduje, która strona dowodzi swojej tożsamości przed drugą.

Co remote faktycznie określa

Wpis remote nazywa host, opcjonalnie port i transport, a opcjonalnie kilka takich wpisów próbowanych po kolei.

Jego brak ma znaczenie określone, a nie nieokreślone: proces czeka i nie działa na pakiety z adresu, chyba że ten peer się uwierzytelni. Brama obsługująca użytkowników mobilnych nie ma więc powodu wymieniać któregoś z nich z góry.

Czytaj wpis jako relację adresów. To, czy drugi koniec jest zaufany, rozstrzygają certyfikaty i opcje weryfikacji, a nie fakt zapisania adresu.

Trzy układy decydują o odpowiedzi

Klient mobilny potrzebuje celu, bo musi inicjować i bez niego nie wie, gdzie jest brama. Brama dla wielu klientów nie potrzebuje celu na użytkownika, bo klienci przychodzą i uwierzytelniają się. Zamierzone połączenie dwóch peerów ze znanymi końcami może mieć cel po jednej stronie, po obu albo po żadnej, w zależności od tego, która strona inicjuje.

Wklejenie stałego adresu klienta do ogólnej bramy to błąd wynikający z ignorowania tych kategorii. Działa dla jedynego peera, którego adres zapisano, i wprowadza w błąd wszystkich pozostałych.

Nic w dyrektywie nie zamienia konfiguracji w serwer dla wielu klientów i nic w jej obecności nie blokuje roli serwera. Dokumentacja OpenVPN 2.6 opisuje osobno argumenty opcjonalne i zachowanie bez remote, co jest wskazówką, jak niezależne są te rzeczy.

Role transportu to inna oś

W TCP jedna strona czeka, a druga wybiera numer. To osobne dyrektywy od celu, a ich zmieszanie daje parę, w której obie czekają albo obie wybierają numer.

Istnieje też rola filtra źródła TCP, dlatego płaskie stwierdzenie, że serwer nigdy nie może zawierać remote, jest błędne.

W UDP nie ma połączenia do nawiązania, więc oba końce używają odpowiedniego transportu UDP, a dyrektywa mówi tylko, gdzie celować. Zmiany adresu przez uwierzytelnionego peera obsługuje dedykowane zachowanie, a nie dodawanie kolejnych wpisów. Właściwy transport jest warunkiem, by cel cokolwiek znaczył, a pomieszanie obu daje konfiguracje, które wyglądają wiarygodnie i nigdy nie kończą uzgadniania.

Dlaczego brak remote nie jest otwartymi drzwiami

Proces bez celu nadal odrzuca ruch od peerów, które się nie uwierzytelniają, i to jest ta część, którą ludzie przeoczają, czytając brakującą linię jako nasłuch otwarty dla wszystkich.

Uwierzytelnianie i cel są niezależne, a to pierwsze ma znaczenie dla zaufania.

Odwrócony błąd jest groźniejszy. Stały adres źródłowy może sprawiać wrażenie kontroli dostępu, bo jest konkretny i łatwy do sprawdzenia, ale nie dowodzi niczego o tym, kto jest po drugiej stronie. Zachowaj weryfikację certyfikatów i kontrole tożsamości, które wiążą certyfikat z jego rolą. Zastąpienie ich dopasowaniem adresu zamienia realną kontrolę na jej pozór.

Zapisz, co zakłada konfiguracja

Dla każdej strony zapisz trzy rzeczy: jak pierwszy pakiet dociera do peera, która strona może przyjąć transport i co każda strona weryfikuje u drugiej.

Te założenia to projekt. Dyrektywy są tylko ich pisownią.

Jeśli oba pliki się różnią, sprawdź, czy wyrażają różne założenia, zamiast zakładać, że jeden jest błędny. Symetryczna para plików nie jest ani konieczna, ani wystarczająca dla działającego tunelu, a asymetria jest często tą częścią, która sprawia, że topologia działa.