Udostępnianie OpenVPN przez TCP i UDP z jednego hosta
Jeden proces wiąże jeden transport przed 2.7. Porównaj mostkowaną parę TAP, dwie podsieci TUN i wspólną pulę, a następnie dopasuj każdy profil do jego listenera.
Sieci, które dopuszczają tylko TCP 443, współistnieją z sieciami, które bez problemu przepuszczają UDP, a jeden serwer musi obsłużyć oba. Profil z proto udp odpowiada drugiej grupie i zawodzi w pierwszej, a edycja tej samej konfiguracji, by mówiła proto tcp, nie tworzy drugiego listenera. Dyrektywa wybiera jeden transport dla jednego procesu. Wszystko inne wynika z tego ograniczenia.
Albo uruchamiasz więcej niż jeden proces, albo uruchamiasz wersję, która potrafi związać kilka gniazd naraz.
Jeden proces wiąże jeden transport przed 2.7
Społecznościowy OpenVPN wiąże gniazdo opisane przez proto, a ta dyrektywa wybiera jeden transport dla instancji. TCP i UDP to osobne stosy, więc ten sam numer portu mogą zajmować oba jednocześnie, ale nie jeden proces. Linia 2.6 daje więc jeden transport na demon. OpenVPN 2.7 usunął to ograniczenie dla serwerów, które mogą wiązać kilka gniazd przez kilka instrukcji --local w jednym procesie.
Sprawdź wersję, zanim zaprojektujesz rozwiązanie wokół którejkolwiek odpowiedzi, ponieważ układ 2.7 to inny model operacyjny z własną składnią konfiguracji. Przewodnik napisany dla 2.6 opisuje dwa procesy, nawet gdy tego nie mówi.
Trzy sposoby uruchomienia dwóch instancji
Z interfejsami TAP uruchom jedną instancję na transport i połącz dwa urządzenia tap mostkiem na hoście. Oba zbiory klientów trafiają do tej samej domeny rozgłoszeniowej, co pozwala jednej puli adresów je objąć i utrzymuje działanie protokołów zależnych od rozgłoszenia. Z TUN mostkowanie nie jest dostępne, więc najprostszy podział daje każdej instancji własną podsieć, a routing trzyma oba zbiory klientów osobno. Trzecia opcja zachowuje jedną pulę, każąc każdej instancji wywołać skrypt learn-address, który instaluje trasę /32 dla klienta przez urządzenie tej instancji.
Ten trzeci układ jest tym, o który ludzie proszą, i tym, który wymaga największej staranności, ponieważ skrypt staje się częścią ścieżki danych i musi poprawnie obsługiwać zdarzenia dodania, aktualizacji i usunięcia.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Trzymaj obie instancje osobno
Każda instancja potrzebuje też osobnego portu lub adresu, osobnego pliku stanu i osobnego celu logów. Dwa demony dopisujące do jednego pliku stanu tworzą wyjście, którego nie da się odczytać podczas incydentu, a właśnie wtedy jest potrzebne. Jeśli druga instancja wiąże konkretny adres, adres ten musi istnieć na hoście w chwili startu procesu; w przeciwnym razie kończy się błędem wiązania, zanim powie cokolwiek o kluczach.
Nazwij jednostki i profile tak, by transport był oczywisty z nazwy pliku. Następny operator nie powinien musieć otwierać konfiguracji, by dowiedzieć się, który jest TCP.
Dopasuj profil do listenera
Serwer uruchamiający proto tcp oczekuje profilu klienta z proto tcp-client, a profil wciąż zawierający proto udp wobec tego listenera kończy się przekroczeniem czasu bez błędu, na który użytkownik może zareagować. Zachowaj dwa profile, jeśli wdrożenie oferuje oba transporty, i oznacz je tak, by wsparcie wiedziało, który wypróbowano. Sam numer portu nie opisuje transportu.
Reguły zapory podążają za tym samym podziałem: reguła dla UDP 1194 nie mówi nic o TCP 1194, a reguła dla jednego adresu nie obejmuje drugiego listenera.
Najpierw przeczytaj obraz serwera
Zacznij od ss -lntup na serwerze i potwierdź, że pojawia się zarówno listener TCP, jak i UDP. Następnie podłącz po jednym kliencie każdego rodzaju i sprawdź wyjście statusu pod kątem dwóch wpisów z różnymi adresami. Jeśli gniazda istnieją, a klient nie przychodzi, ścieżka lub zapora odrzucają pakiety, zanim demon je zobaczy.
Gniazdo, które nigdy się nie pojawia, to problem konfiguracji lub wiązania, a gniazdo, które się pojawia, ale nigdy nie rejestruje połączenia, to problem filtrowania. Z perspektywy klienta oba wyglądają identycznie, dlatego obraz samego serwera jest pierwszy. Pamiętaj, że TCP niesie blokowanie na początku kolejki, więc oferowanie go jest środkiem osiągalności, a nie ulepszeniem dla klientów z czystą ścieżką UDP.