Peter V. Saveliev пишет: > В сообщении от Tuesday 16 October 2007 12:59:31 вы написали: >> Peter V. Saveliev пишет: >>> ... >>> >>> В следующей сборке connexion/ncsh, которая пойдёт в Сизиф через неделю, >>> будет поддержка обработки событий на различных шинах, в частности, оно >>> сможет реагировать на события netlink (подъём/опускание интерфейсов, >>> маршрутов, правил rpdb, обработка пакетов -j ULOG и т.п.) и snmp traps >>> (v1/2c/3) (т.е. можно будет перестраивать таблицы маршрутизации, файрвол >>> или управлять процессами в ответ на мессаги от сетевых девайсов). >>> >>> Отсюда вопрос. Если у кого-н.ть есть use cases, в которых эта >>> функциональность может быть полезна -- самое время поделиться. Потому как >>> хоть я и стараюсь делать максимально обощённый framework, но могу не >>> учесть какой-либо неизвестной мне специфики. >> Классика жанра: подключение к двум провайдерам, один из которых >> Corbina (т. е. pptp, через vpn сервер доступный _только_ через >> маршрутизатор локалки)... > > > А можешь расписать схему в ascii-art с пояснением, какая часть должна > реагировать на какое событие? > > Спасибо. Схема взаимосвязи интерфейсов: HE -- хост система |\ | lanbr -- бридж для квартирной локалки | |\ | \ lan -- eth квартирной локалки | \ | veth1040.0 -- veth для VE с DHCP |\ | wp -- eth для ADSL модема (частная сеть: NAT/DNAT подняты на модеме), | резервный канал. |\ | venet0 -- для VE не требующих veth (2 DNS`а, ntp и пр.) \ wanbr -- бридж для работы с Сorbin`ой маршрут по умолчанию (основной | канал) \ veth1020.0 -- veth для VE с Crbin`овским шлюзом. Всё что ниже -- в | данном VE VE | |\ | | dmz -- veth со стороны VE |\ | corblan -- eth, проброшенный в VE. Обеспечивает доступ к Corbin`овской | локалке (частная сеть) и VPN серверу в частности (Внимание: IP | VPN сервера белый, и данной сети _не_принадлежит_). \ ppp0 -- PPTP тунель во внешний мир (основной канал). Маршрут по умолчанию. Дополнения, косающиеся Corbina: 1. Штатный способ получения IP -- DHCP. Возможность взять фисированный, внутриситевой, IP есть, но их диапазон в каждом сегменте ограничен (зарезирвированы для серверов предоставляющих районнык ресурсы). 2. Доступ к локальным ресурсам (если он вообще есть) -- _только_ через маршрутизатор района (в каждом районе разный, DHCP отдаёт его в качестве шлюза по умолчанию). Доступ к локальным ресурсам не тарифицируется и скорость не ограничивается. 3. Часть локальных ресурсов (похоже, что все ресурсы принадлежащие самой Corbin`е) имеют внешний IP, и доступны как через районный маршрутизатор, так и через внешний канал (VPN). Но при доступе через VPN они считаются внешними (скорость доступа и тарификация в соответствии с тарифом), а при доступе через локалку (районный маршрутизатор) -- ограничений и тарификации нет 4. VPN сервера (их сильно больше одного) имеют внешний IP и доступны _только_ через районный маршрутизатор. Если при установке тунеля маршрут доступа к VPN серверу будет переписан -- получим нерабочий тунель. Что сделано сейчас (средствами etcnet): 1. Ресурсы, расположенные на хосте, доступны через обоих провайдеров. 2. К ресурсам доступным только через одного провайдера -- прописаны статические маршруты. 3. default -- Corbina Что хотелось бы иметь в конечном итоге: 1. Если доступны оба канала -- делим трафик между ними. 2. Если отвалился один их каналов -- default на оставшийся. 3. Если отвалился VPN тунель -- default на wp, но маршруты к локальным ресурсам Corbina должны действовать... 4. Приоритизация трафика. PS: Отправляю копию в sysadmins@. -- С уважением. Алексей.