Праводзіць адну падсетку LAN праз OpenVPN і захаваць маршрут па змаўчанні

Захавайце маршрут LAN па змаўчанні, пакуль адна падсетка ідзе праз тунель. Параўнайце табліцу палітык з праўкамі асноўнай табліцы, затым выберыце NAT або маршрут на баку сервера.

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

Адзін маршрут па змаўчанні, два ўладальнікі

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

У OpenVPN ёсць перамыкач менавіта для гэтага. route-noexec не дазваляе кліенту наогул кранаць асноўную табліцу, а значэнні, якія ён мог бы выкарыстаць, перадаюцца ў скрыпт route-up як route_vpn_gateway, dev і адрасы інтэрфейса. Затым вы вырашаеце, якая табліца атрымае які маршрут, у кодзе, які можна прачытаць пазней.

Табліца палітык супраць перапісвання асноўнай

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

Асобная табліца — адзіны варыянт, які масштабуецца далей за адну падсетку. Дайце ёй імя адзін раз, а затым спасылайцеся на яго па імені, каб нікому не даводзілася трымаць у галаве лік:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

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

Правіла павінна адпавядаць і хасту

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

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

ip route get 203.0.113.9 from 192.168.50.1

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

NAT або маршрут на далёкім баку

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

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

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

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

Зрабіце так, каб падзел перажыў перападключэнне

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

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

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