Како разделениот тунел одлучува кој сообраќај го користи VPN-от
Разделениот тунел е збир одлуки за рути и поврзување, а не режим што го вклучувате. Погледнете како правилата по апликација, префиксите, DNS и безбедносните прекинувачи дејствуваат заедно.
Разделениот тунел е рутирачка политика изразена како збир правила, и клиентот е само она што ги инсталира. Раздвојувањето се случува на две места: правила за совпаѓање што избираат пат за секој пакет, и поврзувања што држат апликација на едно интерфејс, што и да каже табелата. Кој механизам го користи вашиот клиент објаснува повеќето изненадувања за кои луѓето известуваат.
Политика што можете да ја изразите во еден ред е проверлива. Политика опишана како побрзо прелистување не е, и нема да ви каже кое правило да го смените кога барањето оди по погрешниот пат.
Клиентот инсталира правила, јадрото го прави изборот
Кога тунелот се крева, клиентот додава рути и често правила за политика во истата табела што ја користат вашите други интерфејси. Секој пакет потоа стигнува до пребарување што ја споредува неговата дестинација со секој кандидат-префикс и го задржува најконкретното совпаѓање, додека приоритетот решава нерешени врски меѓу правила што покажуваат на различни табели. Ништо во тоа пребарување не знае дека пакетот дошол од таб на прелистувач, а не од задача за резервна копија. Правилото што победува е она што го поставува патот, и можете да го прочитате пред и по промената.
Затоа разделениот тунел може да изгледа произволен. Две дестинации во една апликација може да тргнат по различни патишта само затоа што едниот префикс е потесен од другиот.
Истиот избор постои на секоја платформа, иако имињата се менуваат. Windows ја турка одлуката во својата филтерска платформа, Android изложува список на дозволени апликации преку својата VPN услуга, а macOS го прикачува тунелот на уред што сѐ уште ја слуша табелата за рутирање. Белешките на Microsoft за рутирање вреди да се прочитаат за случајот со Windows, а водич напишан за една платформа ретко се пренесува непроменет на друга.
Поврзувањето по апликација и префиксите на дестинација се различни алатки
Политиката за дестинација прашува каде оди пакетот и се консултира со табелата за рути или правило за политика. Политиката по апликација прашува која програма го отвори сокетот, и платформата ја држи таа програма на интерфејсот на тунелот дури и кога поконкретна рута покажува на друго место. Втората е посилна затоа што преживува промени на табелата, но покрива само процеси што платформата може да ги припише. Помошен процес, вграден прелистувач или услуга што отвора сопствена врска може да не го наследи поврзувањето што го претпоставивте.
Ниту еден од двата пристапа не преживува политика заснована на имиња без помош. Адресите на големите сајтови ротираат низ мрежи за содржина, така што заковањето на име на домаќин за неколку префикси создава правило што тивко престанува да се совпаѓа. Политиката што мора да следи имиња бара компонента свесна за решавачот, а не статична рута.
DNS и безбедносниот прекинувач ги следат своите правила
Решавањето имиња е одделна одлука од рутирањето пакети, и разделениот тунел обично сака два решавачи: оној на компанијата за внатрешни имиња, локалниот за сѐ друго. Клиентот може да инсталира DNS поставки по интерфејс, да ги предаде барањата на посреден решавач или да ја остави системската стандардна вредност недопрена. Прелистувач со сопствен шифриран решавач ги заобиколува сите три распореди. Тестирајте едно пребарување наместо да претпоставувате дека решавачот ја следел рутата.
Безбедносниот прекинувач додава филтер одозгора, и тој филтер не секогаш разликува намерно исклучување од случајно истекување. Некои клиенти блокираат сѐ надвор од тунелот, додека други ги дозволуваат исклучувањата што ги објавува политиката, затоа прочитајте кое однесување го спроведува вашиот пред да се потпрете на кое и да е од двете.
Проверете го разделувањето од двете страни
Тестирајте ја вклучената патека и исклучената патека одделно, и проценете го резултатот по име на интерфејс, а не по јавна адреса. Овие команди претпоставуваат Linux домаќин со веќе кренат тунелски уред. Заменете 203.0.113.10 со дестинација што вашата политика ја рутира навнатре, и 198.51.100.25 со онаа што ја праќа нанадвор.
ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'
Читајте ги првите два одговора заедно, бидејќи интерфејсот наведен во секој од нив покажува дали разделувањето ја ставило таа дестинација на тунелот. Барањето до решавачот покажува кој сервер одговорил на внатрешното име, а последната команда докажува дека тунелскиот уред воопшто може да носи барање. Неуспех на втората линија додека првата успева значи дека политиката прави точно она што ѝ е кажано.
Повторете го збирот по повторно поврзување и по промена на мрежата. Обновата на закупот и менувањето интерфејси се местата каде разделувањето престанува да одговара на намерата за која е изградено, и зачуваниот излез од секое извршување го прави отстапувањето очигледно.