Табела рутирања наспрам стварне претраге: где иде VPN саобраћај

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

Табела је скуп кандидата, а не одлука

Сваки унос описује префикс и шта учинити са саобраћајем који му одговара: послати га на интерфејс, предати следећем скоку или одбацити. Ништа у том списку није поређано по намери, а унос који човеку изгледа најконкретније није увек онај који језгро бира, јер избор следи најдуже поклапање префикса, а међу једнаким префиксима метрику.

Зато је први корак питати језгро уместо читати списак. Команда за претрагу одговара за дестинацију, а са аргументом извора одговара за тачан пар који би користила прослеђена или везана веза:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

Претрага пролази кроз правила, а затим кроз табеле

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

ip rule show
ip route show table all | head -40
ip route show table 100

Ако правило шаље саобраћај из вашег VPN пула у табелу 100, онда је табела 100 она која је важна, и главна табела је мамац. То је и механизам рутирања заснованог на извору на рутеру: иста дестинација може имати два различита одговора зависно од тога одакле је пакет дошао, и само претрага са аргументом извора открива који важи.

IPv6 има своја правила и табеле. Дизајн који покреће обе фамилије потребан је обе претраге, а радни одговор IPv4 ништа не говори о путу v6 који клијент са два стека може да преферира.

Шта VPN клијент инсталира

Клијенти обично не замењују подразумевану руту, јер би то сломило сопствени спољашњи пут тунела. Они инсталирају нешто конкретније што побеђује по дужини префикса: пар полуподразумеваних рута које покривају 0.0.0.0/1 и 128.0.0.0/1 је класичан трик, јер су обе дужи префикси од 0.0.0.0/0 и заједно покривају цео простор. Други инсталирају конкретне приватне префиксе плус правило политике, а неки додају ознаку да би се ухватио само изабрани саобраћај.

Зато "VPN ми није променио подразумевану руту" није доказ неуспеха. Проверите шта је заиста додао и да ли предметна дестинација пада у те префиксе:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Две полуруте је лако пропустити у дампу јер не изгледају као подразумевана рута. Конфигурација подељеног тунела која је заборавила да укључи префикс производи тачно онај симптом који јурите: апликација која је требало да користи тунел уместо тога резолује и повезује се локално. Упоредите инсталиране префиксе са дестинацијама које кориснику заиста требају, а не са адресама које сте случајно тестирали. Листа подељеног тунела која покрива сервер датотека али не његов резолвер производи везу која се резолује на јавну адресу и затим не прође аутентификацију, што изгледа као проблем са лозинком, а јесте проблем са рутом.

Спољашња рута такође мора да преживи

Тунел је сам по себи саобраћај. Пакети који носе инкапсулирани терет иду на адресу партнера преко физичког интерфејса, и тај пут не сме бити рутиран назад у тунел. Када јесте, добијате карактеристичан квар где се тунел успостави и затим престане да пропушта саобраћај, јер је транспорт за тунел сада унутар тунела.

Проверите адресу партнера као што сте проверили унутрашњу дестинацију, и потврдите да се резолује на физички интерфејс, а не на тунел:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Рекурзивна рута, правило политике које хвата партнера, или подразумевана рута замењена клијентом пуног тунела су три уобичајена узрока. Сва три су видљива у спољашњој претрази, и ниједан није видљив у дампу главне табеле узетом накнадно.

Шта излаз рутирања не може да вам каже

Исправна претрага значи да би језгро послало пакет на разумно место. То не значи да га заштитни зид дозвољава, да га IPsec политика покрива, да га NAT правило преводи или да удаљена страна има повратну руту. Свако од тога је каснија фаза, и белешке strongSwan о прослеђивању описују ланац кроз који пакет мора да прође на оба краја.

Такође не узима у обзир везивање на нивоу апликације. Процес може да се веже за интерфејс, постави ознаку или користи сопствени резолвер и повеже се под именом које се резолује другачије од онога што сте тестирали. Када је претрага исправна а веза и даље не успева, следеће питање је који процес је ствара и да ли тај процес види исту табелу као ви.

Зато држите дијагностику уређену: именујте дестинацију и извор, покрените претрагу, читајте само табелу и правило које је претрага именовала, затим тестирајте следећу фазу. Тај редослед држи истрагу рутирања у минутима и оставља запис који неко други може да прати, што налепљена табела никада не чини.