Маршрутизувати клієнтів OpenVPN через Cloudflare? Спершу перевірте роль
Клієнт пристрою — не маршрутизатор. Підтвердьте, що роль Cloudflare пересилає пакети інших хостів, і залиште власний тунель сервера на його старому шляху.
У вас є робочий OpenVPN-сервер і хост, на якому також працює програмне забезпечення пристрою Cloudflare, і очевидний наступний крок виглядає як спрямування клієнтського трафіку до нього. Два робочі з'єднання на одній машині не утворюють транзитний шлюз. Бракує ролі, задокументованої для пересилання пакетів, що належать комусь іншому, і політики, яка класифікує ці пакети під час їх надходження.
Перед кожним правилом стоять чотири питання: який трафік входить, куди він іде далі, як відповіді знаходять зворотний шлях і що робить дизайн, коли цей другий шлях відмовляє. Перші два — питання можливостей.
Два сервіси на одному хості — не транзитний шлях
Клієнт пристрою створений для обробки трафіку, що виникає на машині, де він працює. Він перехоплює розв'язання імен або вибраний трафік застосунків і надсилає його через власний тунель, а його політика написана для користувача цього пристрою та процесів цього пристрою. Пакет, пересланий від клієнта OpenVPN, не є локальним виводом, тому ті самі правила його не класифікують. Це не деталь конфігурації, яку можна закрити ширшим правилом, бо саме вона вирішує, чи бачить програма пакет узагалі.
Тому питання дизайну — це питання можливостей. Або встановлений продукт має задокументовану роль, яка пересилає трафік для інших мереж, або функція транзиту належить зовсім іншому місцю.
Яка роль Cloudflare має право пересилати
Клієнт пристрою Cloudflare пропонує режими, що різняться за охопленням: лише розв'язання імен, трафік від пристрою і подеколи обидва. Жоден із цих режимів не перетворює хост на маршрутизатор для приватного діапазону, що надходить через інший тунель. Виділена роль маршрутизації — окремий продукт із власним конектором, реєстрацією та мережевою моделлю.
| 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 |
Перевірте встановлену роль, перш ніж проєктувати маршрути навколо неї. Прочитайте, який інтерфейс створює конектор, чи оголошує він конкретні префікси або маршрут за замовчуванням і чи поширюється локальна політика на переслані пакети так само, як на локальні. Якщо обробляється лише локальний трафік, сервер OpenVPN не може бути точкою транзиту, хоч би як було написано правило перекладу.
Тут також вимогу до публічного виходу треба сформулювати точно. Вихід, який надає Cloudflare для пересланого клієнтського трафіку, — це конкретний випадок використання, і його треба підтвердити щодо сервісу, який ви справді маєте.
Тримайте зовнішній тунель незалежним від нового маршруту
У ту мить, коли ви додаєте маршрут за замовчуванням до нового інтерфейсу, власний вихідний трафік сервера починає конкурувати за нього, і це включає відповіді клієнтам OpenVPN та вашу SSH-сесію до машини. Звичний симптом — тунель, який встановлюється і потім помирає, або адміністратор, заблокований ззовні, поки зміна виглядає такою, що спрацювала. Порівняйте ip route get для кінцевої точки до і після та використайте маршрутизацію на основі політики або маршрут до хоста, щоб залишити власний транспорт сервера там, де він був. Виконайте це порівняння з самої машини, бо саме власний погляд сервера на його маршрут має значення.
Виняток для публічної адреси сервера сам по собі недостатній, бо зворотний шлях кожного віддаленого адміністратора — це окремий потік. Вирішіть, які з цих потоків мають пережити зміну, а потім перевірте кожен, замість того щоб припускати, що перший покриває решту.
Обмежте пересилання й переклад одним потоком
Отримані пакети йдуть шляхом пересилання, а не шляхом локального виводу, тому важливе правило живе в хуку forward. Там, де наступному інтерфейсу потрібен переклад, обмежте джерело пулом клієнтів, призначення — дозволеним, а вихід — тим єдиним інтерфейсом. Правило masquerade, прив'язане лише до інтерфейсу, саме не вибирає маршрут і не дозволяє пересилання повз будь-який інший фільтр.
Вирішіть поведінку під час відмови заздалегідь, а потім перевірте її. Зупиніть подальший шлях і підтвердьте, що клієнти втрачають призначений вихід, а не тихо повертаються до звичайного висхідного каналу, бо це той результат, якого ніхто не помічає, доки трафік не почне виходити через неправильні двері. Повторіть перевірку для розв'язання імен і для IPv6, бо набір правил лише для v4 залишає шлях v6 відкритим.
Запишіть чотири відповіді, на яких ви зупинилися, і спостереження, що кожну з них доводить. Транзитний шлях, який ви можете описати, — це той, який ви зможете захистити на наступному розборі інцидентів.