Праводзіць кліентаў 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 адкрытым.
Запішыце чатыры адказы, на якіх вы спыніліся, і назіранне, якое кожны з іх дэманструе. Транзітны шлях, які вы можаце апісаць, — гэта той, які вы зможаце абараніць на наступным разборы інцыдэнтаў.