Cloudflare объявила общий доступ к private origins — без публичного адреса сервера
Публичный сайт может получать трафик через частную сеть. Рассказываем о роли DNS, соединении с origin и расхождении нового анонса со старой бета-документацией.
Анонс касается маршрута от публичного сайта к частному origin
30 октября Cloudflare объявила об общем доступе к public-to-private origins после закрытого тестирования. Прокси компании получает запрос посетителя, применяет сервисы на границе сети и направляет его к исходному серверу по уже настроенному частному соединению. Отдельный публичный IP у этого сервера для такого маршрута не требуется.
Общий доступ не означает автоматическое включение на любом аккаунте: анонс требует отдельного разрешения Private Origins и связи с командой сопровождения. Для подключений, кроме Cloudflare Tunnel, также названа Unified Routing.
DNS выбирает не только адрес, но и способ доставки
Документация private network routing описывает настройку для проксируемых записей A и AAAA. Вместо обычного выхода к origin через интернет запрос отправляется в настроенный туннель. Запись DNS при этом должна оставаться проксируемой: один лишь частный адрес без нужного пути ещё не создаёт работающее подключение.
Для адресов RFC 1918, IPv6 ULA и диапазона CGNAT частная маршрутизация определяется автоматически. Настройку можно включить и для публичного адреса, который достижим только внутри конкретного туннеля. Если несколько записей A или AAAA используют одно имя и хотя бы одна включает private network routing, частный путь применяется ко всем записям этого имени.
Mesh и Tunnel решают разные сетевые задачи
Один из упомянутых вариантов подключения — Cloudflare Mesh. Его документация описывает частные IP для подключённых серверов и пользовательских устройств, обмен TCP, UDP и ICMP, а также объявление маршрутов к подсетям. Узлы Mesh используют Cloudflare One Client в headless-режиме на Linux. Это существующий компонент, а не отдельная новая СУБД или хостинг.
В сравнении продуктов Mesh предназначен для двусторонней частной связности и продолжительных соединений. Cloudflare Tunnel предлагает исходящий коннектор для публикации определённых приложений, имён и IP-маршрутов. Поддержка обоих вариантов в новом анонсе не делает их взаимозаменяемыми по устройству и требованиям к инфраструктуре.
Работающий туннель не гарантирует обратный маршрут
Руководство для Cloudflare WAN отдельно проверяет подписку, доступ к private origins, IPsec-подключения и статические маршруты. Для отказоустойчивости оно описывает два туннеля с разными конечными точками и приоритетами. Это требования конкретного WAN-сценария, а не обязательная схема для любого подключения через Tunnel или Mesh.
В этом же руководстве выделен диапазон Cloudflare Source IP: частная сеть должна уметь возвращать ответы по туннелю. Если исходный адрес или обратный маршрут настроены неправильно, клиент получает тайм-аут даже при наличии DNS-записи. Наблюдаемая доступность самого туннеля и успешное прохождение запроса к приложению проверяются отдельно, на разных участках сетевого пути.
| Наблюдение | Что отдельно проверяет документация |
|---|---|
| Туннель поднят, ответа приложения нет | Обратный маршрут для диапазона Cloudflare Source IP |
| Трафик пытается идти через интернет | Проксирование DNS и настройку private network routing |
Границы запуска и состояние справки
Анонс исключает совместную работу с Argo Smart Routing и Dedicated CDN Egress IP; проверка состояния origin требует Load Balancing. Private-to-private остаётся будущим направлением: закрытую бету планируют на начало 2027 года, а не объявляют доступной сейчас.
На момент проверки 1 ноября обзор и часть инструкций DNS ещё содержали отметку closed beta и дату обновления 7 мая. Сообщение от 30 октября новее этих страниц; поэтому статус запуска приведён по анонсу, а технические подробности старой справки не выдаются за обновлённые условия доступа.
