Како кроз 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 о прослеђивању вреди прочитати ако је пут повратка део који стално пада.

Повезани чланци