Зошто една подмрежа уште го заобиколува стандардниот маршрут на VPN

Го префрлате VPN во целосен тунел, најголемиот дел од сообраќајот слуша, и потоа една адреса одговара директно — печатач, NAS, скок-хост на 10.x. Очигледното читање е дека тунелот истекува, па ја намалувате метриката на стандардниот маршрут и ништо не се менува. Тој неуспешен обид е трагата: стандардниот маршрут е резерва, а не пресуда. Пребарувањето на маршрут го зема најдолгиот совпаѓачки префикс пред воопшто да ги спореди метриките, па /24 продолжува да победува против /0, без оглед кој број ќе го прикачите на кој било од нив. Кога овој ред е јасен, истекувањето обично е маршрут што некој намерно го инсталирал, или префикс што клиентот никогаш немал намера да го покрие.

Што всушност ветува стандардниот маршрут

0.0.0.0/0 се совпаѓа со секоја IPv4 дестинација со нула бита специфичност. Постои за да може хостот да стигне до сето она што неговата табела не го опишува подобро. Маршрута до 192.168.1.0/24 носи 24 совпаѓачки бита, па за 192.168.1.40 победува пред некој да ги спореди метриките, административното растојание или што клиентот го нарекува поле за приоритет. Истото правило важи во Linux FIB, табелата за рутирање на Windows и BSD стекот зад macOS.

На нормална LAN ова однесување е предност. Локалната подмрежа е директно поврзана, печатачот продолжува да работи додека тунелот го носи вашето прелистување, и ништо не е погрешно конфигурирано. Прашањето што вреди да се постави не е зошто таа една адреса оди директно, туку кој префикс во која табела се совпаѓа со неа, и кој го ставил таму.

Полустандардни маршрути, или зошто стандардниот запис може да изгледа недопренат

Најчистиот пример е redirect-gateway def1 во OpenVPN. Наместо да го избрише вашиот стандарден маршрут и да го замени, тој додава 0.0.0.0/1 и 128.0.0.0/1. Заедно парот го покрива целиот IPv4, секој префикс е подолг од /0, и двата го победуваат стандардниот на рутерот додека го оставаат на место. Пуштете список на маршрути потоа и оригиналниот стандарден маршрут е уште таму, уште покажува на вашата порта; едноставно никогаш не се избира за интернет дестинации.

wg-quick на WireGuard го постигнува истиот резултат преку рутирање засновано на политика. Кога AllowedIPs го покрива 0.0.0.0/0, тој создава своја табела, ги праќа означените пакети таму и додава правило што го игнорира префиксот со нулта должина на главната табела. Главната табела го задржува својот стандарден запис, а правилата одлучуваат дека табелата на тунелот се консултира прва за сообраќајот што го поседува интерфејсот.

Двата дизајна бараат точно еден маршрут надвор од тунелот: хост-маршрута до сопствената адреса на VPN серверот преку оригиналната порта. Без неа клиентот би се обидел да ги носи пакетите што го градат тунелот внатре во тунелот, и врската никогаш не би се завршила. Затоа маршрут што не е тунел во вашата табела е нормален дури и на строг профил со целосен тунел. Маршрутите што вреди да се доведат во прашање се оние што покриваат дестинации до кои навистина ви е грижа.

Метриките одлучуваат нерешено, префиксите одлучуваат победници

Метриките се споредуваат само меѓу кандидати што подеднакво добро се совпаѓаат со дестинацијата. На Linux ip route get 10.20.5.9 го печати победникот заедно со неговата табела, а ip route show table all ги наведува кандидатите, вклучувајќи ги сите полустандардни маршрути и секоја табела на која покажува правило. На Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 ја враќа избраната маршрута и изворната адреса, додека Get-NetRoute ја покажува суровата табела — но ефективната цена е метрика на маршрута плус метрика на интерфејсот, па бавен адаптер може да загуби нерешено што изгледа дека го добива.

Три случаи го покриваат најголемиот дел од она што ќе го видите:

• Иста дестинација, /24 против /0: /24 победува по должина на префиксот, што и да кажат метриките.
• Иста дестинација, две /24 со различни метрики: победува пониската ефективна метрика.
• Иста дестинација, две табели, едната избрана од правило за политика: правилото прво ја избира табелата, а споредбата на префиксите се случува во неа.

Третиот случај е местото каде што завршуваат повеќето од овие извештаи. Linux ip rule или филтер за VPN сообраќај на Windows може да испрати сообраќај во табела што никогаш не го држела стандардниот маршрут на тунелот, а главната табела изгледа совршено цело време.

Кој обично го поседува заобиколувањето

Започнете со профилот, не со табелата. Конфигурациите на split-tunnel и поставките за VPN по апликација намерно оставаат именувани префикси надвор од тунелот; работен профил што штити една приватна подмрежа и дозволува општото прелистување да оди директно се однесува како што е дизајниран, а неговото надминување ја крши политиката што требало да ја спроведува. Упатството за VPN рутирање на Microsoft ја повлекува истата линија меѓу присилно тунелиран сообраќај и експлицитни исклучоци, што го прави корисна вкрстена проверка пред да уредите нешто.

Потоа побарајте остатоци. Маршрута што покажува на интерфејс што повеќе не постои, или на адреса од претходната мрежа, се појавува откако докинг станиците, USB адаптерите и контејнерските мостови доаѓаат и си одат. Бришењето еднаш не е крајот: профилите за врска на NetworkManager, netplan датотеките и постојаните маршрути на Windows ја инсталираат повторно при следното поврзување или подигање, затоа пронајдете ја датотеката или профилот што ја поседува пред да уредите нешто.

Потоа проверете IPv6 одделно. ip -6 route и Get-NetRoute -AddressFamily IPv6 држат одделна состојба, одделни стандардни маршрути и одделно однесување на клиентот. Ревизија само на IPv4 не кажува ништо за хост со двоен стек што тивко претпочита нативна IPv6 патека, и само тоа може да направи клиентот да изгледа како split-tunnel.

Потврдете со сопствениот тек на апликацијата

Запишете ја дестинацијата што апликацијата навистина ја користи, потоа прашајте го системот за патеката што би ја земал од изворната адреса на која таа апликација се врзува. ip route get 10.20.5.9 from 192.168.1.40 одговара на тоа на Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 плус локалната адреса го прави тоа на Windows. Споредете го резултатот со она што го тврди профилот. Страницата за јавна IP на прелистувачот тестира една дестинација на еден протокол и не кажува ништо за приватната адреса што ја започнала жалбата.

Поправете го најтесното објект што ја објаснува разликата. Ако исклучокот е одобрен, запишете го префиксот и оставете го; ако не е, отстранете ја маршрутата или додајте експлицитна потесна маршрута низ тунелот наместо да ја намалувате метриката на стандардниот. Намалувањето на метрика не може да го надмине подолгиот префикс, а уредувањето на стандардниот додека две /1 маршрути го поседуваат интернет патот исто така не менува ништо.

Потоа повторно поврзете го тунелот и повторете го истото барање. Клиентите повторно инсталираат маршрути при секое поврзување, па промена што трае само до следното ракување не е тестирана. Ако патеката уште отстапува, преостанатите сомнителни се правило за политика, втора табела или филтер на страната на клиентот — не стандардниот маршрут.

• Именувајте ја дестинацијата и изворната адреса што апликацијата навистина ги користи.
• Испечатете ја победничката маршрута со ip route get или Find-NetRoute.
• Проверете дали /1 пар или табела за политика го поседува интернет патот.
• Наведете го секој префикс подолг од /0 што се совпаѓа со дестинацијата.
• Повторете ја проверката на IPv6 одделно.
• Следете ја преостанатата маршрута назад до датотеката, профилот или филтерот што ја инсталира.
• Поврзете се повторно и повторно извршете го барањето пред да го наречете поправено.

Ако сите седум се согласуваат со профилот, тунелот го прави точно она за што е конфигуриран, а поправката припаѓа на профилот, а не на метрика.