* Re: [Sysadmins] обработка событ?
@ 2007-10-16 12:22 ` Aleksey Avdeev
0 siblings, 0 replies; 3+ messages in thread
From: Aleksey Avdeev @ 2007-10-16 12:22 UTC (permalink / raw)
To: Peter V. Saveliev; +Cc: ALT Linux sysadmin discuss
[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]
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@.
--
С уважением. Алексей.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread