VPN на хасце ці ўнутры ВМ? Працоўная інструкцыя для рашэння

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

Вызначце ўладальніка, перш чым кранаць кліент

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

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

Запішыце адказ адным радком побач з імем ВМ: guest-owned або host-owned. У лабараторыі з шасці машын гэтая нататка зэканоміць больш часу, чым любы крок ніжэй, бо яна не дазваляе вам шукаць няспраўнасць у тунелі, якога ніколі не было ў машыне, у якую вы ўвайшлі.

WSL1 і WSL2 — процілеглыя выпадкі

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

WSL2 — наадварот. Ён запускае сапраўднае ядро ў лёгкай дапаможнай ВМ за віртуальным камутатарам Hyper-V, а яго адрасная прастора транслюецца праз адаптар на баку хаста. Таму Linux-кліент унутры дыстрыбутыва паводзіць сябе як на фізічнай Linux-машыне: ён стварае tun0 або wg0, усталёўвае ўласныя маршруты і працуе. Збой жыве на баку хаста. Калі кліент VPN для Windows падключаецца з палітыкай, якая блакуе трафік у лакальных сетках, ён лічыць падсетку WSL2 недаверанай лакальнай сеткай і абрывае шлях NAT. Тады дыстрыбутыў губляе DNS і знешні доступ, пакуль яго ўласны тунель яшчэ здаровы: wg show паведамляе пра рукапацісканне, ip route выглядае правільна, а curl завісае.

Якое выпраўленне вам даступна, залежыць ад зборкі Windows. Старэйшае — гэта выключэнне ў кліенце хаста для падсеткі WSL, якое дадаецца ў наладах лакальнай сеткі або раздзеленага тунеля кліента. Навейшае, на зборках Windows 11, якія яго падтрымліваюць, — люстраваная сетка: змесціце networkingMode=mirrored у раздзел [wsl2] файла %UserProfile%\.wslconfig, выканайце wsl --shutdown, і дыстрыбутыў будзе дзяліць інтэрфейсы хаста замест прыватнай падсеткі NAT. Люстраваны рэжым таксама змяняе паводзіны localhost і ўваходных портаў, таму стаўцеся да яго як да міграцыі, а не да пераключальніка.

NAT, мост і што бачыць хост

Пад NAT пакеты тунеля госця адрасуюцца на публічны адрас сервера VPN і выходзяць праз адаптар хаста як шыфраваныя UDP або TCP. Хост бачыць адзін паток і колькасць яго байтаў, нічога пра прызначэнні ўнутры яго. Пад маставым адаптарам госць мае ўласную ідэнтычнасць 2-га ўзроўню ў фізічнай LAN, атрымлівае ўласную арэнду DHCP і выглядае для любой палітыкі на аснове MAC як другая прылада. Ні адзін рэжым не дазваляе хасцу чытаць карысную нагрузку тунеля; маставы госць проста значна больш прыкметны для сеткі вакол яго.

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

Інструкцыя: размясціць, наладзіць, даказаць

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

1. ip route get 1.1.1.1 з адказам tun0 або wg0 азначае, што тунель належыць госцю, а eth0 з прыватным наступным крокам азначае, што ім валодае хост.
2. resolvectl query example.com або прачытайце /etc/resolv.conf там, дзе госць не запускае службу рэзалвера. Тунель, які перадае трафік, але не DNS, — самы часты стан паўналадкі.
3. Параўнайце выхады: curl -4 -s https://ifconfig.me у госці супраць curl.exe -4 -s https://ifconfig.me на хасце. Розныя адрасы азначаюць, што тунелем валодае госць, а хост у VPN з госцем, які паказвае хатняга правайдэра, — гэта выпадак «нічога не атрымана ў спадчыну».
4. Паўтарыце абодва з -6. Тунель толькі для v4 выдае v6, калі кліент яго не блакуе або не маршрутызуе, і шмат кліентаў пакідаюць v6 на фізічным інтэрфейсе па змаўчанні.

Для схемы хост-шлюза, дзе некалькі гасцей дзеляць адзін тунель, хост павінен перасылаць і трансляваць. На Linux-хасце гэта тры часткі, і госць ціха вяртаецца на свой звычайны маршрут, калі якой-небудзь з іх няма:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

На баку WireGuard AllowedIPs пункту хаста павінен уключаць падсетку гасцей, напрыклад 192.168.122.0/24, інакш зваротныя пакеты ніколі не прыйдуць і налада будзе выглядаць як праблема фаервола. Хост Windows дасягае таго ж выніку праз абагульванне падключэння да Інтэрнэту або правіла NAT на камутатары Hyper-V і патрабуе такой жа праверкі зваротнага шляху.

Калі схема яшчэ адкрытая, гэтая табліца ахоплівае самыя частыя варыянты:

Два тунелі, два госці і канфлікты паміж імі

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

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

Праверце, а затым пакіньце аднаўленне ўладальніку

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

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