OpenVPN i HTTPS na porcie 443: do kogo należy nasłuch?

Dwie usługi mogą obie odpowiadać na porcie 443, nigdy nie konkurując, ponieważ nasłuch jest określany przez transport, adres i port razem, a nie przez sam numer. Postaw serwer WWW i OpenVPN na jednej maszynie, a jedynym pytaniem, na które warto odpowiedzieć najpierw, jest to, którego gniazda żąda każdy proces od jądra. Zapisz tę listę, zanim zaczniesz edytować konfigurację, a większość błędów „adres jest już w użyciu” wyjaśni się sama. Wszystko po liście to wybór między nasłuchem UDP, współdzielonym gniazdem TCP a frontem, który kieruje według protokołu.

Zacznij od gniazda, którego żąda każdy proces

Bind udaje się lub nie według tej trójki, więc dwa demony zderzają się tylko wtedy, gdy wszystkie trzy części się pokrywają. Dlatego witryna na TCP 443 bez ograniczeń współistnieje z nasłuchem OpenVPN na UDP 443, i dlatego przeniesienie jednego z nich na drugi lokalny adres na tym samym hoście również kończy spór. Czytaj żywe nasłuchy, a nie pliki, które miały je utworzyć, bo przestarzały include albo zapomniany plik unit przeżywa edycję, którą pamiętasz.

Uruchom ss -lntup jako root i przeczytaj każdy wiersz, który wspomina 443, łącznie z wpisami IPv6. Nasłuch wieloznaczny dla v6 zwykle przyjmuje też ruch v4, i tak zapomniany nasłuch trzyma port zajęty po zmianie pliku, który uważałeś za odpowiedzialny. Jeśli nazwa procesu cię zaskoczy, zawęź wyjście za pomocą ss -lntup 'sport = :443', zanim czegokolwiek dotkniesz.

Przełącz tunel na UDP, gdy sieć na to pozwala

Nasłuch UDP całkowicie omija kolizję i jest zwykle najkrótszą naprawą, bo żadne gniazdo nie jest współdzielone i żaden dodatkowy produkt nie wchodzi na ścieżkę. Nie jest to jednak darmowe. Niektóre sieci klientów odrzucają UDP 443 bez wysłania resetu, więc tunel przestaje się nawiązywać zamiast zawodzić na bind, a użytkownik zgłasza, że VPN nie działa, bez żadnego błędu do przeczytania. Nasłuch UDP przeżywa też restart warstwy WWW, co liczy się na maszynie, której witryna jest często wdrażana ponownie. Testuj z sieci, w której siedzą użytkownicy, bo powłoka na serwerze dowodzi tylko, że serwer dosięga sam siebie.

Zmień transport w konfiguracji serwera i w profilu klienta jednocześnie. Profil, który nadal żąda TCP, będzie krążył w pętlach ponownych połączeń wobec nasłuchu tylko UDP, i wygląda to jak awaria sieci, dopóki nie porównasz obu plików.

Pozwól procesowi VPN posiadać TCP 443 i przekaż resztę

Community OpenVPN w trybie serwera TCP czyta pierwsze bajty połączenia przychodzącego i przekazuje wszystko, co nie jest jego protokołem, do backendu HTTPS, i temu służy dyrektywa port-share. Backend to zwykły serwer WWW z włączonym TLS, nazwany hostem i portem w tej dyrektywie, a nie adresem URL.

port-share 10.0.0.5 8080

Na maszynie, gdzie witryna ma drugi prywatny adres, ten wiersz wysyła ruch nie-VPN do 10.0.0.5:8080, więc wirtualny host HTTPS musi być tam przypisany, a zapora musi zezwalać na lokalny skok. Serwer WWW musi sam zakończyć TLS, bo przychodzące bajty to pierwotny uścisk dłoni przeglądarki i nic pomiędzy ich nie odszyfrowało. Skieruj dyrektywę do zwykłego nasłuchu HTTP, a przeglądarka dostanie błąd nieprawidłowej metody, który czyta się jak zepsuta witryna, a nie jak źle umieszczony backend. Dyrektywa istnieje tylko w trybie serwera TCP, a nasłuch UDP nie ma strumienia do zbadania.

Ponieważ proces VPN przyjmuje każde połączenie, aplikacja WWW widzi przekazane żądanie przychodzące z jednego z własnych adresów hosta, a nie od odwiedzającego. Wszystko, co potrzebuje prawdziwego adresu klienta, zależy od obsługi protokołu PROXY w backendzie albo od frontu, który go dodaje. Przeniesienie backendu na inny lokalny adres nie przywraca adresu odwiedzającego; zmienia tylko, który z adresów hosta witryna zapisuje. Zapisz to ograniczenie w notatkach wdrożeniowych, zanim raport analityczny postawi pytanie.

Odwrotne proxy to niewłaściwe narzędzie; router czwartej warstwy nie

Odwrotne proxy HTTP kończy TLS, aby móc czytać żądania, co oznacza, że nie może przepuścić strumienia OpenVPN nietkniętego. Router czwartej warstwy, który przekazuje według SNI lub według inspekcji pierwszego pakietu, może stać przed oboma, pod warunkiem że nie kończy sesji, od której zależy VPN. Oba urządzenia wyglądają podobnie na schemacie i zachowują się zupełnie inaczej przy gnieździe.

Komercyjny Access Server ma własne ustawienia współdzielenia portu i nie odpowiadają one jeden do jednego dyrektywie społeczności. Zidentyfikuj produkt i wersję, zanim dostosujesz przewodnik napisany dla drugiego. Skopiowane ustawienie, które jest po cichu ignorowane, jest gorsze niż brak ustawienia, bo lista nasłuchów po nim wciąż wygląda wiarygodnie.

Przetestuj witrynę i tunel jako dwie osobne ścieżki

Wczytaj witrynę i połącz tunel, a potem przeczytaj listę nasłuchów ponownie, aby zobaczyć, który proces ma teraz 443. Strona, która się wczytuje, nie dowodzi niczego o VPN, a tunel, który się łączy, nie dowodzi niczego o witrynie, choć oba używają tego samego numeru. Trzy poniższe polecenia sprawdzają współdzielone gniazdo, ścieżkę WWW i usługę VPN w tej kolejności.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Porównaj adres klienta w logu dostępu backendu z tym w logu VPN w tej samej chwili. Jeśli witryna zapisuje każdego odwiedzającego jako samego hosta, przekazywanie działa, a obsługa adresu nie. Jeśli oba logi milczą, front nigdy nie przekazał połączenia. Tak czy inaczej, lista nasłuchów rozstrzyga, kto przyjmuje gniazdo, i to jest fakt do potwierdzenia, zanim zmienisz kolejny plik.

Zostaw tę mapę nasłuchów obok konfiguracji, aby następna osoba, która dotknie 443, wiedziała, który proces przyjmuje i dokąd poszedł drugi protokół. Potwierdź własność po zmianie, zamiast ufać temu, co edycja miała zrobić.