Зашто једна подмрежа и даље заобилази подразумевану 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 одвојено.
• Пратите преосталу руту назад до датотеке, профила или филтера који је инсталира.
• Поново се повежите и поново покрените упит пре него што то назовете исправљеним.

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