Приложение, вързано към VPN адреса, все още излиза по грешния маршрут

Сокет, вързан към VPN адреса, следва обичайния маршрут по подразбиране. Проверете собствеността на адреса и търсенето с оглед на източника, преди да добавяте правила за политика.

Приложение се вързва към адреса на VPN, а връзката все пак излиза през обичайния маршрут по подразбиране. Нищо в bind не се е провалило; той направи точно това, което прави bind. Връзването на сокет към локален адрес избира адреса на източника, който ядрото слага в заглавката. То не инсталира маршрут и не създава правило за политика, което да изпраща пакетите с този източник в определен тунел.

Останалата част от това ръководство е редът за проверка, който използвам, заедно с командата, която дава всяко наблюдение.

Какво всъщност решава bind

Bind присвоява локален адрес на сокета. След това ядрото изпълнява същото търсене на маршрут, което би изпълнило иначе, освен ако правило за политика не промени коя таблица чете това търсене.

Затова пакет може да излезе с VPN адрес на източника по физически интерфейс. От другата страна той пристига от частен диапазон, който мрежата не е очаквала по този път, обратният трафик няма маршрут назад и връзката увисва или се нулира.

Справочникът за IP сокети в Linux документира семантиката на bind. Половината за маршрутизация живее в ip-rule и ip-route и това са отделни ръководства по причина.

Потвърдете, че адресът принадлежи на това пространство от имена

Адресът, към който можете да се вържете, трябва да съществува на интерфейс вътре в мрежовото пространство от имена, в което работи приложението. Адрес на партньор, адрес на шлюз или адрес, който съществува само в друго пространство от имена, не може да бъде вързан и извикването се проваля с EADDRNOTAVAIL.

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

Изпълнете тези три в същия контекст като приложението: същото пространство от имена и същия потребител, ако можете да го получите. Стара диаграма net30 не е доказателство кой адрес текущата ви топология е задала на клиента. Четете интерфейса, който действително е вдигнат.

Прочетете търсенето за този източник и дестинация

Една команда отговаря на въпроса, на който bind не отговори:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Първият ред отпечатва маршрута, по който би минал пакет от този източник до тази дестинация, включително изходящия интерфейс и предпочитания източник. Ако посочи физическия интерфейс, bind и маршрутът са в противоречие и пакетът ще излезе с източник, към който пътят не може да се върне.

След това 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. Всичко добавено по този начин изчезва при рестарт, освен ако мениджър не го запише, което е едновременно свойство за безопасност и причина да не пазите единственото копие в историята на шела си.

Проверете с три наблюдения

Запишете източника, който приложението е поискало, маршрута, който търсенето е избрало, и източника, който сървърът действително е видял.

Тези три могат да се разминават и всяко разминаване сочи на различно място. Заснемане на интерфейса на тунела доказва, че пакетът е излязъл с правилния източник. Заснемане на физическия интерфейс доказва, че е излязъл по грешния път. Изгледът от страната на сървъра е единственият, който доказва пътя от край до край.

Ако приложението предлага опция за връзване към устройство или режим на маршрутизиране за всяко приложение, третирайте го като различен механизъм с различни ограничения. Подобно изглеждащи настройки не всички водят до едно и също решение на ядрото.

Подобни статии