Архив форумов ЦИТФорума

[PolAR]

ОС Linux. Тачка с 2-мя сетевухами.
Можно ли сделать так, чтобы, допустим ftp-клиент цеплялся к ftp-серверу, работающему на той же машине, но не через 127.0.0.1, а пакеты передавались по кроссоверу, который соединяет 2 сетевухи этого компа???
_________________
Come Together!! Right Now....

[dio]

не понял юмора...
а это тогда зачем? #ftp you_ip
_________________
All is not lost!

[dio]

только что проверил - все работает
под you_ip подразумевается ваши как один так и ВТОРОЙ адрес
_________________
All is not lost!

[and3008]

А теперь выдерни кабель и повтори эксперимент.

[PolAR]

Может можно как-то маршрутизацию настроить хитро?

2 and3008 если выдернуть шнур, как я понимаю, работать будет все равно именно через 127.0.0.1.
_________________
Come Together!! Right Now....

[dio]

вот только and3008 не сказал, что при выдернутом шнуре(подразумевая localhost очевидно) траффик не имеет привязки к логическому ip адресу и связанному с ним реальному аппаратному адресу, а это большая разница
_________________
All is not lost!

[PolAR]

2 dio: Если честно ничего не понял.
Ну и что, что пакет не имеет привязки к ИП и МАС?? Скорее всего и при воткнутом шнуре, когда пакет доходит до IP уровня, система определяет что он предназначен этому же компу и до физ. среды дело просто не доходит!
Но я щас сам проверю
_________________
Come Together!! Right Now....

[dio]

А что тут понимать? Я хотел сказать, что передача траффика через интерфейс loopback и через два РАЗНЫХ ip адреса(привязанных к 2 сетевухам) дело совершенно разное(даже при выдернутых шнурках!). Во втором случае работает посылка пакетов к физическим и реальным сетевым интерфейсам, а в первом случае используется петлевой интерфейс, который таких "путей" НЕ проходит и вообще НЕ использует никак понятие логического сетевого интерфейса и привязки его к аппаратному адресу посредством протокола arp, согласно модели стека протокола.
Резюме - "сетевая заглушка" ведет беседу ТОЛЬКО сама с собой (тихо сам с собою....я веду беседу...), в то время как обмен пакетами с физическими сетевыми картами через их ip адреса - это совсем другой коленкор! Те - ping 127.0.0.1 и ping ip_1
ping ip_2 (где ip_1 ip_2 твои реальные и разные физические сетевые интерфейсы) совсем большая разница!
Теперь понятно?
Так что, если тебя как и в начале этой темы интересует обращение к разным сетевым интерфейсам, тогда все в тему пошло, а если онанизм - тогда loopback
_________________
All is not lost!

[PolAR]

Моя задача - заставить пакеты ходить по шнуру.
Вот тут я поэкспериментировал:

Конфигурация:
localhost root # ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:47:6B:46:EE
inet addr:192.168.0.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
..................................................................................................
eth1 Link encap:Ethernet HWaddr 00:FF:01:A3:9B:80
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
_________________
Come Together!! Right Now....

[PolAR]

Запускаем пинг:
localhost artpol # ping -I 192.168.1.1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 192.168.1.1 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.144 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.111 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.116 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.106 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.099 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.087 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.105 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.102 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.104 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.110 ms
_________________
Come Together!! Right Now....

[PolAR]

Начинаем слушать интерфейсы:
localhost root # tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:33:30.376664 IP 169.254.242.23.netbios-dgm > 169.254.255.255.netbios-dgm: NBT UDP PACKET(138)
09:34:30.286410 IP 169.254.242.23.netbios-dgm > 169.254.255.255.netbios-dgm: NBT UDP PACKET(138)

localhost root # tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:33:30.377211 IP 169.254.242.23.netbios-dgm > 169.254.255.255.netbios-dgm: NBT UDP PACKET(138)
09:34:30.287049 IP 169.254.242.23.netbios-dgm > 169.254.255.255.netbios-dgm: NBT UDP PACKET(138)
_________________
Come Together!! Right Now....

[dio]

вот и я про тоже...если по шнуру - тогда интерфейсы, привязанные и физическим картам, а если онанизм, тогда 127.0.0.1
_________________
All is not lost!

[PolAR]

А вот это уже интереснее:
localhost root # tcpdump -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
09:35:47.320537 IP 192.168.1.1 > 192.168.0.1: ICMP echo request, id 2623, seq 26, length 64
09:35:47.320595 IP 192.168.0.1 > 192.168.1.1: ICMP echo reply, id 2623, seq 26, length 64
09:35:48.322580 IP 192.168.1.1 > 192.168.0.1: ICMP echo request, id 2623, seq 27, length 64
09:35:48.322625 IP 192.168.0.1 > 192.168.1.1: ICMP echo reply, id 2623, seq 27, length 64
Мой вывод: пакеты по шнуру ходить НЕ БУДУТ!!!
_________________
Come Together!! Right Now....

[dio]

они будут ходить так, как ты им скажешь, если задать статическое правило и такая возможность есть в принципе.
_________________
All is not lost!