Комментарии 25
Почему никто не использует 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24? Адреса специально выделенные для использования в документации.
С серверными приложениями понятно. А с какого адреса из трёх будут слать пакеты клиентские приложения на таком компе?
От приложений трафик пойдёт по маршруту по-умолчанию с соответствующим адресом источника.
Это вечная боль — когда приложение хочет послать что-то, оно чаще всего не выбирает кого использовать, а за него это решает ОС. Приложение может осознанно выбрать, но большинство десктопных приложений не выбирает и не даёт этого выбора пользователю.
Через какой из интерфейсов пойдёт трафик в этом примере — я думаю, никому не известно.
Через какой из интерфейсов пойдёт трафик в этом примере — я думаю, никому не известно.
Ну можно прикостылить в принципе к каждому приложению свой IP на выход (правда только для TCP):
daniel-lange.com/archives/53-Binding-applications-to-a-specific-IP.html
daniel-lange.com/archives/53-Binding-applications-to-a-specific-IP.html
Кстати вот вспомнилось.
Семь лет назад баловался тем, что на хостинге через curl использовал для запросов не только свой легальный ip, но и все ip сервера.
Интересно, от этого можно как-то просто защищаться?
Семь лет назад баловался тем, что на хостинге через 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;
}
Интересно, от этого можно как-то просто защищаться?
Как вариант, изолировать приложение в своём netns и роутить его трафик через определённый интерфейс.
Подходящего места для systemd-networkd еще не придумано, как я погляжу?
Я так понял, они и не претендуют на всеохватность в systemd-networkd. По крайней мере, пока. Так, для контейнеров, простых серверков и десктопов.
К сожалению, там нет поддержки source routing, а очень бы хотелось, очень.
Кто-нибудь подскажет вообще хоть что-нибудь, чем можно управлять source routing? Для OpenWRT есть mwan3, а под обычный линукс вообще нет ни софта, ни скриптов. Есть только bird, но он не совсем для этого. Очень давно ищу, ничего найти не могу.
Кто-нибудь подскажет вообще хоть что-нибудь, чем можно управлять source routing? Для OpenWRT есть mwan3, а под обычный линукс вообще нет ни софта, ни скриптов. Есть только bird, но он не совсем для этого. Очень давно ищу, ничего найти не могу.
Было уже неоднократно, например тут habrahabr.ru/post/225965
Но за напоминание спасибо.
Но за напоминание спасибо.
А зачем, LARTC мало? Точный же клон раздела split access.
А на Windows source-based routing как-нибудь можно реализовать?
RAS должен уметь, по-идее.
Что-то есть прямо в сетевом стеке, но на практике не проверял.
Если к нашему серверу придёт запрос на первый интерфейс (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.
А почему вы про приоритеты не упомянули? На мой взгляд, их лучше указывать вручную. Очень гибкая вещь. И про встроенные таблицы тоже сказать нужно, в какой последовательности они обрабатываются ядром.
Тут как раз не нужно 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, может переслать его по назначению.
Приятная новость: 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, может переслать его по назначению.
Спасибо за замечание.
роуты от dhcp обычно получает не человек, а клиент. И надо клиент отдельно явно убеждать «использовать роут или нет».
Было бы, кстати, правильно, так изнасиловать dhcp-клиент, чтобы он для каждого интерфейса дефолтный роут (и все остальные роуты) засовывал в эту таблицу. Это позволило бы сососуществовать с конкурирующими specific route'ами в нескольких VPN'ах, например, каждый из которых предлагает свой 192.168 ему слать и т.д.
роуты от dhcp обычно получает не человек, а клиент. И надо клиент отдельно явно убеждать «использовать роут или нет».
Было бы, кстати, правильно, так изнасиловать dhcp-клиент, чтобы он для каждого интерфейса дефолтный роут (и все остальные роуты) засовывал в эту таблицу. Это позволило бы сососуществовать с конкурирующими specific route'ами в нескольких VPN'ах, например, каждый из которых предлагает свой 192.168 ему слать и т.д.
чтобы он для каждого интерфейса дефолтный роут (и все остальные роуты) засовывал в эту таблицу.Легко. Надо только свой доп. скриптик положить в директорию dhclient.d.Если надо, могу опубликовать у меня для СентОС6 и Демьяна6 где-то было, там все просто, сделано на основе Демьяновского debug скрипта. Кстати, если вы не увеличите приоритет правила для таблицы main (ip rule add table main pref 3050). То скорее всего из локальной сети вам будет доступен только шлюз. Если вас не интересуют другие машины в локальной сети, например из диапазона 188.188.188.2-187,189-254, то можно не заморачиваться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Multihome IPv4 в Linux