Як адправіць праз VPN толькі адну прыватную падсетку

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

Тры ўмовы, якія вызначаюць рашэнне

Па-першае, вам патрэбны дакладны прэфікс і маска ад уладальніка сеткі. Сетка 10.x не з'яўляецца прэфіксам; прэфікс гэта 10.20.0.0/16. Пераканайцеся, што ён не перакрывае вашу хатнюю LAN, мост Docker ці іншы VPN, які вы запусцілі, бо перакрыццё робіць маршрут неадназначным, і ядро выбірае не той запіс.

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

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

WireGuard: AllowedIPs гэта табліца маршрутаў

На кліенце AllowedIPs пералічвае прызначэнні, якія могуць увайсці ў тунэль, а wg-quick ператварае кожны запіс у звычайны маршрут. Такім чынам, кліенцкая палова гэтай задачы гэта адзін радок.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

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

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Перастаноўка гэтых двух гэта памылка, якую я бачу найчасцей. Калі змясціць 10.20.0.0/16 у раздзел peer сервера, гэта сцвярджае, што ўся падсетка знаходзіцца за гэтым кліентам, што з'яўляецца заяўкай site-to-site, а не дазволам. Пакеты, якія не адпавядаюць AllowedIPs ні аднаго peer, адкідаюцца моўчкі, таму няправільны запіс выглядае як праблема з фаерволам.

Калі вы кіруеце маршрутамі самі, усталюйце Table = off пад [Interface] і дадайце патрэбны маршрут. Тады нічога не дадаецца аўтаматычна, таму маршрут належыць туды, што ўздымае інтэрфейс.

OpenVPN: праштурхніце маршрут, затым пераканайцеся, што ён дайшоў

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

push "route 10.20.0.0 255.255.0.0"

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

Кліент, якому патрэбны вузкія паводзіны супраць сервера з поўным тунэлем, павінен ігнараваць толькі тыя часткі, якіх не хоча. У OpenVPN 2.4 і пазней pull-filter існуе менавіта для гэтага.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

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

Калі прыватная падсетка знаходзіцца не на VPN-серверы, а за іншым кліентам, сервер трэба паведаміць. Дадайце файл для кожнага кліента праз client-config-dir, які змяшчае iroute 10.20.0.0 255.255.0.0, плюс адпаведны route, каб іншыя кліенты даведаліся пра шлях. Без iroute у сервера няма прычыны адпраўляць гэты прэфікс менавіта праз той тунэль.

IPsec: селектары трафіку павінны супадаць

У IPsec няма маршруту, які трэба праштурхнуць. Два бакі ўзгадняюць, якія адрасы знаходзяцца ўнутры тунэлю, і трафік па-за ўзгодненымі селектарамі не шыфруецца і не адпраўляецца праз яго. На кліенце strongSwan селектары зададзены яўна.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Калі шлюз наладжаны з 0.0.0.0/0 з абодвух бакоў, звужэнне IKEv2 звычайна паменшвае дачэрнюю SA да перасячэння двух прапаноў, што і ёсць жаданы вынік. Некаторыя шлюзы замест гэтага адхіляюць прапанову, якая не адпавядае іх наладжаным селектарам, і ў журнале тады бачная няўдалая дачэрняя SA, а не скарга на маршрутызацыю. Калі гэта адбываецца, змена належыць шлюзу, бо кліенцкі маршрут не можа стварыць тунэль для селектара, якога іншы бок не прыме.

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

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

Трымайце канчатковы пункт і DNS па-за рашэннем

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

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

Праверце, затым перазагрузіцеся і праверце зноў

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Першы радок называе інтэрфейс. Калі ён называе ваш фізічны інтэрфейс, маршрут не ўсталяваўся. У Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 адказвае на тое ж пытанне, а апошняя праверка павінна паказваць ваш звычайны адрас, а не адрас VPN-сервера.

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

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