Адзін публічны хост для VPN і вэбу: як падзяліць ролі

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

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

Выберыце ўладальніка адраса раней за порты

Канцавы пункт тунэля і вэб-сервер могуць дзяліць адно ядро; сумеснае выкарыстанне адраса, порта і пратакола адначасова — гэта тое, што не працуе. WireGuard звычайна займае UDP 51820, OpenVPN займае UDP 1194 або TCP 443, а вэб-сервер займае TCP 443. Балючая пара — гэта OpenVPN праз TCP 443 побач з HTTPS, бо абодва хочуць адзін сокет, і ядро аддае яго таму, хто заняў першым. Толькі дэмультыплексар спераду, такі як sslh або проксі, які разумее TLS, дазваляе ім дзяліць гэты порт, і ён дадае кампанент, збой якога выглядае дакладна як праблема фаервола.

Паглядзіце на ўладальнікаў, перш чым нешта змяняць: ss -lntup друкуе лакальны адрас, порт і працэс для кожнага сокета, які слухае. Два радкі з 0.0.0.0:443 азначаюць, што другі сервіс так і не заняў порт, як бы весела ні выглядаў яго init-скрыпт. Маст таксама пераносіць уладальніка. Калі eth0 далучаецца да br0, адрас IP пераходзіць на br0 і кожнае правіла фаервола, якое згадвае eth0 перастае супадаць, таму прывязвайце сервісы да маста і пацвердзіце з дапамогай ip -br addr.

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

Маршрутызацыя паміж дзвюма LAN або NAT аднаго боку

Дзве LAN, якія не бачаць адна адну, могуць кожная набраць публічны хост, і той перасылае паміж тунэлямі. Гэтая маршрутызаваная схема патрабуе трох рэчаў: уключанай перасылкі, маршруту да кожнага аддаленага прэфікса і палітыкі перасылкі, якая прапускае транзіт. sysctl -w net.ipv4.ip_forward=1 закрывае першае, ip route add 10.20.0.0/24 dev wg1 другое, а радок nftables накшталт nft add rule inet filter forward iifname "wg0" oifname "wg1" accept трэцяе.

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

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

Праверце падзел, калі дзве ролі спынены

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

Тры каманды робяць гэты тэст канкрэтным. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ даказвае, што лакальны слухач адказвае без знешняга DNS, wg show на кліенце даказвае, што рукапацісканне завяршылася, а tcpdump -ni any port 51820 на хабе аддзяляе праблему маршрутызацыі ад праблемы ключа. Рукапацісканне, якое ніколі не з'яўляецца ў захопе, памерла да хоста: фаервол правайдэра, няправільны публічны адрас або правіла NAT на шляху.

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

Трымайце набор правілаў чытэльным, пакуль аднімаеце ролі. nft list ruleset павінен паказваць адно правіла accept на кірунак, які вам сапраўды патрэбны, а ланцужок forward, які прымае ўсё, — гэта не падзел, а працоўнае дэма.

Лініі доступу толькі з IPv6 і сервісы IPv4

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

Праверце кожнае сямейства асобна з curl -4 і curl -6, бо адзін паспяховы запыт нічога не кажа пра шлях, які вы не паспрабавалі. Уласнасць порта не змяняецца паміж сямействамі, але слухач змяняецца: ss -lntup паказвае сокеты IPv4 і IPv6 асобнымі радкамі, а 0.0.0.0:443 не закрывае [::]:443, калі працэс не папрасіў двухстэкавы сокет.

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