Два кліенты OpenVPN на адным Linux-шлюзе: падзяліце палітыку

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

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

Ядро вырашае, а не дэман

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

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

Дайце кожнаму асобніку свой набор рэсурсаў

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull трымае маршруты, якія штурхае сервер, па-за лакальнай табліцай, а гэта менавіта тое, што трэба, калі табліцы палітыкі павінны быць яўнымі. Ці штурхае пэўны сервер таксама опцыю redirect-gateway і ці падтрымлівае ваша версія кліента форму фільтра, варта правяраць па дапаможніку, а не меркаваць.

Напішыце матрыцу: крыніца, табліца, прылада

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

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

Уласны транспарт тунэля не ў групе кліентаў

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

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

Выбар шляху не дае дазволу

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

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

Што адбываецца, калі адзін тунэль падае

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

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

Падобныя артыкулы