On 11.04.2012 12:10, skeletor wrote:
Это подтверждает только то, что вы двое наблюдали какую-то хрень.
Система по умолчанию отправляет пакет согласно роутингу, а не "откуда
пришел запрос". Так что или продемонстрируйте route -n get и tcpdump,
демонстрирующие что у Вас оно ходит не по роутингу, или прекращайте
дезинформировать людей.
Именно какую-то хрень!
Если посмотреть tcpdump, то пакеты уходят согласно таблице маршрутизации
(как и должно быть), но при этом в host IP подменяется тем IP на которых
пришёл запрос. При этом ответ будет уже идти с int2, хотя в src host
будет указан ip1 (ip на интерфейсе int1)
Это нормально, так и должно быть, и так всегда и было, кроме ответов с
udp-сокетов, слушавших на *:* (ряд софтин, типа ntpd, решает это
раздельным прослушиванием каждого адреса машины).
Что бы не быть голословным приведу то, что просят.
Приведу пример, когда запрос приходит на один интерфейс, а сервер на
него отвечает через другой (согласно таблице маршрутизации)
XX.XX.XX.85 - IP удалённого хоста, с которого будем производить проверку
нашего 2-канального сервера
AA.AA.AA.161 - шлюз для первого канала
AA.AA.AA.162 - IP на первом канале сервере (сетевая igb0)
BB.BB.BB.9 - шлюз для второго канала
BB.BB.BB.10 - IP на втором канале сервере (сетевая igb1)
# route -n get XX.XX.XX.85
route to: XX.XX.XX.85
destination: XX.XX.XX.0
mask: 255.255.254.0
gateway: BB.BB.BB.9
interface: igb1
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
Как видим, ответ должен уйти через второй канал.
Запускаем ping на первый канал (то есть ответ должен уйти через второй
канал) и смотрим tcpdump:
Для нормальной диагностики следует приводить эту самую команду ping, и
на какой из машин она запускается.
# tcpdump -i igb0 -t -v -n 'host XX.XX.XX.85 and ip proto \icmp'
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 96
bytes
IP (tos 0x0, ttl 58, id 56746, offset 0, flags [none], proto ICMP (1),
length 84)
XX.XX.XX.85 > AA.AA.AA.162: ICMP echo request, id 1589, seq 0, length 64
IP (tos 0x0, ttl 58, id 56816, offset 0, flags [none], proto ICMP (1),
length 84)
XX.XX.XX.85 > AA.AA.AA.162: ICMP echo request, id 1589, seq 1, length 64
а что в этот момент твориться на втором канале:
# tcpdump -i igb1 -t -v -n 'host XX.XX.XX.85 and ip proto \icmp'
tcpdump: listening on igb1, link-type EN10MB (Ethernet), capture size 96
bytes
IP (tos 0x0, ttl 64, id 58291, offset 0, flags [none], proto ICMP (1),
length 84)
AA.AA.AA.162 > XX.XX.XX.85: ICMP echo reply, id 1589, seq 13, length 64
IP (tos 0x0, ttl 64, id 58420, offset 0, flags [none], proto ICMP (1),
length 84)
AA.AA.AA.162 > XX.XX.XX.85: ICMP echo reply, id 1589, seq 14, length 64
Как видим, запрос приходит на один канал, а ответ уходит через второй
(ну согласно таблице маршрутизации).
Всё как и должно быть, и как всегда и было, если отсутствуют ipfw fwd и
reply-to. Собственно, ipfw fwd и reply-to делаются как раз за тем, чтобы
картина была _не такая_ как тут.
> Интересно так же посмотреть, что покажет tcpdump на XX.XX.XX.85:
# tcpdump -i em0 -t -v -n '(host AA.AA.AA.162 or host BB.BB.BB.10) and
ip proto \icmp'
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96
bytes
IP (tos 0x0, ttl 64, id 8102, offset 0, flags [none], proto ICMP (1),
length 84)
XX.XX.XX.85 > AA.AA.AA.162: ICMP echo request, id 22837, seq 0, length 64
IP (tos 0x0, ttl 60, id 26758, offset 0, flags [none], proto ICMP (1),
length 84)
AA.AA.AA.162 > XX.XX.XX.85: ICMP echo reply, id 22837, seq 0, length 64
IP (tos 0x0, ttl 64, id 8114, offset 0, flags [none], proto ICMP (1),
length 84)
XX.XX.XX.85 > AA.AA.AA.162: ICMP echo request, id 22837, seq 1, length 64
IP (tos 0x0, ttl 60, id 26879, offset 0, flags [none], proto ICMP (1),
length 84)
AA.AA.AA.162 > XX.XX.XX.85: ICMP echo reply, id 22837, seq 1, length 64
А это вот вообще где? В описании двухканального сервера никаких em0 не было.
то есть для конечно хоста достаточно то, что удалённый хост представился
нужным ему IP. Соответственно он делает вывод, что всё ок и сервер
доступен.
Показывать tcpdump, если запрос пришёл на тот интерфейс с которого уйдёт
(согласно таблице маршрутизации) смысла не вижу, так как там картина
будет ясна.
Возможно я где-то неправ или ошибся, но такая схема работает.
Если это и есть то, что было описано топикстартером - то это таки
дезинформация + вероятное непонимание, что именно и зачем делают
fwd/reply-to.
--
WBR, Vadim Goncharov, NUCL1-RIPE
