debian 8 vs zoneminder

2015-06-06 Thread Леонид Кальмаев
Доброго!
Кто нибудь у себя использует связку? Обновился тут до 8 версии и все
сломалось.
Поправил php.ini на предмет short_open_tag вроде заработало, но достаточно
криво..
Свежих сборок выше 1.25 почему то не появилось


Re:Настройка сетевых интерфейсов

2015-06-06 Thread Илья
Наверное, я неправильно вопрос поставил. Мне нужен всегда статический адрес 
устройства и чтобы все настраивалось в одном файле, без вызова скриптов. 
Пока ковыряю в строну bonding (я не знал как это называется), пока его 
функционал меня удовлетворяет.
Проблемы возникают с включением / отключением wlan0 интерфейса, но я думаю это 
проблема драйвера устройства:
У меня raspberry и wifi dwa-125 - а он офицально не поддерживается.



> On Fri, 5 Jun 2015, Илья wrote:

> Посмотрите пакет 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/7348531433580...@web25j.yandex.ru



Re: Настройка сетевых интерфейсов

2015-06-06 Thread Victor Wagner
В Fri, 05 Jun 2015 21:11:27 +0300
Илья  пишет:

> Добрый вечер!
> 
> В моем девайсе два интерфейса 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: Настройка сетевых интерфейсов

2015-06-06 Thread Волков Сергей
Какую задачу Вы хотите решить, когда назначаете статический адрес интерфейса?
С уважением, 
Волков Сергей

---Исходное сообщение---
От: 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: настройка сетевых интерфейсов

2015-06-06 Thread Ivan Shmakov
> Victor Wagner  writes:
> В Fri, 05 Jun 2015 21:11:27 +0300 Илья  пишет:

[…]

 >> Идеально бы было, если при выдергивании кабеля 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: настройка сетевых интерфейсов

2015-06-06 Thread Victor Wagner
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: Настройка сетевых интерфейсов

2015-06-06 Thread Eugene Berdnikov
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: настройка сетевых интерфейсов

2015-06-06 Thread Ivan Shmakov
> Eugene Berdnikov  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: настройка сетевых интерфейсов

2015-06-06 Thread Artem Chuprina
Ivan Shmakov -> debian-russian@lists.debian.org  @ Sat, 06 Jun 2015 13:37:38 
+:

 >> Eugene Berdnikov  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: настройка сетевых интерфейсов

2015-06-06 Thread Eugene Berdnikov
On Sat, Jun 06, 2015 at 01:37:38PM +, Ivan Shmakov wrote:
> > Eugene Berdnikov  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: настройка сетевых интерфейсов

2015-06-06 Thread Ivan Shmakov
> Eugene Berdnikov  writes:
> On Sat, Jun 06, 2015 at 01:37:38PM +, Ivan Shmakov wrote:
> Eugene Berdnikov  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: настройка сетевых интерфейсов

2015-06-06 Thread Eugene Berdnikov
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: настройка сетевых интерфейсов

2015-06-06 Thread Artem Chuprina
Ivan Shmakov -> debian-russian@lists.debian.org  @ Sat, 06 Jun 2015 17:42:55 
+:

 IS>По меньшей мере в случае IPv6, AIUI, приложение может указать
 IS>интерфейс для отправки явно.  Даже в случае совпадение адресов
 IS>(сетей) различных интерфейсов.

Может.  Но делают это полтора приложения - ping да traceroute.

 >> «Никакая» стратегия может быть ровно одна: дропнуть пакет.

 IS> […]

 IS>ACK; благодарю за разъяснения.

 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: настройка сетевых интерфейсов

2015-06-06 Thread Ivan Shmakov
> Artem Chuprina  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: настройка сетевых интерфейсов

2015-06-06 Thread Artem Chuprina
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: настройка сетевых интерфейсов

2015-06-06 Thread Vasiliy P. Melnik
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  написал:

> 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: настройка сетевых интерфейсов

2015-06-06 Thread Eugene Berdnikov
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: настройка сетевых интерфейсов

2015-06-06 Thread Eugene Berdnikov
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