OpenVPN przez proxy HTTP: najpierw przeczytaj odpowiedź CONNECT
Proxy CONNECT przekazuje bajty, więc oba końce potrzebują TCP. Przeczytaj 407, 403 i 503, zanim obwinisz certyfikaty, i pozostaw weryfikację serwera włączoną.
Skieruj klienta VPN na firmowe proxy HTTP, a pierwszy użyteczny fakt jest taki, że proxy nie mówi protokołem VPN. Otwiera zwykłe połączenie TCP na wskazany adres, a potem odsuwa się, pozwalając klientowi i serwerowi przeprowadzić własną wymianę przez ten strumień. Wszystko, czego potrzebuje klient, od typu transportu po odbiornik serwera, musi pasować do tego układu. Dwie niezgodności wyjaśniają większość niepowodzeń: profil UDP skierowany na proxy CONNECT oraz odpowiedź proxy wzięta za błąd VPN.
Co proxy przenosi, a czego nie
Proxy to tylko etap transportu. Nie staje się proxy przeglądarki, nie buforuje stron odwiedzanych przez tunel i nie widzi ruchu wewnętrznego, chyba że ktoś świadomie skonfigurował inspekcję. Tunel, który otwiera, jest dla niego z założenia nieprzezroczysty.
To oznacza też, że proxy nie naprawi serwera bez pasującego odbiornika. Zgoda na dotarcie do celu i usługa nasłuchująca w tym celu to dwa osobne fakty, a tylko pierwszy należy do administratora proxy.
Nośnik musi być TCP po obu stronach
Konwencjonalne proxy CONNECT przekazuje tylko strumień bajtów , więc klient musi używać transportu strumieniowego. Fragment klienta dla tego przypadku wygląda tak:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Strona serwera potrzebuje prawdziwego odbiornika TCP na porcie wymienionym w wierszu remote. Zmiana proto udp na proto tcp-client w profilu tworzy klienta, który oczekuje strumienia; nie tworzy strumienia po drugiej stronie. Jeśli ten sam serwer odpowiada też przez UDP na tym porcie, to inny odbiornik, a nie drugi tryb tego samego.
Gdzie istnieje osobna instancja TCP, jej urządzenie tunelowe, pula adresów i routing są osobnymi zasobami. Skopiowanie działającej konfiguracji i zmiana słowa transportu pozostawia te zasoby wskazujące na pierwotną instancję, co daje połączenie, które się uwierzytelnia, a potem niczego nie routuje.
Przeczytaj odpowiedź proxy przed wynikiem VPN
Pierwsza wymiana klienta to wiersz żądania nazywający host i port docelowy. Odpowiedź na ten wiersz mówi, czy strumień bajtów w ogóle istnieje, i przychodzi, zanim sprawdzony zostanie jakikolwiek certyfikat lub dane logowania:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
Odpowiedź klasy 200 na CONNECT oznacza, że strumień istnieje. Nie mówi nic o tym, czy certyfikat bramy jest zaufany, czy klucz współdzielony się zgadza albo czy konto użytkownika jest ważne. Te kontrole odbywają się później, wewnątrz strumienia, i kończą się niepowodzeniem z komunikatami samego klienta, a nie wierszem stanu HTTP. W logu klienta szukaj pierwszego OpenVPN zdarzenia po uzgodnieniu z proxy, a nie ostatniego wiersza przed zamknięciem okna.
Dane logowania do proxy i do VPN to często różne tożsamości w rękach różnych zespołów. 407 nie jest złym hasłem konta VPN, a odrzucony certyfikat nie jest problemem uprawnień proxy.
Czego CONNECT nie ujawnia
Jawny tunel CONNECT nie jest przechwytywaniem. Proxy przekazuje bajty i nie kończy sesji TLS VPN, więc weryfikacja certyfikatu serwera przez klienta pozostaje sensowna i powinna być włączona. Wyłączanie weryfikacji, aby przejść przez proxy, rozwiązuje inny problem niż twój.
Istnieją osobne rozwiązania, w których organizacja świadomie kończy i sprawdza TLS. Wymagają one własnej konfiguracji zaufania i własnej decyzji politycznej, i nie są tym, o co prosi zwykły wiersz http-proxy.
Koszt TCP w TCP
Przenoszenie tunelu przez TCP utrzymuje zewnętrzny strumień uporządkowany i z retransmisją, a ruch wewnętrzny zwykle też jest TCP. Oba mechanizmy odzyskiwania nie koordynują się, więc pojedynczy utracony segment może zatrzymać wszystko, co dzieli ten zewnętrzny strumień, dopóki nie zostanie przesłany ponownie. To prawdziwa wymiana za zgodność, a nie darmowa aktualizacja.
Używaj ścieżki przez proxy, gdy sieć nie pozostawia alternatywy, i preferuj bezpośrednią ścieżkę UDP tam, gdzie polityka na to pozwala. W każdym razie po zmianie potwierdź, że ten sam proxy, cel i profil docierają do następnego etapu; przeglądarka ładująca stronę pod tym adresem używa innego protokołu i niczego nie dowodzi o tunelu.