шлюз отвечает с другого IP

По барабану, как и с какого ip отвечает хост на трассировку. Это проблема хоста. На крайняк, попробуй трассировать с ключиком -I.

Не работает что?

И покажи полностью алиасы и таблицу маршрутизации.

при множественных адресах/шлюзах лучше указывать src интерфейс при трассировках и прочих пингах
команда
ip route get dst_ip - твой лучший друг при отладке

Не работает - обе сети одновременно на интерфейсе.

Вроде обычный логичный рассклад:

eth0      Link encap:Ethernet  HWaddr 00:14:85:11:2a:d9
          inet addr:10.152.216.222  Bcast:10.152.216.255  Mask:255.255.255.192
          inet6 addr: fe80::214:85ff:fe11:2ad9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:359360 errors:0 dropped:0 overruns:0 frame:0
          TX packets:268304 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:465364556 (443.8 MiB)  TX bytes:36634918 (34.9 MiB)

eth0:2    Link encap:Ethernet  HWaddr 00:14:85:11:2a:d9
          inet addr:217.26.11.238  Bcast:217.26.11.239  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.152.216.192  0.0.0.0         255.255.255.192 U     0      0        0 eth0
217.26.11.236   0.0.0.0         255.255.255.252 U     0      0        0 eth0

даже без роутингов я должен видеть адреса шлюза - 10.152.216.193, 217.26.11.237. Вот первый отрабатывает нормально, а при попытке что-то сделать с вторым:

PING 10.152.216.193 (10.152.216.193) 56(84) bytes of data.
64 bytes from 10.152.216.193: icmp_req=1 ttl=255 time=0.888 ms


PING 217.26.11.237 (217.26.11.237) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

Под оффтоп тоже самое, если на интерфейс вешаю вторую сеть.

Это?

http://crybit.com/iptables-rules-for-icmp/

How to block PING from your server to world ?
In this way you can block PING option from your server to outside. Add these rules to your iptables to do the same.
Block PING operation with message ‘Operation not permitted’

iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP

Example:

root@test [~]# ping google.com
PING google.com (173.194.34.136) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

Все разобрались. У провайдера где-то в настройках «галочка не стояла»

Да я действительно по ошибке выложил лог с заблокированным ICMP с белого IP так как для поста конфигурил поновой систему и не прописал разрешения. Но сути это не меняло, так как пинга от шлюза по белому IP просто небыло.

ip-alias и ассиметричная маршрутизация обычно требует настройки всяких rp_filter, arp_filter/announce/accept

И в iptables нужно быть аккуратным - входящие пакеты всегда приходят основной интерфейс, а не на алиасный.

Policy-routing тоже добавляет граблей...

входящие пакеты всегда приходят основной интерфейс, а не на алиасный

что есть основной интерфейс?

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

Если на сетевом интерфейсе несколько адресов, то не всегда можно понять на какой именно адрес пришел пакет.

Вы что-то путаете. У пакета есть Destination IP, так что понять можно. Непонятки возможны при передаче пакета, потому что выбор Source IP происходит только из Primary IP интерфейса. Secondary IP в выборах не участвуют, но это не случай автора топика. У него оба IP - Primary.

Куда придет броадкаст/мультикаст ? на какой интерфейс/адрес?

А форвардинг пакетов ?

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

Secondary IP - это то, что получается после ip addr add ... без label ?

Извиняюсь, я ответил только на ваш последний комментарий, вне контекста iptables. Собственно сетевой подсистеме (без надстроек) не пофиг на какой интерфейс/адрес пришел пакет, только в смысле того предназначен ли он самому хосту или идет транзитом. Причем в первом случае из-за «weak end system model» это может быть любой реальный интерфейс и любой собственный адрес хоста. Броадкаст придет на собственный адрес хоста перечисленный в таблице local (не на адрес интерфейса), будет принят и обработан независимо от наличия фиктивных интерфейсов. Их тупо не существует. Eth0:2 - это просто текст в in_ifaddr.ifa_label для обратной совместимости с ifconfig.

Браво!

Именно из-за этого в iptables правила проверяющие имя интерфейса через который был получен пакет работают с алиасным интерфейсам не совсем так, как это некоторые ожидали. О чем я и хотел предупредить ТС.

Про правила обработки трафика с алиасами я знаю. Вообще изначально просил провайдера сделать для нас vlan'ы, но они отказались. Хотя я не понимаю в чем проблема настроить конвертер на них.