amarao 14 дек 2015 в 13:39

Multihome IPv4 в Linux

4 мин

27K

Настройка Linux*Сетевые технологии*Серверное администрирование*

+17

Комментарии 25

BuriK666 14 дек 2015 в 15:29

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

Halt 14 дек 2015 в 15:41

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

+10

amarao 14 дек 2015 в 16:20

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

-3

dmitrmax 14 дек 2015 в 15:41

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

EvilMan 14 дек 2015 в 16:04

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

amarao 14 дек 2015 в 16:22

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

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

RicoX 14 дек 2015 в 16:25

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

amarao 14 дек 2015 в 16:50

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

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

Mendel 14 дек 2015 в 19:10

Кстати вот вспомнилось.
Семь лет назад баловался тем, что на хостинге через 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 15 дек 2015 в 01:12

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

amarao 15 дек 2015 в 02:22

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

evnp 14 дек 2015 в 15:58

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

evg_krsk 14 дек 2015 в 19:53

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

ValdikSS 14 дек 2015 в 20:40

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

RicoX 14 дек 2015 в 16:22

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

amarao 14 дек 2015 в 16:52

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

merlin-vrn 14 дек 2015 в 17:12

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

Ethril 14 дек 2015 в 18:38

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

amarao 14 дек 2015 в 19:15

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

navion 14 дек 2015 в 21:07

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

ValdikSS 14 дек 2015 в 20:53

Если к нашему серверу придёт запрос на первый интерфейс (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 15 дек 2015 в 02:57

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

Приятная новость: 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 15 дек 2015 в 18:20

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

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

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

izyk 15 дек 2015 в 19:39

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

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

vit1251 20 дек 2016 в 22:17

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Multihome IPv4 в Linux

Комментарии 25

Публикации

Истории