Чаму правіла блакіроўкі кліента OpenVPN ніколі не трапляе ў ланцуг FORWARD

Два кліенты на адным серверы OpenVPN могуць дасягаць адзін аднаго, нават калі вы дадалі правіла DROP для іх пула. Правіла знаходзіцца ў ланцугу FORWARD, трафік відавочна ідзе, а лічыльнік гэтага правіла застаецца на нулі. Натуральная выснова — міжсеткавы экран зламаны. Часцей за ўсё пакет увогуле не ўваходзіў у ланцуг.

Ёсць два шляхі, якія пакет партнёра можа прайсці праз сервер OpenVPN, і іх вызначае канфігурацыя, а не міжсеткавы экран. Веданне таго, які шлях выкарыстоўваецца, паказвае, ці знаходзіцца правіла хаста наогул у правільным месцы.

Два шляхі, якія можа прайсці пакет партнёра

Калі ўнутраная перадача выключана, пакет ад кліента A прыходзіць на інтэрфейс тунеля з прызначэннем унутры прызначанага адраса кліента B. Табліца маршрутызацыі сервера адпраўляе яго назад праз той жа інтэрфейс тунеля, бо маршрут да адраса B належыць серверу. Гэта паток унутр і вонкі праз хост, і яго ацэньвае шлях перадачы IPv4.

Калі ўнутраная перадача ўключана, працэс сервера супастаўляе пакет з падключаным кліентам і запісвае яго назад самому гэтаму кліенту. Пакет апрацоўваецца ўнутры дэмана і ніколі не вяртаецца ў прыладу тунеля, таму шлях перадачы хаста цалкам прапускаецца. Кіраўніцтва OpenVPN 2.6 апісвае гэту опцыю як унутраную перадачу ад кліента да кліента, і менавіта таму правіла міжсеткавага экрана хаста не можа яго ўбачыць.

Існуе трэці варыянт у разгортваннях, якія пераносяць канал даных у модуль ядра. Рашэнне аб перадачы і шыфраванне выходзяць з прасторы карыстальніка, і тое, ці бачыць netfilter паток, залежыць ад таго, як пабудаваны шлях пераносу. Ніколі не мяркуйце, што стары набор правілаў паводзіць сябе на серверы з пераносам так жа, як на серверы ў прасторы карыстальніка. Пацвердзіце рэжым з працуючай канфігурацыі, а не з версіі пакета.

Калі лічыльнік ніколі не рухаецца

Нулявы лічыльнік азначае, што пакет не адпавядаў гэтаму правілу ў гэтай кропцы, і прычын некалькі. Першая — абыход вышэй: трафік ніколі не дасягнуў ланцуга. Другая — неадпаведнасць інтэрфейса, кірунку, крыніцы або прызначэння, што часта бывае, калі пул перанумаравалі, а правіла ўсё яшчэ называе стары прэфікс.

Трэцяя — пазіцыя. Правіла раней у ланцугу можа прыняць паток да таго, як ваша DROP будзе ацэнена, а правіла пазней можа быць тым, што фактычна вырашае вынік. Чытайце ланцуг па парадку з бачнымі лічыльнікамі, затым праверце, лічыльнік якога правіла расце, калі вы паўтараеце тэст.

Правядзіце адзін кантраляваны абмен паміж двума кліентамі, рэальныя адрасы якіх вы пацвердзілі з уласнага стану сервера, а не з арэнды, якую памятаеце. Калі адпаведны лічыльнік усё яшчэ не рухаецца, падазрайце шлях, перш чым перапісваць супастаўленне. Калі ён рухаецца, але злучэнне ўсё яшчэ паспяховае, скід перавызначаецца пазней, і праблема ў парадку. Гэты адказ вырашае, ці з'яўляецца рамонт зменай правіла або зменай тапалогіі, таму атрымайце яго перад любым рэдагаваннем.

Выбар мяжы, якая можа фільтраваць

Калі палітыка павінна жыць у міжсеткавым экране хаста, змясціце трафік там, дзе экран можа яго бачыць. Выключэнне ўнутранай перадачы — падтрыманы спосаб прымусіць трафік партнёраў праходзіць праз інтэрфейс тунеля і шлях перадачы, каштуючы праходжання кожнага пакета партнёра праз стэк хаста.

Затым супастаўце паток дакладна. Трафік прыходзіць на інтэрфейс тунеля і выходзіць з інтэрфейса тунеля ў абодвух кірунках, таму правілы, якія ўлічваюць толькі фізічны інтэрфейс, не будуць супадаць. Правілы на аснове адрасоў патрабуюць бягучага пула і павінны ўлічваць зваротны кірунак гэтак жа, як і прамы.

Многім разгортванням лепш служыць фільтрацыя на ўзроўні кліента або групы, дзе ідэнтычнасць вядомая і палітыка ідзе за карыстальнікам, а не за адрасам, які змяняецца пры перападключэнні. Гэта іншы механізм, чым ланцуг хаста, і іх не варта змешваць без яснай прычыны.

Не пераносьце набор правілаў старой тапалогіі праз міграцыю без змен. Пулы адрасоў, імёны інтэрфейсаў і рэжымы перадачы ўсе ўплываюць на тое, ці супадае правіла, а скапіяванае правіла, якое раней працавала, — самы падманлівы від доказаў. Пачніце з патоку, які вы хочаце дазволіць, і напішыце правіла, якое яму адпавядае.

Тэставанне ізаляцыі замест даверу да правіла

Тэстуйце забаронены выпадак і дазволены выпадак у адным запуску. Пачніце новае злучэнне ад аднаго кліента да другога і пацвердзіце, што яно не ўдаецца, затым пацвердзіце, што злучэнне, якое павінна быць дазволена, усё яшчэ працуе. Калі тэстуецца толькі першае, экран, які блакуе ўсё, выглядае як поспех.

Паўтарыце пасля перазагрузкі канфігурацыі сервера і пасля перападключэння кліента, бо ўнутраная перадача і прызначэнні пулаў — гэта стан выканання. Правярайце лічыльнікі ў абодвух кірунках, бо правіла, якое супадае з адным кірункам і не супадае з адказам, дае частковую ізаляцыю, якую цяжка заўважыць у хуткім тэсце.

Ізаляцыя — гэта назіраны вынік на мяжы, якая фактычна нясе паток. Правіла DROP недзе ў хаста не доказ; няўдалае злучэнне плюс рух лічыльніка правіла, якое яго выклікала, — доказ.