Маршрутызацыя па крыніцы для двух пулаў VPN: што прапускае ваша правіла

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

Пошук адбываецца раней, чым крыніца перапісваецца

Для пакета, які перанакіроўваецца ад кліента VPN, ядро выконвае фіксаваную паслядоўнасць. Ён прыходзіць на інтэрфейс тунеля, праходзіць этап prerouting, дзе жывуць conntrack і DNAT, затым прымаецца рашэнне аб маршруце, затым перанакіраванне, затым postrouting, дзе SNAT ужываецца апошнім. Правіла выгляду from разглядаецца падчас гэтага рашэння аб маршруце, а значыць, яно бачыць зыходны адрас кліента, а не транслираваны.

Такім чынам, даданне правіла masquerade не мяняе таго, якая палітыка адпавядае зыходнаму патоку. Яно мяняе тое, што бачыць далёкі бок, а значыць, які зваротны шлях існуе. Гэта два розныя наступствы, і агляды змен пастаянна іх блытаюць. Раздзяліце іх — і дызайн звычайна робіцца відавочным на працягу хвіліны.

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

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

Тэст са шлюза — не тэст пула

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

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

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

Прыярытэт, а не месца ў файле

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

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

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

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

Зваротны шлях усё яшчэ павінен існаваць

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

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

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

Не лавіце ўласны тунель шлюза ў палітыцы

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

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

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