Re: настройка сетевых интерфейсов
2015-07-07 2:40 GMT+03:00 Tim Sattarov sti...@gmail.com: Спасибо, не знал тогда строка должна выглядеть как: ip -o link | grep -E eth0|eth2 в смысле: причем здесь `ip -o |sh| grep` ? проклятые сокращения :) ip -o l sh | grep это ip -o link show | grep On 2015-07-06 07:12, Anatoly Pugachev wrote: немного offtopic, Тимур, для скриптования ip , есть удобный ключ -o (one line) , например: # ip -o l sh | grep -E eth 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:3f:2f:c7 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:26:9d:12 brd ff:ff:ff:ff:ff:ff PS: grep -A -B конечно тоже решают задачу, но ip -o реально полезный, например когда обрабатываете несколько (заранее не известно сколько их) IP адресов на интерфейсе.
Re: настройка сетевых интерфейсов
немного offtopic, Тимур, для скриптования ip , есть удобный ключ -o (one line) , например: # ip -o l sh | grep -E eth 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:3f:2f:c7 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:26:9d:12 brd ff:ff:ff:ff:ff:ff PS: grep -A -B конечно тоже решают задачу, но ip -o реально полезный, например когда обрабатываете несколько (заранее не известно сколько их) IP адресов на интерфейсе. 2015-06-08 4:19 GMT+03:00 Tim Sattarov sti...@gmail.com: # ip link | grep -A1 -E eth0|eth2 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc sfq master br0 state UP mode DEFAULT group default qlen 1000 link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff -- 5: eth2: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:24:27:fe:3f:c8 brd ff:ff:ff:ff:ff:ff
Re: настройка сетевых интерфейсов
Спасибо, не знал тогда строка должна выглядеть как: ip -o link | grep -E eth0|eth2 в смысле: причем здесь `ip -o |sh| grep` ? On 2015-07-06 07:12, Anatoly Pugachev wrote: немного offtopic, Тимур, для скриптования ip , есть удобный ключ -o (one line) , например: # ip -o l sh | grep -E eth 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:3f:2f:c7 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:26:9d:12 brd ff:ff:ff:ff:ff:ff PS: grep -A -B конечно тоже решают задачу, но ip -o реально полезный, например когда обрабатываете несколько (заранее не известно сколько их) IP адресов на интерфейсе. 2015-06-08 4:19 GMT+03:00 Tim Sattarov sti...@gmail.com mailto:sti...@gmail.com: # ip link | grep -A1 -E eth0|eth2 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc sfq master br0 state UP mode DEFAULT group default qlen 1000 link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff -- 5: eth2: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:24:27:fe:3f:c8 brd ff:ff:ff:ff:ff:ff smime.p7s Description: S/MIME Cryptographic Signature
Re: настройка сетевых интерфейсов
Опции up/down и есть скрипты, товарищ. :) Натурально. Забавно читать вместе без скриптов и оттестировать скрипт. :))) Скрипт - это отдельный файл, я предложил вариант решения в одном файле конфига. Так что это костыль, но не скрипт :)
Re: настройка сетевых интерфейсов
не забываем еще про pre-up и pre-down Munko O. Bazarzhapov JabberID: v...@aginskoe.ru mail: vec...@gmail.com 8 июня 2015 г., 15:55 пользователь Vasiliy P. Melnik ba...@vpm.net.ua написал: Опции up/down и есть скрипты, товарищ. :) Натурально. Забавно читать вместе без скриптов и оттестировать скрипт. :))) Скрипт - это отдельный файл, я предложил вариант решения в одном файле конфига. Так что это костыль, но не скрипт :)
Re: настройка сетевых интерфейсов
А может всетаки бридж лучше? А то бондинг это както чуток другое 8 июня 2015, в 15:13, Илья mir...@yandex.ru написал(а): Если, что я : 1) в вопросе и имел это в виду Скрипт - это отдельный файл. 2) задача практически решена с помошью bond интерфейса так (https://wiki.debian.org/Bonding): auto eth0 iface eth0 inet manual bond-master bond0 bond-primary eth0 bond-mode active-backup up route add default 192.168.1.1 gw eth0 down route add default gw 192.168.1.1 eth0 auto wlan0 iface wlan0 inet manual wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf bond-master bond0 bond-primary eth0 bond-mode active-backup up route add default 192.168.1.1 gw wlan0 down route add default gw 192.168.1.1 wlan0 auto bond0 iface bond0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 bond-slaves none bond-primary eth0 bond-mode active-backup bond-miimon 100 3) теоретически, пока не поняты пара вопросов (хотя я и не основательно тестил): 3.1 при выдергивании интерфейсов пропадает маршрут по умолчанию, который gateway 192.168.1.1 . решено пока up,down add router вызовами - возможно не правильно, но работает 3.2 при переключении с wlan на eth и одновременном присуствии eth поднимается как 10 вместо 100Мбит Опции up/down и есть скрипты, товарищ. :) Натурально. Забавно читать вместе без скриптов и оттестировать скрипт. :))) Скрипт - это отдельный файл, я предложил вариант решения в одном файле конфига. Так что это костыль, но не скрипт :) -- С уважением, Илья. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/787691433765...@web2h.yandex.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b8350523-245c-4584-bb54-eeebfc96e...@vpm.net.ua
Re: настройка сетевых интерфейсов
On Sun, Jun 07, 2015, Vasiliy P. Melnik ba...@vpm.net.ua wrote: Изначально товарищу хотелось использовать eth0 если он подключен, а здесь наоборот, приоритет имеет wlan0. Может мне еще поехать к нему и оттестировать скрипт, а потом еще и его зарплату получить? Спросил как без скриптов - вот так без скриптов, дальше пусть сам думает. Опции up/down и есть скрипты, товарищ. :) Натурально. Забавно читать вместе без скриптов и оттестировать скрипт. :))) З.Ы. я без наезда - но делать за кого-то его работу не буду. Советом подсказать - это да, для этого рассылка и нужна. Совет в том виде, в котором он был дан, увы, задачу не решает по концептуальным причинам. Вы, судя по всему, этого ещё не поняли. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150607212324.ga8...@sie.protva.ru
Re: Настройка сетевых интерфейсов
On 2015-06-06 04:51, Илья wrote: Наверное, я неправильно вопрос поставил. Мне нужен всегда статический адрес устройства и чтобы все настраивалось в одном файле, без вызова скриптов. Пока ковыряю в строну bonding (я не знал как это называется), пока его функционал меня удовлетворяет. Проблемы возникают с включением / отключением wlan0 интерфейса, но я думаю это проблема драйвера устройства: У меня raspberry и wifi dwa-125 - а он офицально не поддерживается. Я в свое время такую задачу решал сетевым мостом. привязать интерфейсы ethN и wlanN к бриджу и присвоить статический адрес именно ему. вне зависимости после этого, какой бы ни был физический интерфейс поднят - адрес один и тот же. Только надо будет аккуратно настроить сам бридж, чтобы не пересылал траффик между сетями. smime.p7s Description: S/MIME Cryptographic Signature
Re: настройка сетевых интерфейсов
On 2015-06-06 16:28, Eugene Berdnikov wrote: On Sat, Jun 06, 2015 at 09:29:43PM +0300, Artem Chuprina wrote: Кроме того. У меня в свое время был, гм, опыт. Были сервера в офисе. Было два провайдера, основной и резервный. Адреса, правда, разные (failover средствами DNS), но существенно не это. Существенно то, что входящий TCP на резервный канал работал на ура, а вот UDP не везло, потому что ответ на TCP идет с того же интерфейса, поскольку сеанс, а Нет, в tcp никакой привязки коннекции к интерфейсу нет, поэтому такое соединение должно было бы рваться, если бы не была обеспечена маршрутизация пакетов с определёнными src_ip через своего провайдера. В линуксе это достигается с помощью ip rules. skip Мне кажется, что дискуссия зашла не туда. протоколам верхнего уровня все равно как идет фрейм, если только он нормально доставлен. ни IP ни TCP/UDP не имеют никакого представления об интерфейсе, кроме его IP характеристик. ниже разъяснение, TL/DR: в layer2 сети load balancing будет работать только если его настроить, иначе будет работать только один из интерфейсов (в нашем случае оба конца подключены к одному и тому же сегменту), блокируя второй механизмами STP. все ответы на ARP запросы были отосланы от MAC адреса br0, и никогда от реального выходного интерфейса. end of TL/DR само разъяснение: #brctl show bridge namebridge idSTP enabledinterfaces br08000.002427fe3fc8noeth0 eth2 # ip link | grep -A1 -E eth0|eth2 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc sfq master br0 state UP mode DEFAULT group default qlen 1000 link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff -- 5: eth2: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:24:27:fe:3f:c8 brd ff:ff:ff:ff:ff:ff # ip link show dev br0 4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 00:24:27:fe:3f:c8 brd ff:ff:ff:ff:ff:ff Отмечаем, что бридж имееет MAC адрес интерфейса, который в дауне на соседней машине, откуда я зашел на этот сервер: $ arp 192.168.1.1 ? (192.168.1.1) at 0:24:27:fe:3f:c8 on en0 ifscope [ethernet] (адрес бриджа) # brctl delif br0 eth2(удаляем даун интерфейс) # ip link show dev br0 4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff мак адрес бриджа сменился на адрес от eth0 то же самое на клиенте $ arp 192.168.1.1 ? (192.168.1.1) at aa:0:4:0:a:4 on en0 ifscope [ethernet] все это время я подключен к серверу и изменения мак адреса ловились очень быстро, моя SSH сессия работала все это время. Надеюсь помог. С уважением Тимур smime.p7s Description: S/MIME Cryptographic Signature
Re: настройка сетевых интерфейсов
Изначально товарищу хотелось использовать eth0 если он подключен, а здесь наоборот, приоритет имеет wlan0. Может мне еще поехать к нему и оттестировать скрипт, а потом еще и его зарплату получить? Спросил как без скриптов - вот так без скриптов, дальше пусть сам думает. З.Ы. я без наезда - но делать за кого-то его работу не буду. Советом подсказать - это да, для этого рассылка и нужна.
Re: настройка сетевых интерфейсов
On Sat, Jun 06, 2015 at 09:29:43PM +0300, Artem Chuprina wrote: Кроме того. У меня в свое время был, гм, опыт. Были сервера в офисе. Было два провайдера, основной и резервный. Адреса, правда, разные (failover средствами DNS), но существенно не это. Существенно то, что входящий TCP на резервный канал работал на ура, а вот UDP не везло, потому что ответ на TCP идет с того же интерфейса, поскольку сеанс, а Нет, в tcp никакой привязки коннекции к интерфейсу нет, поэтому такое соединение должно было бы рваться, если бы не была обеспечена маршрутизация пакетов с определёнными src_ip через своего провайдера. В линуксе это достигается с помощью ip rules. И в этом отношении никакого отличия udp от tcp нет. Отличие лишь в том, что для udp нет неявной привязки src_ip исходящих пакетов к какому-то адресу, и если приложение не делает bind() на нужный адрес, то ответные пакеты попадают в ядро с пустым src_ip и ядро заполняет src_ip по применённому маршруту. В частности, может подставить в src_ip адрес выходного интерфейса. С tcp такого никогда не происходит, потому что tcp-коннекция изначально создаётся со строго определённым квадруплетом (src_ip, src_port, dst_ip, dst_port). ответ на UDP - по общим правилам маршрутизации, т.е. пока (по мнению сервера) основной жив - через основной. Правила маршрутизации для tcp и udp одинаковые, они вообще применяются на другом уровне стека протоколов -- на уровне ip (L3). И я подозреваю, что дополнительный эффект этой ситуации будет в том, что даже в случае одного адреса на двух интерфейсах TCP-сеанс будет рваться, если упадет тот интерфейс, через который он был установлен. Хотя это надо проверять, может быть, и нет. Нет. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606202818.gc10...@sie.protva.ru
Re: настройка сетевых интерфейсов
Victor Wagner vi...@wagner.pp.ru writes: В Fri, 05 Jun 2015 21:11:27 +0300 Илья mir...@yandex.ru пишет: […] Идеально бы было, если при выдергивании кабеля wlan брал себе этот адрес. […] При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Последнее время я так делать перестал, потому что в качестве dhcp-сервера стал использовать роутер с dnsmasq. А dnsmasq умеет поддерживать локальную DNS зону, в которую прописывает hostname присланные ему в dhcp-запросах. И мне в общем-то пофигу, какой именно IP-адрес получает по dhcp компьютер, если этому адресу соответствует правильное имя в DNS. Я так полагаю, акцент здесь следует сделать не на DNS, а на сохранении DHCP-сервером прежнего адреса при переключении интерфейсов. Поскольку в противном случае — если такие переключения ведут к смене адреса — получим разрыв установленных соединений. (Не критично для Web, но вот к примеру SSH-туннели у меня работают месяцами.) Упомянутый выше bonding (который, по-видимому, реализуется и в варианте с Dnsmasq?) так же означает, что при падении одного из интерфейсов, установленные соединения автоматически будут «перенаправлены» на другой. Наконец, динамическое обновление DNS, конечно, удобно; но вот умеет ли Dnsmasq динамическое обновление Iptables? PS. Да, ISC DHCP и BIND также вполне способны к DDNS-взаимодействию. -- FSF associate member #7257 np. Фейерверк — Гражданская Оборона … 230E 334A
Re: настройка сетевых интерфейсов
On 2015.06.06 at 11:30:51 +, Ivan Shmakov wrote: Я так полагаю, акцент здесь следует сделать не на DNS, а на сохранении DHCP-сервером прежнего адреса при переключении интерфейсов. Поскольку в противном случае — если такие переключения ведут к смене адреса — получим разрыв установленных соединений. (Не критично для Web, но вот к примеру SSH-туннели у меня работают месяцами.) Я стараюсь так не делать. Поскольку (судя по наличию двух интерфейсов) речь идет о ноутбуке, то запросто на следующий день придется выходить в интернет из какого-нибудь кафе или через телефон. И IP все равно поменяется. Собственно, поэтому я сейчас и не забочусь о том, чтобы в домашней сети ноутбуки получали фиксированный адрес - в них все равно все заточено, чтобы не было проблем при смене адреса, а для того чтобы удобно на них ходить по ssh достаточно DNS. Упомянутый выше bonding (который, по-видимому, реализуется и в варианте с Dnsmasq?) так же означает, что при падении одного из интерфейсов, установленные соединения автоматически будут «перенаправлены» на другой. Наконец, динамическое обновление DNS, конечно, удобно; но вот умеет ли Dnsmasq динамическое обновление Iptables? А зачем? Все мобильные клиенты в локальной сети у меня получают одинаковые настройки файрволла. Опять же по той причине, что завтра им придется работать из кафе, без прикрытия файрволлом моего роутера. Поэтому они должны быть самодостаточны. PS. Да, ISC DHCP и BIND также вполне способны к DDNS-взаимодействию. Но там это не слишком удобно настраивается. Там прописать секцию на client identifier удобнее. А у dnsmasq неудобно наоборот на identifier завязываться. Хотя я использовал эту конструкцию и там, для того, чтобы обеспечить одно и то же DNS-имя и при подключении по локальной сети, и при подключении извне через openvpn. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606122733.ga1...@wagner.pp.ru
Re: Настройка сетевых интерфейсов
В Fri, 05 Jun 2015 21:11:27 +0300 Илья mir...@yandex.ru пишет: Добрый вечер! В моем девайсе два интерфейса eth0 (static) и иногда wlan0 (dhcp). Настраиваю в /etc/network/interfaces. Подскажите существует ли простая возможность (без написания скриптов) настроить их таким образом: 1) если подключен eth0 то ему даем адрес , предположим 192.168.1.1 2) если eth0 не подключен, но подключен wlan0 даем этот адрес 192.168.1.1 3) если оба включены до eth0 даем этот адрес, а второму любой. Смысл задачки в том, что девайс должен быть доступен в сети по одному и тому же IP адресу. Идеально бы было, если при выдергивании кабеля wlan брал себе этот адрес. Лично я это всегда делал следующим образом: 1. Все интерфейсы настраивал как dhcp. 2. В конфигурационном файле dhclient включал send-client-identifier и устанавливал этот самый client-identifier равный hostname компьютера. 3. После этого единственным местом, где настраивается соответствие становится конфигурация dhcp-сервера, где указывается что вот этому client identifier всегда выдавать вот этот адрес. Если в качестве DHCP-сервера используется debian с ISC DHCPD это очень просто. При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Последнее время я так делать перестал, потому что в качестве dhcp-сервера стал использовать роутер с dnsmasq. А dnsmasq умеет поддерживать локальную DNS зону, в которую прописывает hostname присланные ему в dhcp-запросах. И мне в общем-то пофигу, какой именно IP-адрес получает по dhcp компьютер, если этому адресу соответствует правильное имя в DNS. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606125035.6c75d...@wagner.wagner.home
RE: Настройка сетевых интерфейсов
Какую задачу Вы хотите решить, когда назначаете статический адрес интерфейса? С уважением, Волков Сергей ---Исходное сообщение--- От: yuri.nefe...@gmail.com Отпр.: 06.06.2015, 09.20 Кому: debian-russian@lists.debian.org Тема: Re: Настройка сетевых интерфейсов On Fri, 5 Jun 2015, Илья wrote: Добрый вечер! В моем девайсе два интерфейса eth0 (static) и иногда wlan0 (dhcp). Настраиваю в /etc/network/interfaces. Подскажите существует ли простая возможность (без написания скриптов) настроить их таким образом: 1) если подключен eth0 то ему даем адрес , предположим 192.168.1.1 2) если eth0 не подключен, но подключен wlan0 даем этот адрес 192.168.1.1 3) если оба включены до eth0 даем этот адрес, а второму любой. Смысл задачки в том, что девайс должен быть доступен в сети по одному и тому же IP адресу. Идеально бы было, если при выдергивании кабеля wlan брал себе этот адрес. На мой взгляд, udev здесь не работает. Выдергивание кабеля или выключение wifi точки доступа - это разрывы связи, а не изменение в конфигурации устройств. Посмотрите пакет ifplugd. Не уверен, что все ваши запросы он может удовлетворить. Документацию же читать и править настройки точно придется. Если wlan0 настраивается по dhcp, то настройка выделяемого адреса - дело сервера dhcp. Может быть проще будет оба интерфейса конфигурировать по dhcp? Ю. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/xmgqbtnt4kmy.34nxn...@smtp.gmail.com
Re: Настройка сетевых интерфейсов
On Sat, Jun 06, 2015 at 12:50:35PM +0300, Victor Wagner wrote: При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Нет, не получается. В лучшем случае выходит асимметричная маршрутизация. Bonding требует дополнительного мастер-интерфейса и явного подключения к бонду дочерних, а маршрут должен быть проложен через мастер. Здесь правильно прозвучал вопрос о том, какую задачу хочется решить. В любом случае ifplugd является универсальным средством, хотя в ряде случаев можно обойтись без него. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606123924.ga8...@sie.protva.ru
Re: настройка сетевых интерфейсов
Eugene Berdnikov b...@protva.ru writes: On Sat, Jun 06, 2015 at 12:50:35PM +0300, Victor Wagner wrote: При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Нет, не получается. Действительно. В лучшем случае выходит асимметричная маршрутизация. Разве? Предполагая типовой сценарий — WLAN и Ethernet образуют одну сеть (IP, MAC; IOW, соеденены в режиме «моста») — узел будет использовать, «без предпочтения», любой из интерфейсов для связи в пределах этой сети. С другой стороны, удаленные узлы также смогут использовать для связи с данным любой из его MAC-адресов — или, что то же, — интерфейсов. Впрочем, я не уверен, что умение отслеживать несколько MAC для одного IP-адреса регламентировано соответствующими RFC. […] -- FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
Re: настройка сетевых интерфейсов
Ivan Shmakov - debian-russian@lists.debian.org @ Sat, 06 Jun 2015 13:37:38 +: Eugene Berdnikov b...@protva.ru writes: On Sat, Jun 06, 2015 at 12:50:35PM +0300, Victor Wagner wrote: При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Нет, не получается. ISДействительно. В лучшем случае выходит асимметричная маршрутизация. ISРазве? Предполагая типовой сценарий — WLAN и Ethernet образуют ISодну сеть (IP, MAC; IOW, соеденены в режиме «моста») — узел ISбудет использовать, «без предпочтения», любой из интерфейсов для ISсвязи в пределах этой сети. ISС другой стороны, удаленные узлы также смогут использовать для ISсвязи с данным любой из его MAC-адресов — или, что то же, — ISинтерфейсов. В результате возможна ситуация, когда пинг или DNS-запрос уходят с одного интерфейса, а ответ приходит на другой. Или наоборот, запрос приходит на один, а уходит с другого. В первом случае мы здорово рискуем налететь на включенное как бы не по умолчанию net.ipv4.conf.all.rp_filter=1, и получить дропнутый ответ на свой запрос. Следует ли ожидать проблем во втором случае, не уверен. На шибко умном роутере, у которого наши два интерфейса тоже будут воткнуты в два разных, можно налететь на то же самое. ISВпрочем, я не уверен, что умение отслеживать несколько MAC для ISодного IP-адреса регламентировано соответствующими RFC. AFAIR не регламентировано. Будет использоваться последний известный. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbf0rjtv@silver.lasgalen.net
Re: настройка сетевых интерфейсов
On Sat, Jun 06, 2015 at 01:37:38PM +, Ivan Shmakov wrote: Eugene Berdnikov b...@protva.ru writes: On Sat, Jun 06, 2015 at 12:50:35PM +0300, Victor Wagner wrote: При этом даже если eth0 и wlan0 подключены одновременно, они получают один и тот же ip и получается bonding. Нет, не получается. Действительно. В лучшем случае выходит асимметричная маршрутизация. Разве? Предполагая типовой сценарий ??? WLAN и Ethernet образуют одну сеть (IP, MAC; IOW, соеденены в режиме ??моста??) ??? узел будет использовать, ??без предпочтения??, любой из интерфейсов для связи в пределах этой сети. Во-первых, когда два интерфейса включаешь в одну сеть, ни бондинг, ни мост (bridge) автомагически не создаются. Хотя бы потому, что ядру просто неоткуда узнать, что два интерфейса находятся в одной сети. :) Во-вторых, сомневающиеся могут просто поднять пару одинаковых адресов на разных интерфейсах и заглянуть в таблицу маршрутизации. Сюрприз: там не будет ни бондинга, ни моста, ни даже балансировки между интерфейсами. Один из интерфейсов тупо встанет первым. Проверяется по ip route get. В-третьих, что значит без предпочтения? Узел, отправляющий пакеты, не может не иметь предпочтений, потому что он должен принимать решение о машрутизации. Поэтому ему нужно выбрать какую-то стратегию: или берём лишь первый интерфейс в таблице, или используем оба, но тогда нужно выбрать и режим балансировки: либо round robin, либо псевдослучайно, либо по младшим октетам mac'a и так далее. Никакая стратегия может быть ровно одна: дропнуть пакет. Впрочем, я не уверен, что умение отслеживать несколько MAC для одного IP-адреса регламентировано соответствующими RFC. Если хранить несколько mac'ов для одного ip, то при отсылке пакета на этот ip нужно точно так же принять решение о выборе mac'а получателя, т.е. мы опять возвращаемся к необходимости ввести какую-то стратегию балансировки. Мне неизвестны ОС, которые были бы этим озабочены. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606151533.ga10...@sie.protva.ru
Re: настройка сетевых интерфейсов
On Sat, Jun 06, 2015 at 10:32:49PM +0300, Vasiliy P. Melnik wrote: https://wiki.debian.org/ru/NetworkConfiguration auto eth0 iface eth0 inet static address 192.168.0.7 netmask 255.255.255.0 gateway 192.168.0.254 auto wlan0 iface wlan0 inet static address 192.168.0.7 netmask 255.255.255.0 gateway 192.168.0.254 up ifconfig eth0 down down ifconfig eth0 up Изначально товарищу хотелось использовать eth0 если он подключен, а здесь наоборот, приоритет имеет wlan0. Очевидно, выдёргивание кабеля из eth0 никак не отслеживается. Насчёт ассоциации с AP непонятно: этот кусок конфига либо неполон, либо неработоспособен. Кроме того, такое назначение статического адреса интерфейсу wifi (без использования dhcp) может вызвать проблемы с оборудованием некоторых производителей, в частности, с AP от Cisco. Насколько я могу судить (по результатам экспериментов), циски хотят, чтобы клиент присылал пакеты с тем src_mac, который он передал в dhcp-request'e. А пока запросов dhcp нет, клиент блокирован, даже arp не ходит. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606211531.gd10...@sie.protva.ru
Re: настройка сетевых интерфейсов
Artem Chuprina r...@lasgalen.net writes: […] AC Были сервера в офисе. Было два провайдера, основной и резервный. AC Адреса, правда, разные (failover средствами DNS), но существенно не AC это. Существенно то, что входящий TCP на резервный канал работал AC на ура, а вот UDP не везло, потому что ответ на TCP идет с того же AC интерфейса, поскольку сеанс, а ответ на UDP — по общим правилам AC маршрутизации, т. е. пока (по мнению сервера) основной жив — через AC основной. Это решаемо созданием нескольких таблиц маршрутизации и определением правил выбора нужной через # ip rule. AC И я подозреваю, что дополнительный эффект этой ситуации будет в AC том, что даже в случае одного адреса на двух интерфейсах TCP-сеанс AC будет рваться, если упадет тот интерфейс, через который он был AC установлен. Хотя это надо проверять, может быть, и нет. С чего бы? Разумеется, наличие чего бы то ни было «отслеживающего соединения» между узлами — вроде маршрутизатора с NAT — существенно меняет ситуацию. -- FSF associate member #7257 np. Das Modell — Rammstein … 3013 B6A0 230E 334A
Re: настройка сетевых интерфейсов
Ivan Shmakov - debian-russian@lists.debian.org @ Sat, 06 Jun 2015 18:45:27 +: AC Были сервера в офисе. Было два провайдера, основной и резервный. AC Адреса, правда, разные (failover средствами DNS), но существенно не AC это. Существенно то, что входящий TCP на резервный канал работал AC на ура, а вот UDP не везло, потому что ответ на TCP идет с того же AC интерфейса, поскольку сеанс, а ответ на UDP — по общим правилам AC маршрутизации, т. е. пока (по мнению сервера) основной жив — через AC основной. ISЭто решаемо созданием нескольких таблиц маршрутизации и ISопределением правил выбора нужной через # ip rule. Ну, да. Я это к тому, что само не работало. AC И я подозреваю, что дополнительный эффект этой ситуации будет в AC том, что даже в случае одного адреса на двух интерфейсах TCP-сеанс AC будет рваться, если упадет тот интерфейс, через который он был AC установлен. Хотя это надо проверять, может быть, и нет. ISС чего бы? Мне так вот сходу не очевидно, по каким именно параметрам ядро выбирает, куда отправлять обратный пакет в TCP-соединении. Если только по адресам, то не упадет, а если учитывает интерфейс... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw0cr692@silver.lasgalen.net
Re: настройка сетевых интерфейсов
https://wiki.debian.org/ru/NetworkConfiguration auto eth0 iface eth0 inet static address 192.168.0.7 netmask 255.255.255.0 gateway 192.168.0.254 auto wlan0 iface wlan0 inet static address 192.168.0.7 netmask 255.255.255.0 gateway 192.168.0.254 up ifconfig eth0 down down ifconfig eth0 up 6 июня 2015 г., 21:18 пользователь Eugene Berdnikov b...@protva.ru написал: On Sat, Jun 06, 2015 at 05:42:55PM +, Ivan Shmakov wrote: Так или иначе, исходный вопрос ??? как я его понял ??? был в том, как обеспечить failover. Использование одного адреса на нескольких интерфейсах эту задачу как будто бы решает? Как бы нет, :) потому что не обеспечивает изменение маршрута исходящих пакетов при изменении состояния линка из подключен/ассоциирован в отключен/деассоциирован. Выдёргивание изернетовского кабеля ни адрес, ни маршрут не меняет. Кроме того, инициатор треда хотел, чтобы всегда использовался интерфейс с наибольшей пропускной способностью. Повторю, что ifplugd даёт возможность решить задачу в любых мыслимых вариантах. Но ему нужно написать обвязку. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606181831.gb10...@sie.protva.ru
Re: настройка сетевых интерфейсов
Eugene Berdnikov b...@protva.ru writes: On Sat, Jun 06, 2015 at 01:37:38PM +, Ivan Shmakov wrote: Eugene Berdnikov b...@protva.ru writes: […] В лучшем случае выходит асимметричная маршрутизация. Разве? Предполагая типовой сценарий — WLAN и Ethernet образуют одну сеть (IP, MAC; IOW, соеденены в режиме «моста») — узел будет использовать, «без предпочтения», любой из интерфейсов для связи в пределах этой сети. Во-первых, когда два интерфейса включаешь в одну сеть, ни бондинг, ни мост (bridge) автомагически не создаются. Хотя бы потому, что ядру просто неоткуда узнать, что два интерфейса находятся в одной сети. :) Строго говоря, у ядра /есть/ необходимая информация — префиксы сетей легко обнаруживаются в выводе $ ip addr. Во-вторых, сомневающиеся могут просто поднять пару одинаковых адресов на разных интерфейсах и заглянуть в таблицу маршрутизации. Сюрприз: там не будет ни бондинга, ни моста, ни даже балансировки между интерфейсами. Один из интерфейсов тупо встанет первым. Проверяется по «ip route get». В-третьих, что значит «без предпочтения»? Узел, отправляющий пакеты, не может «не иметь предпочтений», потому что он должен принимать решение о машрутизации. О пересылке. Поэтому ему нужно выбрать какую-то стратегию: или берём лишь первый интерфейс в таблице, или используем оба, но тогда нужно выбрать и режим балансировки: либо round robin, либо псевдослучайно, либо по младшим октетам mac'a и так далее. По меньшей мере в случае IPv6, AIUI, приложение может указать интерфейс для отправки явно. Даже в случае совпадение адресов (сетей) различных интерфейсов. «Никакая» стратегия может быть ровно одна: дропнуть пакет. […] ACK; благодарю за разъяснения. Так или иначе, исходный вопрос — как я его понял — был в том, как обеспечить failover. Использование одного адреса на нескольких интерфейсах эту задачу как будто бы решает? -- FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
Re: настройка сетевых интерфейсов
On Sat, Jun 06, 2015 at 05:42:55PM +, Ivan Shmakov wrote: Так или иначе, исходный вопрос ??? как я его понял ??? был в том, как обеспечить failover. Использование одного адреса на нескольких интерфейсах эту задачу как будто бы решает? Как бы нет, :) потому что не обеспечивает изменение маршрута исходящих пакетов при изменении состояния линка из подключен/ассоциирован в отключен/деассоциирован. Выдёргивание изернетовского кабеля ни адрес, ни маршрут не меняет. Кроме того, инициатор треда хотел, чтобы всегда использовался интерфейс с наибольшей пропускной способностью. Повторю, что ifplugd даёт возможность решить задачу в любых мыслимых вариантах. Но ему нужно написать обвязку. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150606181831.gb10...@sie.protva.ru
Re: настройка сетевых интерфейсов
Ivan Shmakov - debian-russian@lists.debian.org @ Sat, 06 Jun 2015 17:42:55 +: ISПо меньшей мере в случае IPv6, AIUI, приложение может указать ISинтерфейс для отправки явно. Даже в случае совпадение адресов IS(сетей) различных интерфейсов. Может. Но делают это полтора приложения - ping да traceroute. «Никакая» стратегия может быть ровно одна: дропнуть пакет. IS […] ISACK; благодарю за разъяснения. ISТак или иначе, исходный вопрос — как я его понял — был в том, ISкак обеспечить failover. Использование одного адреса на ISнескольких интерфейсах эту задачу как будто бы решает? Как будто нет. Если у тебя упала точка доступа, но не до такой степени, чтобы машинка это осознала сама (либо адрес статический, либо DHCP lease еще не истекла), то ядро будет, не моргнув глазом, пытаться отправить пакеты через этот интерфейс. Поэтому до него надо как-то оперативно доносить, что данный линк _практически_ сдох, и надо маршрутизировать через другой. Кроме того. У меня в свое время был, гм, опыт. Были сервера в офисе. Было два провайдера, основной и резервный. Адреса, правда, разные (failover средствами DNS), но существенно не это. Существенно то, что входящий TCP на резервный канал работал на ура, а вот UDP не везло, потому что ответ на TCP идет с того же интерфейса, поскольку сеанс, а ответ на UDP - по общим правилам маршрутизации, т.е. пока (по мнению сервера) основной жив - через основной. И я подозреваю, что дополнительный эффект этой ситуации будет в том, что даже в случае одного адреса на двух интерфейсах TCP-сеанс будет рваться, если упадет тот интерфейс, через который он был установлен. Хотя это надо проверять, может быть, и нет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3por8q0@silver.lasgalen.net
Re: Настройка сетевых интерфейсов
скрипты не сложные - в удеве такого точно нет, а больше особо за этим смотреть некому. Да и в удеве все равно скрипты должны быть написаны. По логике я бы сделал, если не работает eth0 - поднять wlan0, и соотвественно погасить wlan0, если появился eth0 В действительности элементарщина https://wiki.debian.org/ru/NetworkConfiguration 5 июня 2015 г., 21:11 пользователь Илья mir...@yandex.ru написал: Добрый вечер! В моем девайсе два интерфейса eth0 (static) и иногда wlan0 (dhcp). Настраиваю в /etc/network/interfaces. Подскажите существует ли простая возможность (без написания скриптов) настроить их таким образом: 1) если подключен eth0 то ему даем адрес , предположим 192.168.1.1 2) если eth0 не подключен, но подключен wlan0 даем этот адрес 192.168.1.1 3) если оба включены до eth0 даем этот адрес, а второму любой. Смысл задачки в том, что девайс должен быть доступен в сети по одному и тому же IP адресу. Идеально бы было, если при выдергивании кабеля wlan брал себе этот адрес. -- С уважением, Илья. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5891621433527...@web4h.yandex.ru
Re: Настройка сетевых интерфейсов
On Fri, 5 Jun 2015, Илья wrote: Добрый вечер! В моем девайсе два интерфейса eth0 (static) и иногда wlan0 (dhcp). Настраиваю в /etc/network/interfaces. Подскажите существует ли простая возможность (без написания скриптов) настроить их таким образом: 1) если подключен eth0 то ему даем адрес , предположим 192.168.1.1 2) если eth0 не подключен, но подключен wlan0 даем этот адрес 192.168.1.1 3) если оба включены до eth0 даем этот адрес, а второму любой. Смысл задачки в том, что девайс должен быть доступен в сети по одному и тому же IP адресу. Идеально бы было, если при выдергивании кабеля wlan брал себе этот адрес. На мой взгляд, udev здесь не работает. Выдергивание кабеля или выключение wifi точки доступа - это разрывы связи, а не изменение в конфигурации устройств. Посмотрите пакет ifplugd. Не уверен, что все ваши запросы он может удовлетворить. Документацию же читать и править настройки точно придется. Если wlan0 настраивается по dhcp, то настройка выделяемого адреса - дело сервера dhcp. Может быть проще будет оба интерфейса конфигурировать по dhcp? Ю.
Re: Настройка сетевых интерфейсов. Роути нг.
On Wed, 7 Jul 2004 11:36:05 +0300 DZ == Dmitry Zabolotny [EMAIL PROTECTED] wrote: DZ DZ 1. Как правильно и в каких скриптах прописывать настройки сетевых DZ интерфейсов если использовать iproute? man 5 interfaces DZ 2. Подскажите как настроить роутинг в таком случае: DZЕсть падающая выделенка(eth0), локальная сеть(eth1) и диал-ап. Когда DZвыделенка есть(как проверить?) роутинг на eth0. При падении выделенки DZзапускается дозвонка. После появления выделенки опять роутинг на eth0? Для переключения routing'а лучше всего завести routing daemon'а, скажем, zebra или routed. -- Alexander Kotelnikov Saint-Petersburg, Russia
Re: Настройка сетевых интерфейсов. Роутинг.
On Wed, 7 Jul 2004 22:29:15 +0400 ilya voronin [EMAIL PROTECTED] wrote: On Wed, Jul 07, 2004 at 11:36:05AM +0300, Dmitry Zabolotny wrote: 2. Подскажите как настроить роутинг в таком случае: Есть падающая выделенка(eth0), локальная сеть(eth1) и диал-ап. Когда выделенка есть(как проверить?) роутинг на eth0. При падении выделенки запускается дозвонка. После появления выделенки опять роутинг на eth0? Проверять доступность какого-нибудь хоста. (ping?). Простой скриптик в кроне. Как только хост становится недоступным: удалять маршрут по умолчанию (ведующий куда-то через eth0). В ppp скриптах есть переопределение маршрута по умолчанию. Подняли ppp -- дефолт по модему Опустили ppp -- вернули старый маршрут. Regards, Yuri Kozlov
Re: Настройка сетевых интерфейсов. Роутинг.
On Wed, Jul 07, 2004 at 11:36:05AM +0300, Dmitry Zabolotny wrote:
1. Как правильно и в каких скриптах прописывать настройки сетевых
интерфейсов если использовать iproute?
в /etc/network/interfaces.
статические маршруты можно прописать так (последняя строчка):
auto eth2
iface eth2 inet static
address 192.168.48.140
netmask 255.255.255.0
network 192.168.48.0
broadcast 192.168.48.255
up ip route add 192.168.49.0/24 via 192.168.48.1
2. Подскажите как настроить роутинг в таком случае:
Есть падающая выделенка(eth0), локальная сеть(eth1) и диал-ап. Когда
выделенка есть(как проверить?) роутинг на eth0. При падении выделенки
запускается дозвонка. После появления выделенки опять роутинг на eth0?
Проверять доступность какого-нибудь хоста. (ping?).
Как только хост становится недоступным:
удалять маршрут по умолчанию (ведующий куда-то через eth0).
# ip route del default
добавлять маршрут на машину, за доступностью которой мы наблюдаем:
# ip route add machine.somedomain.com via ${default_gateway}
звонить dial-up провайдеру. (и соответственно default route туда)
переодически проверять доступность 'machine.somedomain.com', - как
только становится доступным - обрывать соединение, удалять маршрут
на машину 'machine.somedomain.com', восстанавливать default route
# ip route add default via ${default_gateway}
Хотя можно маршрут на 'machine.somedomain.com' вообще не трогать -
прописать один раз и всё. (см ответ на первый вопрос - как).
--
ilya voronin [EMAIL PROTECTED]
