Multihome IPv4 в Linux

[@BuriK666]

Почему никто не использует 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24? Адреса специально выделенные для использования в документации.

[@Halt]

Потому что никто не читает документацию.

[@amarao]

Потому что на живых IP легче показывать. Это не пример настройки сетевого оборудования (где кривой роут может невинным людям поломать интернеты), а на реальных (похожих на использующиеся) диапазонах проще понять о чём речь и где тут серые адреса, а где белые.

[@dmitrmax]

С серверными приложениями понятно. А с какого адреса из трёх будут слать пакеты клиентские приложения на таком компе?

[@EvilMan]

От приложений трафик пойдёт по маршруту по-умолчанию с соответствующим адресом источника.

[@amarao]

Это вечная боль — когда приложение хочет послать что-то, оно чаще всего не выбирает кого использовать, а за него это решает ОС. Приложение может осознанно выбрать, но большинство десктопных приложений не выбирает и не даёт этого выбора пользователю.

Через какой из интерфейсов пойдёт трафик в этом примере — я думаю, никому не известно.

[@RicoX]

Ну можно прикостылить в принципе к каждому приложению свой IP на выход (правда только для TCP):
daniel-lange.com/archives/53-Binding-applications-to-a-specific-IP.html

[@amarao]

Да, есть такой метод.

К сожалению, костыльный. Жаль, что нет красивого системного решения.

[@Mendel]

Кстати вот вспомнилось.
Семь лет назад баловался тем, что на хостинге через curl использовал для запросов не только свой легальный ip, но и все ip сервера.

function mybot2($url,$ip=FALSE,$user_agent="Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)")
    {
    // получим контент
    $ch = curl_init();    // initialize curl handle
    if($ip<>FALSE) curl_setopt($ch, CURLOPT_INTERFACE, $ip);
    curl_setopt($ch, CURLOPT_URL, $url); // set url to post to
    curl_setopt($ch, CURLOPT_FAILONERROR, 1);              // Fail on errors
    curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); // return into a variable
    curl_setopt($ch, CURLOPT_TIMEOUT, 15); // times out after 15s
    curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);
    $document = curl_exec($ch);
    curl_close($ch);
    return $document;
    }

Интересно, от этого можно как-то просто защищаться?

[@grossws]

Как вариант, изолировать приложение в своём netns и роутить его трафик через определённый интерфейс.

[@amarao]

Да, и прочие ужасные системные вещи. А вот изящный user-friendly вариант — отсутствует. Хотя очевидно, что использование переменной среды окружения (типа DEFAULT_IFACE=eth0) должно было бы сделать шелловую жизнь лучше. Ну или хотя бы системное на уровне ядра «если не знаешь как юзать — юзай этот».

[@evnp]

Подходящего места для systemd-networkd еще не придумано, как я погляжу?

[@evg_krsk]

Я так понял, они и не претендуют на всеохватность в systemd-networkd. По крайней мере, пока. Так, для контейнеров, простых серверков и десктопов.

[@ValdikSS]

К сожалению, там нет поддержки source routing, а очень бы хотелось, очень.
Кто-нибудь подскажет вообще хоть что-нибудь, чем можно управлять source routing? Для OpenWRT есть mwan3, а под обычный линукс вообще нет ни софта, ни скриптов. Есть только bird, но он не совсем для этого. Очень давно ищу, ничего найти не могу.

[@RicoX]

Было уже неоднократно, например тут habrahabr.ru/post/225965
Но за напоминание спасибо.

[@amarao]

Оно то же средство для другой задачи использовало — на исходящий трафик. Меня интересовал вопрос равноправного присутствия в роли сервера.

[@merlin-vrn]

А зачем, LARTC мало? Точный же клон раздела split access.

[@Ethril]

А на Windows source-based routing как-нибудь можно реализовать?

[@amarao]

RAS должен уметь, по-идее.

[@navion]

Что-то есть прямо в сетевом стеке, но на практике не проверял.

[@ValdikSS]

Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Не совсем.
По умолчанию, наверное, в большинстве дистрибутивов (Ubuntu, Fedora, ArchLinux) уже стоит net.ipv4.conf.*.rp_filter=1. Знаю только Debian, где по умолчанию 0.
Если этот параметр установлен в значение 1, приложение, получающее входящий пакет, пришедший, скажем, на интерфейс с IP 188, вообще не получит его, его отбросит ядро как Martian packet.
Такие пакеты можно логировать, что очень удобно:

# sysctl net.ipv4.conf.*.log_martians=1

Если же rp_filter отключен, то в Linux ответ действительно пойдет с неправильным IP через неправильный интерфейс, независимо от протокола, и, с большой вероятностью, отбросится провайдерскими маршрутизаторами. А вот в Windows и OS X все интересней: в Windows, при использовании TCP, никакой дополнительной настройки source routing не требуется — ответ на пакет, пришедший на определенный интерфейс, пойдет через этот же интерфейс и с правильным IP, аналогичная ситуация для TCP наблюдается и в OS X.
А вот с UDP все интересней: как в Windows, так и в OS X, ответ на пакет, пришедший с одного интерфейса, уйдет через другой интерфейс с правильным IP другого интерфейса!

Надеюсь, в середине недели расскажу об этом более подробно отдельной статьей — такая, казалось бы, очевидная вещь, с которой сталкивался любой, кто настраивал Multi WAN и Multihoming, может использоваться для деанонимизации пользователей VPN.

[@izyk]

А почему вы про приоритеты не упомянули? На мой взгляд, их лучше указывать вручную. Очень гибкая вещь. И про встроенные таблицы тоже сказать нужно, в какой последовательности они обрабатываются ядром.

Приятная новость: policy routing имеет более высокий приоритет, чем dhcp'шный default route, так что обновление аренды не сломает маршрутизацию.

Тут как раз не нужно default route получать по dhcp и прописывать его в таблицу «main», вы же его уже настроили для каждого интерфейса, получайте по dhcp только адрес. А если у вас в главной таблице не будет маршрута по умолчанию. То можно сделать так:
ip rule add table main pref 3050
Главное чтобы приоритет был ниже (по номеру), чем у правил для таблиц по умолчанию (в вашем случае, скорее всего, у них 3276{5,4,3}).
ip rule будет выдавать что-то наподобие:
0: from all lookup local
3050: from all lookup main
32763:…
32764:…
32765: from 188.188.188.188 lookup eth0-route
32766: from all lookup main
32767: from all lookup default

Не большое замечание по безопасности.
Как вы правильно упомянули в примечание. Крайне не желательно расширять это правило на сеть (from 188.188.188.0/24). И даже если указан только ваш IP. Возможен такой сценарий:
Кто-то из сети 188.188.188. пошлет от вашего имени (подменив свой IP адрес на 188.188.188.188) вам пакет на любой другой адрес в Интернет, то ваш комп., согласно вашим правилам маршрутизации (32765: from 188.188.188.188 lookup eth0-route), в зависимости от настроек iptables, может переслать его по назначению.

[@amarao]

Спасибо за замечание.

роуты от dhcp обычно получает не человек, а клиент. И надо клиент отдельно явно убеждать «использовать роут или нет».

Было бы, кстати, правильно, так изнасиловать dhcp-клиент, чтобы он для каждого интерфейса дефолтный роут (и все остальные роуты) засовывал в эту таблицу. Это позволило бы сососуществовать с конкурирующими specific route'ами в нескольких VPN'ах, например, каждый из которых предлагает свой 192.168 ему слать и т.д.

[@izyk]

чтобы он для каждого интерфейса дефолтный роут (и все остальные роуты) засовывал в эту таблицу.

Легко. Надо только свой доп. скриптик положить в директорию dhclient.d.Если надо, могу опубликовать у меня для СентОС6 и Демьяна6 где-то было, там все просто, сделано на основе Демьяновского debug скрипта. Кстати, если вы не увеличите приоритет правила для таблицы main (ip rule add table main pref 3050). То скорее всего из локальной сети вам будет доступен только шлюз. Если вас не интересуют другие машины в локальной сети, например из диапазона 188.188.188.2-187,189-254, то можно не заморачиваться.

[@vit1251]

А нельзя создать отдельный интерфейс(псевдоним) завернуть с него весь трафик в какой-нибудь тунель/мост/псевдоинтерфейс, а потом со статического адреса шлюза этого туннеля снять уже статический адрес для маршрутизации. Внутри тунеля он будет меняться и оходить по основной таблице маршрутизации?