Кліенты за вышэйшым VPN: маршрут ці NAT?

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

Вызначце мадэль вяртання, перш чым брацца за маршрутызацыю

У гэтым прыкладзе кліенты ніжэйшага ўзроўню выкарыстоўваюць 10.90.0.0/24, прызначаны шлюзу адрас вышэйшага тунелю — 10.80.0.6, а ўзгоджаны аддалены рэсурс — 172.20.0.30. Гэтай схеме адпавядаюць дзве мадэлі: захаваць ніжэйшую крыніцу і дамагчыся, каб далёкі бок яе маршрутызаваў, або трансляваць крыніцу ва ўласны адрас тунелю шлюза. Усё, што ідзе пасля гэтага рашэння, механічнае, а само рашэнне патрабуе ўладальніка сэрвісу. Адзін радок вышэй — гэта пагадненне аб маршрутызацыі з далёкім бокам; другі — лакальная змена палітыкі, якую вы можаце зрабіць самі. Менавіта блытаніна паміж імі ператварае змену на дзесяць хвілін у перамовы.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

Захаванне крыніцы праз маршрутызацыю

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

Калі адказ станоўчы, лакальная канфігурацыя невялікая: уключаная перадача, allowed-ips peer WireGuard, якія пакрываюць ніжэйшы дыяпазон, і палітыка фаеруола, якая дазваляе пераход у абодвух кірунках.

Наўмысная трансляцыя крыніцы

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

IPv6 патрабуе ўласнага праекта; капіяванне радка masquerade для IPv4 — гэта не архітэктура. Праверце трансляваны шлях новым злучэннем, а не кэшаваным.

Лакальны шлях даных усё яшчэ павінен працаваць

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

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

Адна крыніца — адна ідэнтычнасць сеансу

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

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

Вызначце стан адключэння, потым праверце тры запыты

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

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