Апликација везана за VPN адресу ипак користи погрешан пут

Апликација се везује за адресу VPN-а, а веза ипак излази кроз уобичајену подразумевану руту. Ништа у везивању није омануло; оно је урадило тачно оно што везивање ради. Везивање сокета за локалну адресу бира изворну адресу коју језгро уписује у заглавље. Оно не поставља руту и не прави правило политике које би пакете са тим извором слало у одређени тунел.

Остатак овог приручника је редослед провере који користим, заједно са командом која даје свако запажање.

Шта везивање заправо одлучује

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

Зато пакет може изаћи са VPN изворном адресом на физичком интерфејсу. На другој страни долази из приватног опсега који мрежа никада није очекивала на том путу, повратни саобраћај нема руту назад, а веза се блокира или ресетује.

Linux референца за IP сокете документује семантику везивања. Део за рутирање живи у ip-rule и ip-route, и то су одвојени приручници с разлогом.

Потврдите да адреса припада овом именском простору

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Покрените те три у истом контексту као апликацију: исти именски простор и исти корисник ако га можете добити. Стари net30 дијаграм није доказ коју је адресу ваша тренутна топологија доделила клијенту. Читајте интерфејс који је заиста подигнут.

Прочитајте претрагу за тај извор и одредиште

Једна команда одговора на питање на које везивање није одговорило:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

Затим ip rule show каже да ли би неко правило изабрало другу табелу. Приоритети су овде важни, јер побеђује прво правило које се поклопи, а правило које хвата све изнад вашег чини ваше правило невидљивим.

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

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

Изводљив облик је посебна табела са подразумеваном рутом кроз тунел, плус правило које шаље VPN изворни опсег у ту табелу. Додајте изузетке које дизајн захтева, јер табела само са тунелским подразумеваним уносом ухватиће одредишта која треба да остану локална или доступна преко физичког пута.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Поништите са ip rule del и ip route flush table 100. Све тако додато нестаје након рестарта ако то не запише неки менаџер, што је истовремено сигурносна особина и разлог да једину копију не држите у историји свог шела.

Проверите са три запажања

Забележите извор који је апликација тражила, руту коју је претрага изабрала и извор који је сервер заиста видео.

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

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