Ing. Calogero Bono
Cloudflare udostępnił ogólnie wsparcie dla prywatnych originów, uruchomione w zamkniętej becie w czerwcu. Rekord DNS z proxy może teraz wskazywać prywatny adres IP, a ruch dociera do serwera przez już istniejące połączenie Cloudflare One. Dla tych, którzy zarządzają wewnętrznymi API, backendami agentów AI lub narzędziami operacyjnymi, oznacza to stosowanie WAF, cache i bot management bez wystawiania serwera do Internetu. Trzeba jednak sprawdzić, jakie wymagania są naprawdę potrzebne.
Kilka terminów, zanim przejdziemy do faktów. Origin to serwer przechowujący aplikację, ukryty za Cloudflare. WAF to firewall aplikacyjny, który filtruje szkodliwe żądania. Cloudflare One to platforma prywatnej łączności firmy, z tunelami i sieciami. RFC 1918 definiuje prywatne adresy IPv4, takie jak 10.0.0.50. CGNAT oznacza adresy współdzielone z bloku 100.64.0.0/10, używane przez operatorów.
Co dokładnie wydało Cloudflare?
Według oficjalnego bloga Cloudflare, podczas zamkniętej bety dostęp miały kwalifikujące się konta, które prosiły o niego swój account team. Teraz dostęp jest otwarty szerzej niż ta grupa.
Wskazujesz rekord A lub AAAA z proxy na prywatny IP, a narzędzia aplikacyjne działają jak przy publicznych originach.
- WAF i reguły zarządzane
- Bot management
- Rate limiting
- Caching
- Reguły transformacji i przepisywania
- Workers
Jaki problem rozwiązuje?
Cloudflare mówi, że często słyszał ten sam problem. Wewnętrzne API, backendy agentów AI, serwery MCP i narzędzia operacyjne nie są stworzone, by stać w Internecie, a muszą przyjmować żądania od partnerów, klientów lub agentów.
Wcześniej postawienie Cloudflare przed takimi usługami wymagało publicznego IP, otwartego portu na firewallu albo cloudflared obok serwera. Często prywatne aplikacje zostawały bez tych samych zabezpieczeń co publiczne.
Jeśli interesują cię sieci prywatne, zajrzyj do naszego przewodnika o prywatnych podsieciach i security group w AWS.
Jak działa prywatny routing?
Tworzysz rekord z proxy wskazujący na origin. Dla obsługiwanych prywatnych zakresów opcja prywatnego routingu włącza się automatycznie. Jeśli origin ma publiczny IP osiągalny tylko z sieci prywatnej, włączasz ją ręcznie.
Ustawienie jest automatyczne dla adresów RFC 1918, dla bloku CGNAT RFC 6598 i dla lokalnych adresów IPv6 RFC 4193. Dla tych zakresów nie można go wyłączyć, a próba przez API zwraca błąd.
Przez API wystarczy atrybut private_routing w rekordzie DNS. Gdy proxy go zobaczy, przekazuje żądanie na warstwę prywatnej sieci, która korzysta z istniejącej łączności, czyli IPsec, GRE, Cloudflare Tunnel, CNI lub Cloudflare Mesh. Przy Cloudflare WAN nie potrzeba żadnego konektora na originie. Przy Mesh jeden konektor w sieci może obsłużyć kilka originów.
Czego potrzeba, by to włączyć?
Cloudflare wymienia kilka wymagań.
- Uprawnienie Private Origins na koncie, o które prosisz account team.
- Łączność Cloudflare One z IPsec, GRE, CNI, Tunnel lub Mesh.
- Aktywny Unified Routing, z wyjątkiem Tunnel.
- Przy WAN lub Mesh trasa powrotna dla zakresów źródłowych Cloudflare, 100.64.0.0/12 dla IPv4 i 2606:4700 – cf1:5000 – – /64 dla IPv6.
Cloudflare ostrzega, że brakująca trasa powrotna to najczęstszy błąd konfiguracji. Jeśli żądania kończą się timeoutem i do serwera nic nie dociera, sprawdź ją najpierw.
Ograniczenia, które warto znać
Ograniczenia nadal istnieją. Argo Smart Routing i dedykowane adresy IP wyjściowe CDN nie są obsługiwane, a kontrole stanu originu wymagają Load Balancing. Pełna lista jest w dokumentacji dla deweloperów. Nie znamy cen ani niezależnych testów, a aktywacja przechodzi przez account team. Ruch między prywatnymi sieciami jest wciąż w przygotowaniu.
Co się zmienia dla osób pracujących w technologii
Ci, którzy udostępniają API partnerom lub agentom AI, mogą utrzymywać serwer bez publicznego IP i bez otwartych portów, co zmniejsza powierzchnię ataku. Serwer z jasnymi regułami dostępu trzeba jednak skonfigurować z uwagą na poziomie sieci Linux. Reguły WAF, cache i bot management, które już działają, stosują się do nazwy hosta bez dodatkowych kroków. Dla małych firm przeszkodą jest kwestia handlowa, bo potrzebna jest infrastruktura Cloudflare One i kontakt z działem sprzedaży.
Nasze zdanie
Krok jest użyteczny, bo przenosi publiczne zabezpieczenia tam, gdzie wcześniej rezygnowano z nich dla wygody. Ukrytym kosztem jest jednak zależność. Chroniąc prywatną usługę, wiążesz sieć, DNS i filtry z jednym dostawcą, z wymaganiami przechodzącymi przez account team. Dla firm, które już korzystają z Cloudflare One, ma to sens, a pozostałe powinny porównać prostsze rozwiązania, zanim się zobowiążą.
Najczęstsze pytania
Czym są prywatne originy Cloudflare?
To serwery z prywatnym IP, do których Cloudflare dociera przez twoje połączenie Cloudflare One. Pozostają niewidoczne w Internecie. WAF, cache, bot management i Workers działają tak jak przy publicznym originie.
Czy trzeba otwierać port na firewallu?
Nie. Według Cloudflare origin zachowuje prywatne IP i nie potrzeba żadnego wyjątku przychodzącego na firewallu. Przy Cloudflare WAN nie trzeba nawet konektora na serwerze.
Jakie połączenia są obsługiwane?
Cloudflare wskazuje IPsec, GRE, CNI, Cloudflare Tunnel i Cloudflare Mesh. Unified Routing działa na wszystkich, z wyjątkiem Tunnel.
Dlaczego żądania kończą się timeoutem?
Prawie zawsze brakuje trasy powrotnej. Cloudflare mówi, że to był najczęstszy błąd w becie. Przy WAN lub Mesh skonfiguruj trasy dla 100.64.0.0/12 i 2606:4700 – cf1:5000 – – /64.
Czy działa też między prywatnymi sieciami?
Jeszcze nie. Wydanie obejmuje ruch publiczny do prywatnych originów. Cloudflare planuje zamkniętą betę dla ruchu między prywatnymi sieciami na początku 2027 roku.
Przejście na ruch między sieciami prywatnymi, spodziewane w 2027 roku
Kolejnym zapowiedzianym krokiem Cloudflare jest objęcie WAF i rate limitingiem również ruchu między sieciami prywatnymi. Na razie to ambicja, a zamknięta beta ma ruszyć na początku 2027 roku.
- Przeczytaj aktualną listę ograniczeń w dokumentacji, zanim zaplanujesz migrację.
- Zapytaj account team o warunki dostępu do Private Origins i przyszłej prywatnej bety.
- Spisz, które usługi wewnętrzne naprawdę powinny przyjmować żądania z zewnątrz, aby wiedzieć, gdzie ta ochrona jest potrzebna.
