Как определить шлюз по умолчанию

ip route ?

а внимательно прочесть? я написал что 2 шлюза если интерфейсы виртуальные...

Здесь как раз беды нет, это в венде беда, раз они позволяют добавлять несколько дефолтных маршрутов.

А в чём беда, если они будут с разными метриками?

Для начала стоило бы уточнить, какой у тебя дистрибутив.

В CentOS7, например, нет ifconfig вообще. :)

Далее, есть просто команда route (не ip route) - можно в неё смотреть, опять же, если у тебя не CentOS7 :)

Ну и, наконец, шлюз «по умолчанию» - он один. То есть, совсем один.

Через ip route можно сделать несколько разных шлюзов «по умолчанию», но для разных сетей.

«Пишу скрипт для манипуляций с траффиком.»

Я обычно подхожу к вопросу с другого конца: попросту скриптом во временный файл пишу информацию, кто сейчас рутер. Что-нибудь типа:

route add default gw 192.168.219.254 eth0

echo «gw 192.168.219.254» > /tmp/router-ip

echo «eth0» > /tmp/router-iface

Для PPP соединений, рутер можно вообще не указывать, а только интерфейс. Соответственно, и пишем в файлы:

echo «» > /tmp/router-ip

echo «ppp0» > /tmp/router-iface

Можно прям целиком выдергивать и подставлять в команду route, чего париться-то.

Ну и, наконец, шлюз «по умолчанию» - он один. То есть, совсем один.

Все сюда, у нас тут новичок

В том, что наличие второго пораждает нездоровые треды в толкс.

Как определить шлюз по умолчанию

ip route show 0.0.0.0/0

«ip ro get XXXX from <interface_ip> iif <interface_name>» дает ответ через какой шлюз будет выполнена передача данных.

Семейство убунты. Релиз, хотя это не существенно Ubuntu 14.04 - 15.04.

Уже ближе, но! опять-таки не работает с виртуальными интерфейсами.

Собственно основная проблема в том, что скрипт будет работать на нескольких серверах, а подключение к сетям не у всех одинаковое. Моя задача извлечь все шлюзы по умолчанию и соотнести их с интерфейсами.

Самое близкое что я нашел,

ip a | grep glo
и
ip r

а XXXX это, пардон, что такое? кажется мне данная команда - ни что иное, как решение.

root@pc$ ip route get 8.8.4.4 from 10.0.0.145 iif eth1:1
RTNETLINK answers: Invalid argument

«ip route get 8.8.4.4 from 10.0.0.145» дает правильный ответ ?

Забыл, что если from локальный, то iif не требуется

В CentOS7, например, нет ifconfig вообще. :)

yum install net-tools

К сожалению нет..

root@pc$ ifconfig eth1:0 | grep add
eth1:0    Link encap:Ethernet  HWaddr 00:19:6d:73:2e:44  
          inet addr:30.0.0.145  Bcast:30.0.0.254  Mask:255.255.255.0

root@pc$ ifconfig eth1:1 | grep add
eth1:1    Link encap:Ethernet  HWaddr 00:19:6d:73:2e:44  
          inet addr:10.0.0.145  Bcast:10.0.0.234  Mask:255.255.255.0

root@pc$ ip route get 8.8.4.4 from 30.0.0.145
8.8.4.4 from 30.0.0.145 via 30.0.0.1 dev eth1 
    cache

root@pc$ ip route get 8.8.4.4 from 10.0.0.145
8.8.4.4 from 10.0.0.145 via 30.0.0.1 dev eth1 
    cache 

Как видите, в обоих случаях eth1 вместо (eth1:0 и eth1:1), да и шлюз во втором случае не верный.

По-моему я как-то не так объясняю. Попробую иначе.
Есть ВИРТУАЛЬНЫЙ интерфейс настроенный по dhcp.
Как мне получить адрес, маску и шлюз на этом конкретном интерфейсе?

Я слишком много времени уже ковыряюсь. Пробовал через ip, netstat, ifconfig... бестолку. Чем дальше я лезу, тем сложнее разобраться в той каше информации которую я умудряюсь нагуглить. Уже складывается мнение что шлюз на интерфейсе прописывается не для интерфейса а скорее для таблиц маршрутизации. Но и там я не могу соотнести виртуальные интерфейсы с адресами. Я так понимаю это вообще невозможно без костылей...

У dhcp-клентов обычно дампится информация о полученных настройках. dhcpcd у меня например создаёт /var/run/dhcpcd-ethX.envs со всей информацией.

Как видите, в обоих случаях eth1 вместо (eth1:0 и eth1:1)

Потому что eth1:0 и eth1:1 - это один и тот же интерфейс. ifconfig - это устаревшая утилита, которая показывает далеко не всё и не совсем так, как оно есть на самом деле.

да и шлюз во втором случае не верный

Не верный с какой именно точки зрения?

Уже складывается мнение что шлюз на интерфейсе прописывается не для интерфейса а скорее для таблиц маршрутизации.

Шлюз, как и интерфейс прописываются для маршрута. То есть перед отправкой пакета (например) ядро сначала по адресу назначения выбирает наиболее подходящий маршрут, а уже потом смотрит через какое место пакет отправлять.

«ip ro get» всегда права. Имя физического интерфейса она тебе сказала. алиас - это только дополнительный адрес, а не интерфейс. Как интерфейс его показывают по-старинке и для совместимости со старым софтом.

«ip a sh XXX» даст всю информацию по адресам интерфейса.

шлюз на интерфейсе прописывается не для интерфейса а скорее для таблиц маршрутизации

Шлюз по-умолчанию - это маршрут 0.0.0.0/0. Маршрут привязан к интерфейсу.

я не могу соотнести виртуальные интерфейсы с адресами

почему ?

ip -4 a sh  eth0.3
6: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    inet 10.0.0.64/24 brd 10.0.0.255 scope global eth0.3
       valid_lft forever preferred_lft forever
    inet 10.30.0.64/24 scope global eth0.3:x
       valid_lft forever preferred_lft forever

Есть физ. адатер (eth0), на нем поднят интерфейс vlan3 (eth0.3) и в этом vlan-е 2 подсети 10.0.0.0/24 и 10.30.0.0/24

В чем сложность ?

Потому что eth1:0 и eth1:1 - это один и тот же интерфейс...

Да причем тут ifconfig. Я знаю что это линки на один интерфейс. Но в роутах и iptables то я пишу именно виртуальные, и мне нужна информация по ним.

Не верный с какой именно точки зрения?

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

Шлюз, как и интерфейс прописываются для маршрута....

Да это и ежу понятно. Я тут спрашиваю как мне узнать где растет яблоко, а где груша, а в ответ слышу только, что это всё фрукты, что фрукты на кустах не растут, и кучу морали о садоводстве.

Я прекрасно понимаю что и зачем нужно. Уже разобрался. Поясняю на пальцах свой же вопрос:

root@pc$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth1:0
iface eth1:0 inet static
address 30.0.0.145
network 24
gateway 30.0.0.1
metric 1

auto eth1:1
iface eth1:1 inet dhcp
# здесь я знаю что шлюз сейчас 10.0.0.193
# но завтра он может измениться
metric 100

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 10.10.0.1
broadcast 10.10.0.255
netmask 255.255.255.0
bridge_ports eth0
bridge_fd 0
bridge_stp off

root@pc$ ip route
default 
    nexthop via 30.0.0.1 dev eth1 weight 5
    nexthop via 10.0.0.193 dev eth1 weight 2
default via 10.0.0.193 dev eth1 metric 100
10.0.0.192/28 dev eth3 proto kernel scope link src 10.0.0.145 
30.0.0.0/24 dev eth3 proto kernel  scope link src 10.0.0.145
10.10.0.0/24 dev br0 proto kernel scope link src 10.10.0.1
10.8.0.0/24 via 10.8.0.6 dev tun0 

Нужно получить список

eth1:0   30.0.0.1
eth1:1   10.0.0.193
tun0     10.8.0.6

для br0 (шлюз для локалки) и для ppp0 (выход через PPPoE) я вообще не уверен, что именно я должен получить...

Как видите, в обоих случаях eth1 вместо (eth1:0 и eth1:1)

man какбэ намекает тебе

The address is a protocol (IP or IPv6) address attached to a network device. Each device must have at least one address to use the corresponding protocol. It is possible to have several different addresses attached to one device. These addresses are not discriminated, so that the term alias is not quite appropriate for them and we do not use it in this document

Интерестно, как такой ″/etc/network/interfaces″ приводит к ″nexthop″ в маршрутах.

Но в роутах и iptables то я пишу именно виртуальные,

В смысле? Вы пишите ″iptables -i eth0:1″ что-ли?

root@pc$ ip route
1) default 
    nexthop via 30.0.0.1 dev eth1 weight 5
    nexthop via 10.0.0.193 dev eth1 weight 2
2) default via 10.0.0.193 dev eth1 metric 100
3) 10.0.0.192/28 dev eth3 proto kernel scope link src 10.0.0.145 
4) 30.0.0.0/24 dev eth3 proto kernel  scope link src 10.0.0.145

2 в данном случае не будет использоваться.

в (1) ядро с определенной вероятностью будет использовать разные шлюзы. вычислить какой будет использоваться для отправки следующего пакета нереально.

а вот 3 и 4 - это правда или ошибка копирования ? Если правда, то разбирайся со своими проблемами сам. src из левой сети для прямого маршрута - это источник странных граблей и проблем на пустом месте. Для косвенных маршрутов - да, пожалуйста, а для прямых - не надо.

Я бы в таком случае отказался от алиасов и использовал бы macvlan-интерфейсы на eth1

2 в данном случае не будет использоваться.

это да, при подъеме обоих виртуальных интерфейсов поднялось и 2 дефолтных, первый переписан, второй просто не удаляется в силу того что мне лень :)

а вот 3 и 4

Пардон, конечно ошибка. там эти правила при подъеме интерфейса прописались

в (1) ядро с определенной вероятностью...

Я уже понял свою ошибку и некорректность своего вопроса. Ошибка вопроса в том что шлюз это понятие маршрута, а следовательно в понятиях интерфейса, ip адреса, маски - условность. Но так случилось что мне нужно их знать.

Пришлось писать костыль, который, на удивление, с первого раза везде (из имеющихся серверов) заработал. Суть в том что нужно было добыть шлюз в данной подсети, причем шлюзом я называю хост на который пихать все пакеты вне вышеупомянутой подсети если направление находится за пределами подсети. Просто не на всех серверах адрес шлюза вида x.x.x.1, гдето последний октет далеко не всегда заканчивается как на роутере на единичку, где-то - 254, гду-то 100... а мне нужно их знать (в пределах скрипта)

Тред считаю закрытым. Спасибо.

Так может покажешь свое решение, вдруг еще кому пригодится?

не люблю делиться костылями, в большинстве своём люди слишком строго оценивают то, что оценивать вообще не нужно. да и косяк... на ppp0 пусто-пусто возвращает..