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

Поврзани статии