Linux два интерфейса одно подсети

unixforum.org

Два сетевых интерфейса в одной подсети (Как разнести?)

Два сетевых интерфейса в одной подсети

Сообщение be9 » 14.12.2008 13:35

Дано: комп с тремя сетевыми интерфейсами, работающий маршрутизатором и файлопомойкой (samba и ftp). Система — убунта 8.10.

Задача: разнести по разным интерфейсам файлопомойку и маршрутизатор.

Интерфейс ethext смотрит наружу.

ethint Link encap:Ethernet HWaddr 00:15:58:60:d9:fb
inet addr:10.0.0.250 Bcast:10.0.0.255 Mask:255.255.255.0

ethsrv Link encap:Ethernet HWaddr 00:15:58:60:d9:fc
inet addr:10.0.0.200 Bcast:10.0.0.255 Mask:255.255.255.0

И ethint, и ethsrv воткнуты в один свитч.

Хочется, чтобы вся деятельность, связанная с файлопомойкой, проходила _только_ через интерфейс ethsrv и никак не затрагивала интерфейс
ethint.

Однако arp, делаемый с другой машины, показывает, что и 10.0.0.200, и 10.0.0.250 имеют MAC интерфейса ethint — 00:15:58:60:d9:fb. Соответственно, все входит и выходит через ethint (10.0.0.250), а адрес 10.0.0.200 работает просто как его алиас, хотя и будучи включенным в ту же подсеть.

Как сделать, чтобы интерфейс ethint не перехватывал ничего для 10.0.0.200?

Re: Два сетевых интерфейса в одной подсети

Сообщение ford1813 » 14.12.2008 14:18

Poor Fred Сообщения: 1575 Статус: Pygoscelis papua ОС: Gentoo Linux, FreeBSD

Re: Два сетевых интерфейса в одной подсети

Сообщение Poor Fred » 14.12.2008 15:52

Хочется, чтобы вся деятельность, связанная с файлопомойкой, проходила _только_ через интерфейс ethsrv и никак не затрагивала интерфейс
ethint.

Re: Два сетевых интерфейса в одной подсети

Сообщение be9 » 14.12.2008 16:31

2 wertik: файлопомоечные сервисы, естественно, биндятся на ethsrv.
2 Poor Fred: дефолтные конфиги я читать умею, а умеете ли вы внимательно читать посты?

Еще раз: есть две сетевые карты, воткнутые в одну подсеть с одинаковой нетмаской. Допустим, кто-то хочет зайти на 10.0.0.200 (адрес ethsrv). Посылается arp-запрос, который приходит на оба интерфейса: на ethint и ethsrv, причем на ethint первым (он на шине PCI первым стоит). И ethint отвечает, что адрес 10.0.0.200 — это его адрес! Видимо смотрит, что в системе есть адрес 10.0.0.200, лежащий в той же подсетке, и откликается. А пакет, зашедший на ethsrv, отбрасывается системой, ибо она его уже обработала.

В итоге потом все пакеты начинают валить через физический интерфейс ethint, попадая на ethsrv через межинтерфейсное взаимодействие внутри ядра.

Читайте также:  Zabbix температура процессора linux

При этом я могу вообще вынуть патчкорд из ethsrv — оно все равно будет работать. А мне надо, чтобы электроны бежали именно по тому патчкорду и чтобы лампочка моргала у ethsrv, а не ethint

Источник

два интерфейса в одной подсети

Такая ситуация, есть два сетевых интерфейса (проводной и беспроводной), смотрят в одну и ту же сеть, получают разные ip-адреса от одного и того же dhcp-сервера, но в одной и той же подсети.

С ARP-Flux я разобрался, tcpdump’ом вижу, что ARP-ответы шлются через верные интерфейсы. Но после начинается ерунда с маршрутизацией, пакеты приходят на один интерфейс, а ответ уходит через другой, с другого ip-адреса. Причем, разумеется, с другим mac-адресом.

Хочется что бы всё было «нормально» — отвечало через тот же интерфейс, через который пришёл запрос, с ip-адреса интерфейса. Понимаю, что хочется странного, но может кто подскажет как такое реализовать? Подозреваю что при помощи policy based routing, но может есть способ проще? А если нет — то может кто подскажет как при помощи неё?

Сетевые интерфейсы [root@alarmpi ~]# ifconfig eth0 eth0: flags=4163 mtu 1500 inet 192.168.1.192 netmask 255.255.255.0 broadcast 192.168.1.255 ether b8:27:eb:50:e7:ad txqueuelen 1000 (Ethernet) RX packets 1414 bytes 92808 (90.6 KiB) RX errors 0 dropped 2 overruns 0 frame 0 TX packets 1522 bytes 201782 (197.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@alarmpi ~]# ifconfig wlan0 wlan0: flags=4163 mtu 1500 inet 192.168.1.181 netmask 255.255.255.0 broadcast 192.168.1.255 ether f8:1a:67:07:08:dd txqueuelen 1000 (Ethernet) RX packets 1236 bytes 369079 (360.4 KiB) RX errors 0 dropped 28 overruns 0 frame 0 TX packets 36 bytes 5003 (4.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
[root@alarmpi ~]# ip ro sh default via 192.168.1.1 dev eth0 metric 204 default via 192.168.1.1 dev wlan0 metric 305 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.192 metric 204 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.181 metric 305 
net.ipv4.conf.all.accept_local = 0 net.ipv4.conf.all.accept_redirects = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.arp_accept = 0 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_notify = 0 net.ipv4.conf.all.bootp_relay = 0 net.ipv4.conf.all.disable_policy = 0 net.ipv4.conf.all.disable_xfrm = 0 net.ipv4.conf.all.force_igmp_version = 0 net.ipv4.conf.all.forwarding = 0 net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.all.medium_id = 0 net.ipv4.conf.all.promote_secondaries = 0 net.ipv4.conf.all.proxy_arp = 0 net.ipv4.conf.all.proxy_arp_pvlan = 0 net.ipv4.conf.all.route_localnet = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.send_redirects = 1 net.ipv4.conf.all.shared_media = 1 net.ipv4.conf.all.src_valid_mark = 0 net.ipv4.conf.all.tag = 0 net.ipv4.conf.eth0.accept_local = 0 net.ipv4.conf.eth0.accept_redirects = 1 net.ipv4.conf.eth0.accept_source_route = 0 net.ipv4.conf.eth0.arp_accept = 0 net.ipv4.conf.eth0.arp_announce = 0 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.arp_ignore = 0 net.ipv4.conf.eth0.arp_notify = 0 net.ipv4.conf.eth0.bootp_relay = 0 net.ipv4.conf.eth0.disable_policy = 0 net.ipv4.conf.eth0.disable_xfrm = 0 net.ipv4.conf.eth0.force_igmp_version = 0 net.ipv4.conf.eth0.forwarding = 0 net.ipv4.conf.eth0.log_martians = 0 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.eth0.medium_id = 0 net.ipv4.conf.eth0.promote_secondaries = 1 net.ipv4.conf.eth0.proxy_arp = 0 net.ipv4.conf.eth0.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.route_localnet = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth0.secure_redirects = 1 net.ipv4.conf.eth0.send_redirects = 1 net.ipv4.conf.eth0.shared_media = 1 net.ipv4.conf.eth0.src_valid_mark = 0 net.ipv4.conf.eth0.tag = 0 net.ipv4.conf.wlan0.accept_local = 0 net.ipv4.conf.wlan0.accept_redirects = 1 net.ipv4.conf.wlan0.accept_source_route = 0 net.ipv4.conf.wlan0.arp_accept = 0 net.ipv4.conf.wlan0.arp_announce = 0 net.ipv4.conf.wlan0.arp_filter = 0 net.ipv4.conf.wlan0.arp_ignore = 0 net.ipv4.conf.wlan0.arp_notify = 0 net.ipv4.conf.wlan0.bootp_relay = 0 net.ipv4.conf.wlan0.disable_policy = 0 net.ipv4.conf.wlan0.disable_xfrm = 0 net.ipv4.conf.wlan0.force_igmp_version = 0 net.ipv4.conf.wlan0.forwarding = 0 net.ipv4.conf.wlan0.log_martians = 0 net.ipv4.conf.wlan0.mc_forwarding = 0 net.ipv4.conf.wlan0.medium_id = 0 net.ipv4.conf.wlan0.promote_secondaries = 1 net.ipv4.conf.wlan0.proxy_arp = 0 net.ipv4.conf.wlan0.proxy_arp_pvlan = 0 net.ipv4.conf.wlan0.route_localnet = 0 net.ipv4.conf.wlan0.rp_filter = 0 net.ipv4.conf.wlan0.secure_redirects = 1 net.ipv4.conf.wlan0.send_redirects = 1 net.ipv4.conf.wlan0.shared_media = 1 net.ipv4.conf.wlan0.src_valid_mark = 0 net.ipv4.conf.wlan0.tag = 0 
[root@alarmpi ~]# tcpdump -ni wlan0 arp 00:10:00.586376 ARP, Request who-has 192.168.1.181 tell 192.168.1.17, length 46 00:10:00.586535 ARP, Reply 192.168.1.181 is-at f8:1a:67:07:08:dd, length 28 [root@alarmpi ~]# tcpdump -ni eth0 arp 00:11:18.026342 ARP, Request who-has 192.168.1.192 tell 192.168.1.17, length 46 00:11:18.026447 ARP, Reply 192.168.1.192 is-at b8:27:eb:50:e7:ad, length 28 
[root@alarmpi ~]# tcpdump -nei wlan0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:33:44.018351 00:24:1d:df:c6:8e > f8:1a:67:07:08:dd, ethertype IPv4 (0x0800), length 74: 192.168.1.17 > 192.168.1.181: ICMP echo request, id 1, seq 1295, length 40 00:33:45.018072 00:24:1d:df:c6:8e > f8:1a:67:07:08:dd, ethertype IPv4 (0x0800), length 74: 192.168.1.17 > 192.168.1.181: ICMP echo request, id 1, seq 1296, length 40 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel [root@alarmpi ~]# tcpdump -nei eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:33:50.023437 b8:27:eb:50:e7:ad > 00:24:1d:df:c6:8e, ethertype IPv4 (0x0800), length 74: 192.168.1.181 > 192.168.1.17: ICMP echo reply, id 1, seq 1301, length 40 00:33:51.024437 b8:27:eb:50:e7:ad > 00:24:1d:df:c6:8e, ethertype IPv4 (0x0800), length 74: 192.168.1.181 > 192.168.1.17: ICMP echo reply, id 1, seq 1302, length 40 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel 

Источник

Читайте также:  Android port to linux

Linux два интерфейса в одной подсети

привязываю к ним интерфейсы eth0 и eth1 если в /etc/network/interfaces прописать сразу оба интерфейса, то активен и пингуется только eth0 если прописывать по отдельности, то работает и eth0 и eth1 соответственно. auto eth0 iface eth0 inet static address 192.168.0.121 gateway 192.168.0.228 netmask 255.255.252.0

auto eth1 iface eth0 inet static address 192.168.0.122 netmask 255.255.252.0 Подозреваю, что дело в шлюзе, так? Вроде бы шлюз прописывается только для первого интерфейса, а для второго надо прописывать маршрут. Но никак не могу разобраться, как правильно. Подскажите, пожалуйста, что сделать, чтобы заработало ) Зачем две сетевые карты? Тем более в одной подсети IPv4? Если нужна избыточность, то нужна агрегация LACP, если нужно два айпишника, то можно привязать к одной сетевухе, алиасингом или еще чем-то. Опечатка же во втором конфиге? auto eth1 iface eth0 inet static address 192.168.0.122 netmask 255.255.252.0

Русские форумы такие форумы?

Раскажи чего ты хочешь этим добиться? Чтобы понять почему идея гавно, надо чутка почитать как именно линукс роутит пакеты, в реальном мире, для каждого сконфигурированного интерфейса создаётся маршрут x.x.x.x/netmask означающий, что на адреса в этой подсети слать пакеты напрямую получателям, в твоём примере создастся: 192.168.0.0/22 dev eth0 proto kernel scope link src 192.168.0.121
Это значит, что всё исходящее в 192.168.0.0/22 должно уходить с eth0, а всё приходящее на eth0 из 192.168.0.0/22 адресовано нам. Когда ты создаешь второй интерфейс с адресом в той же сети, ещё один маршрут для подсети 192.168.0.0/22 создасться не может, т.к. её уже обслуживает eth0. Все входящие пакеты на 192.168.0.122 будут приходить на eth1, а в соотвествии с таблицей маршрутизации за 192.168.0.0/22 ответственный eth0, такие пакеты по дефолту считаются не парвильными и называются «марсианскими» (martian), если проверишь dmesg то наверняка увидишь там такие записи. Кароче в реальном мире твоя схема кривая и работать не должно, но обойти эти ограничения можно, но это ппц костыли и я бы за такое ими тебя и ***покарал***, например ты можешь включить Promiscuous режим на eth1, тогда ядро будет пропускать марсианские пакеты и твоё поделие начнёт подавать признаки жизни, но исходящий трафик всё равно будет ходить через eth0 по умолчанию.

Читайте также:  Powerpc linux gnuspe gcc

Re: Русские форумы такие форумы?

На украинских форумах такая же история, на англоязычных ресурсах также песня.

А что мешает сделать «ip ro add 192.168.0.32/28 dev eth1 scope link src 192.168.0.122» ? Пусть к .32-.47 ходят через eth1 ! PS любимые грабли нужно знать по именам: rp_filter, arp_accept, arp_announce, arp_filter, arp_ignore Чёта не понял про грабли))) Я бы в ситуации ТС создал ещё одну таблицу маршрутизации в /etc/iproute2/rt_tables и загнал туда eth1 правилом. Хотя всё равно решение плохое и так делать не надо

В такой ситуации ТС может просто реализовать только статическую схему, в которой часть хостов в сети будет адресоваться через eth0, а часть через eth1, просто добавив маршруты. Например, dgw через eth1, а все остальное через eth0, или половину сети через один интерфейс, а остальных через другой. Но ему нужно пройти грабли которые специально разложены на пути для тех, кто начинает использовать несколько самостоятельных интерфейсов в одной подсети. Это не запрещено, но ты должен доказать системе, что ты понимаешь на что подписался. Это как раз и нужно выразить через sysctl net.ipv4.conf. .

Re: Русские форумы такие форумы?

Re: Русские форумы такие форумы?

  1. мудаком его никто не называл
  2. неправым тоже
  3. но, о ужас! презренные хелперы-помогаторы дерзнули объяснять, как может (должно) сделать и стали требовать дополнительных пояснений (ну, тупые, ага)
  4. да — «Русские форумы такие форумы» ©

unixforum.org

Форум для пользователей UNIX-подобных систем

Источник

Оцените статью
Adblock
detector