Как да изпращате само една частна подмрежа през 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 на сървъра твърди, че цялата подмрежа стои зад този клиент, което е претенция сайт към сайт, а не разрешение. Пакетите, които не съвпадат с 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 за препращане си струват четенето, ако обратният път е частта, която постоянно се проваля.

Подобни статии