Чаму адна падсетка ўсё яшчэ абыходзіць маршрут 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.

У звычайнай лакальнай сетцы такія паводзіны — гэта функцыя. Лакальная падсетка далучана напрамую, прынтар працягвае працаваць, пакуль тунэль нясе ваша агляданне, і нішто не наладжана памылкова. Пытанне, якое варта задаць, не ў тым, чаму гэты адзін адрас ідзе напрамую, а ў тым, які прэфікс у якой табліцы яму адпавядае і хто яго туды паставіў.

Паўмаршруты, або чаму запіс па змаўчанні можа выглядаць некранутым

Найчысцейшы прыклад — 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 з рознымі метрыкамі: перамагае меншая эфектыўная метрыка.
• Той жа пункт прызначэння, дзве табліцы, адна выбрана правілам палітыкі: правіла спачатку выбірае табліцу, і параўнанне прэфіксаў адбываецца ўнутры яе.

Трэці выпадак — гэта тое, дзе заканчваецца большасць такіх дакладаў. Правіла ip rule у Linux або фільтр трафіку 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 асобна.
• Прасочыце маршрут, які застаўся, да файла, профілю або фільтра, які яго ўсталёўвае.
• Перападключыцеся і паўторна выканайце запыт, перш чым назваць гэта выпраўленым.

Калі ўсе сем узгаджаюцца з профілем, тунэль робіць менавіта тое, для чаго ён быў наладжаны, і выпраўленне належыць профілю, а не метрыцы.