Кліенты LAN ігнаруюць VPN роўтара, пакуль не ўключана маршрутызацыя па палітыцы

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

Правіла фільтра не можа выбраць інтэрфейс

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

Прыклад ніжэй выкарыстоўвае LAN 192.168.8.0/24 на br-lan, тунельную прыладу tun0 і адну прыстаўку set-top box на 192.168.8.23, якая павінна ісці праз тунель.

Прачытайце пошук перад рэдагаваннем правілаў

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

Прывяжыце табліцу да кліентаў, якіх хочаце ахапіць

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

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Інтэрфейсы прашыўкі звычайна прадстаўляюць тыя ж аб'екты, што і старонка маршрутызацыі па палітыцы або палітыкі VPN. Спіс прылад там прасцей падтрымліваць, чым рукапісныя правілы, і ён звычайна перажывае абнаўленні, якія змяняюць сінтаксіс правілаў.

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

Трымайце лакальныя прызначэнні па-за тунелем

Новая табліца ведае толькі тыя маршруты, якія вы ў яе паклалі. Прэфікс LAN адсутнічае, таму трафік прынтара і NAS пайшоў бы па маршруце па змаўчанні ў тунель і знік. Маршрут throw спыняе пошук у гэтай табліцы і вяртае рашэнне галоўнай табліцы.

ip -4 route add throw 192.168.8.0/24 table 200

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

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