Kierować klientów OpenVPN przez Cloudflare? Najpierw sprawdź rolę
Klient urządzenia nie jest routerem. Potwierdź, że rola Cloudflare przekazuje pakiety innych hostów, i pozostaw własny tunel serwera na jego starej ścieżce.
Masz działający serwer OpenVPN i host, który uruchamia także oprogramowanie urządzeniowe Cloudflare, a oczywisty następny krok wygląda na kierowanie ruchu klientów do niego. Dwa działające połączenia na jednej maszynie nie tworzą bramy tranzytowej. Brakuje roli udokumentowanej do przekazywania pakietów należących do kogoś innego oraz polityki, która klasyfikuje te pakiety, gdy przybywają.
Przed każdą regułą stoją cztery pytania: jaki ruch wchodzi, dokąd trafia dalej, jak odpowiedzi znajdują drogę powrotną i co robi projekt, gdy ta druga ścieżka zawodzi. Pierwsze dwa to pytania o możliwości.
Dwie usługi na jednym hoście nie są ścieżką tranzytową
Klient urządzenia jest zbudowany do obsługi ruchu, który powstaje na maszynie, na której działa. Przechwytuje rozwiązywanie nazw lub wybrany ruch aplikacji i wysyła go własnym tunelem, a jego polityka jest napisana dla użytkownika tego urządzenia i procesów tego urządzenia. Pakiet przekazany z klienta OpenVPN nie jest lokalnym wyjściem, więc te same reguły go nie klasyfikują. To nie jest szczegół konfiguracji, który można przykryć szerszą regułą, ponieważ decyduje, czy oprogramowanie w ogóle widzi pakiet.
Dlatego pytanie projektowe jest pytaniem o możliwości. Albo zainstalowany produkt ma udokumentowaną rolę, która przekazuje ruch dla innych sieci, albo funkcja tranzytu należy do zupełnie innego miejsca.
Która rola Cloudflare może przekazywać
Klient urządzeniowy Cloudflare oferuje tryby różniące się zakresem: tylko rozwiązywanie nazw, ruch z urządzenia i czasami oba. Żaden z tych trybów nie czyni hosta routerem dla prywatnego zakresu, który przychodzi innym tunelem. Dedykowana rola routingu to osobny produkt z własnym łącznikiem, rejestracją i modelem sieci.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Sprawdź zainstalowaną rolę, zanim zaprojektujesz wokół niej trasy. Przeczytaj, jaki interfejs tworzy łącznik, czy ogłasza konkretne prefiksy lub trasę domyślną i czy lokalna polityka dotyczy także pakietów przekazywanych, a nie tylko lokalnych. Jeśli obsługiwany jest tylko ruch lokalny, serwer OpenVPN nie może być punktem tranzytowym, niezależnie od tego, jak napisano regułę tłumaczenia.
Tutaj również wymóg publicznego wyjścia trzeba sformułować precyzyjnie. Wyjście zapewniane przez Cloudflare dla przekazywanego ruchu klientów to konkretny przypadek użycia i trzeba je potwierdzić wobec usługi, którą naprawdę masz.
Utrzymuj tunel zewnętrzny niezależny od nowej trasy
W chwili dodania trasy domyślnej do nowego interfejsu własny ruch wychodzący serwera zaczyna o nią konkurować, a to obejmuje odpowiedzi do klientów OpenVPN i twoją sesję SSH do maszyny. Typowym objawem jest tunel, który się zestawia, a potem ginie, albo administrator zablokowany na zewnątrz, podczas gdy zmiana wydaje się działać. Porównaj ip route get dla punktu końcowego przed i po, i użyj routingu opartego na polityce lub trasy do hosta, aby utrzymać własny transport serwera tam, gdzie był. Wykonaj to porównanie z samej maszyny, ponieważ liczy się własny widok serwera na jego trasę.
Wyjątek dla publicznego adresu serwera nie wystarcza sam w sobie, ponieważ droga powrotna każdego zdalnego administratora to inny strumień. Zdecyduj, które z tych strumieni muszą przetrwać zmianę, a następnie zweryfikuj każdy, zamiast zakładać, że pierwszy obejmuje resztę.
Ogranicz przekazywanie i tłumaczenie do jednego strumienia
Odebrane pakiety podążają ścieżką przekazywania, a nie ścieżką lokalnego wyjścia, więc decydująca reguła żyje w haku forward. Gdzie następny interfejs wymaga tłumaczenia, ogranicz źródło do puli klientów, cel do tego, co dozwolone, a wyjście do tego jednego interfejsu. Reguła masquerade powiązana tylko z interfejsem sama nie wybiera trasy i nie pozwala na przekazywanie obok żadnego innego filtra.
Zdecyduj z góry o zachowaniu przy awarii, a potem je przetestuj. Zatrzymaj dalszą ścieżkę i potwierdź, że klienci tracą zamierzone wyjście, zamiast po cichu wracać do zwykłego łącza nadrzędnego, ponieważ to wynik, którego nikt nie zauważa, dopóki ruch nie zacznie wychodzić złymi drzwiami. Powtórz kontrolę dla rozwiązywania nazw i dla IPv6, ponieważ zestaw reguł tylko dla v4 pozostawia otwartą ścieżkę v6.
Zapisz cztery odpowiedzi, na których stanąłeś, i obserwację, która każdą z nich potwierdza. Ścieżka tranzytowa, którą potrafisz opisać, to taka, której potrafisz bronić na następnym przeglądzie incydentów.