Насочване на 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 отворен.
Запишете четирите отговора, на които сте се спрели, и наблюдението, което демонстрира всеки от тях. Транзитен път, който можете да опишете, е такъв, който можете да защитите на следващия преглед на инциденти.