Dlaczego proxy Cloudflare nie może przenosić OpenVPN pod jedną nazwą

Jedna maszyna uruchamia witrynę i serwer OpenVPN, a pokusa polega na wskazaniu na nią jednej nazwy hosta i pozwoleniu pomarańczowej chmurze uporządkować ruch. Proxy porządkuje HTTP i HTTPS. Nie porządkuje sesji OpenVPN, niezależnie od tego, którego portu ta sesja używa. Dwie nazwy, jedna bezpośrednia i jedna przez proxy, nic nie kosztują i usuwają całą tę klasę zamieszania.

Dwie nazwy, dwa transporty

Daj witrynie rekord z proxy, aby jej ruch HTTP i HTTPS przechodził przez Cloudflare. Daj VPN rekord tylko DNS, który rozwiązuje się prosto na publiczne wejście VPN, i pozwól klientowi używać portu UDP lub TCP, dla którego jest skonfigurowany.

Obie nazwy mogą trafić na tę samą maszynę źródłową. Różnica polega na tym, co dzieje się między klientem a tą maszyną, i ta różnica jest sensem podziału.

Dokumentacja portów sieciowych Cloudflare wymienia porty akceptowane przez zwykłe proxy internetowe. Ta lista dotyczy HTTP i HTTPS na tych portach, a nie dowolnych protokołów, które przypadkiem dzielą jeden numer.

Port to nie protokół

Przeniesienie OpenVPN na TCP 443 nie czyni go HTTPS. Proxy nadal oczekuje żądania HTTP na początku połączenia, a klient OpenVPN wysyła zamiast tego binarny komunikat sterujący. Połączenie kończy się niepowodzeniem w sposób wyglądający jak blokada sieci, ponieważ nic użytecznego nie trafia do dziennika.

Jeśli wymaganiem naprawdę jest umieszczenie produktu Cloudflare na ścieżce danych VPN, oceń taki, który dokumentuje obsługę potrzebnego protokołu. Nie zakładaj, że pomarańczowa chmura to ogólny tunel TCP lub UDP, bo jest odwrotnym proxy dla ruchu internetowego z konkretnym zadaniem.

Rekord tylko DNS to nudna odpowiedź, która działa, i to po nią należy sięgnąć najpierw.

Jedna maszyna nadal potrzebuje dwóch nasłuchów

Oddzielne nazwy nie pozwalają dwóm procesom związać tego samego adresu, portu i transportu w tym samym czasie. Jeśli serwer WWW już trzyma TCP 443 na wszystkich adresach, instancja OpenVPN nie może go także zająć bez świadomego ustalenia.

Zwiąż nasłuch VPN z innym portem, albo innym adresem, albo postaw z przodu udokumentowany multiplekser i zaakceptuj związane z tym koszty operacyjne. Każdy z tych wyborów powinien być widoczny w regułach firewalla, bo nasłuch, którego nikt nie udokumentował, jest tym, który się pomija podczas incydentu. Zapisz wybrane powiązanie w tym samym runbooku, który opisuje tunel. Wtedy następna osoba nie odkryje go ponownie o drugiej w nocy.

Certyfikaty podążają za połączeniem, które chronią

Połączenie TLS przeglądarki z Cloudflare i połączenie Cloudflare z twoim źródłem to dwie osobne relacje z dwoma osobnymi certyfikatami. Przeglądarka widzi certyfikat brzegowy. Źródło przedstawia Cloudflare własny certyfikat, a certyfikat Cloudflare Origin CA jest przeznaczony dokładnie dla tej drugiej relacji.

Ten certyfikat źródła jest zaufany przez Cloudflare w trybie Full (strict) i nie jest powszechnie zaufanym certyfikatem przeglądarki. Jeśli ktoś odwiedzi bezpośrednio nazwę hosta tylko DNS i dostanie ostrzeżenie, jest to oczekiwany skutek zmienionej ścieżki zaufania, a nie dowód, że szyfrowanie się zatrzymało.

Witryna odwiedzana bezpośrednio potrzebuje więc łańcucha certyfikatów, któremu ufają jej przeglądarki. Może to współistnieć z witryną przez proxy, której źródła wcale nie zamierza się odwiedzać.

OpenVPN niesie własną tożsamość serwera i uwierzytelnianie klienta, z własnym urzędem certyfikacji i własną ochroną kanału sterującego. Kłódka na witrynie nie zapewnia niczego z tego, a oba procesy przygotowania powinny pozostać osobne.

Ekspozycja podąża za nazwą

Rekord VPN tylko DNS publikuje adres, na który wskazuje. Jeśli ten adres jest także źródłem internetowym, źródło nie jest ukryte, a opisywanie go jako ukrytego dlatego, że druga nazwa jest za proxy, to błąd, który trwa, dopóki ktoś go nie przeskanuje.

Zdecyduj, które żądania internetowe mogą docierać do źródła bezpośrednio, i egzekwuj to w źródle, a następnie zezwól nasłuchowi VPN na jego własnych warunkach. Strony administracyjne, pobieranie profili i nasłuch danych mogą mieć trzy różne wymagania dotyczące ekspozycji, nawet gdy jeden pakiet zapewnia wszystkie trzy.

Trzymaj generowane linki na publicznej nazwie internetowej i schemacie HTTPS, a profile klientów na nazwie VPN z rzeczywistym protokołem i portem. Żadna z usług nie powinna w normalnej pracy zależeć od przełączania ustawienia proxy drugiej.

Kolejność pracy: nazwa przez proxy dla witryny, nazwa tylko DNS dla VPN, osobne nasłuchy, certyfikat dla każdej relacji, a potem jeden test, który dowodzi, że każda nazwa dociera tylko do usługi, do której powinna.