практика говорит о другом :)# route add x.x.x.6 x.x.x.2
# netstat -rn | grep ^x.x.x.6
x.x.x.x x.x.x.2 UGHS 0 0 rl0
# ping x.x.x.6
PING x.x.x.6 (x.x.x.6): 56 data bytes
36 bytes from x.x.x.2: Redirect Host(New addr: x.x.x.6)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 a86b 0 0000 40 01 3433 x.x.x.1 x.x.x.6
64 bytes from x.x.x.6: icmp_seq=0 ttl=64 time=0.912 ms
# netstat -rn | grep ^x.x.x.6
x.x.x.6 00:0c:6e:3e:d4:ea UHLW 0 2 rl0 1197
система FreeBSD
теперь теория. согласно модели ОСИ данные идут с верхнего уровня до нижнего, физического.
пока они дойдут до физики, пройдут еще много уровней, где с ними может произойти моного интересного.
в частности есть уровень ip, на котором определятся маршрут для исходящего пакета. приоритет имеет маршрут с большей маской сети. если рассматривать задачу в сети езернет (врядли автор вопроса подразумевал иную физику), то после конфигурации интерфейса в таблицу роутинга попадет вся подключенная к езеру сеть с маской /24. первый пакет на конкретный ип удет по маршруту на всю сеть, далее, на уровне ниже - арп, отрезолвит мак и внесет в таблицу роутинга спецефичный маршрут с маской /32 для этого хоста с маком. в дальнейшем пакеты уже будут уходить по этой новой записи.
теперь мы добавляем маршрут к .6 через .2 (мой случай), которым заменяем маршрут с маком. выход пакета имеет примерно такую логику - уровень ip заглядывает в таблицу роутинга, и видит что .6 доступен через .2, передает пакет на уровень arp, но с информацией о том, что пакет надо отправить по маку .2, что arp и делает, попутно, если надо, определяя мак .2. но .2 вроде не глупа и видит что отправитель .1 и получатель .6 в одной сети и могут обойтись без .2, поэтому в на .1 отправляется icmp redirect, что можно видеть после моей команды ping. после обработки данного сообщения на .1 в таблицу роутинга помещается нормальный прямой маршрут на .6 с маком вместо хопа через .2
само-собой, на .2 должен быть включен ip routing, т.е. грубо говоря, возможность принимать пакеты для других хостов и передавать их дальше согласно routing table
теперь ответы на вопросы
> смогут ли общаться .1 и .4 между собой?
да, смогут
> Как отработает ping с .1-го на .4-ый ?
это я и описал, только ип другие, так что пакеты будут идти с .1-го на .4-ый через .2-ой до обработки icmp redirect, после будут ходить напрямую. есть возможность запретить icmp redirect, тогда пакеты всегда будут ходить через .2-го
> Т.е. если ДА, то .1-й получит ответ от .4-го через .3-й или .2-й?
согласно таблице роутинга на .4-ом пакет будет отправлен через .3-ий, с оговоркой на icmp redirect
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
(??) on 26-Дек-07, 03:14 
