Вышел dhcpcd v4.0.0

Это означает, что теперь без всяких плясок и рихтовок линукс-хост будет спокойно получать статические бесклассовые маршруты от dhcp-сервера? Если так, то это большой шаг вперёд, а то в домашних сетях на просторах СНГ многие провайдеры строят маршрутизируемые городские сети, чтобы все локальные сервисы и сервера РРTP находились за коммутатором L3, а также этот(эти) коммутатор(ы) делят большую сеть на более мелкие. Для того, чтобы всё это работало не через получение маршрута 0.0.0.0, нужно, чтобы автоматом получались статические бесклассовые маршруты, что из коробки работало лишь в винде и во фре 7.0. Теперь, наверное, будет работать и в линуксах из коробки.

Интересно только одно: маршруты по dhcp получать оно научилось? Остальное вроде как устраивает.

>> Это означает, что теперь без всяких плясок и рихтовок линукс-хост будет спокойно получать статические бесклассовые маршруты от dhcp-сервера? Если так, то это большой шаг вперёд, а то в домашних сетях на просторах СНГ многие провайдеры строят маршрутизируемые городские сети, чтобы все локальные сервисы и сервера РРTP находились за коммутатором L3, а также этот(эти) коммутатор(ы) делят большую сеть на более мелкие. Для того, чтобы всё это работало не через получение маршрута 0.0.0.0, нужно, чтобы автоматом получались статические бесклассовые маршруты, что из коробки работало лишь в винде и во фре 7.0. Теперь, наверное, будет работать и в линуксах из коробки.

Эти самые classless static routes dhcpcd умел ещё чёрт знает когда. Проблема в том, что в RFC для них один код опции, а в венде - другой. При том что формат пакета там один и тот же. *Вендовые* classless static routes dhcpcd умеет получать начиная с версии 3.2.0 при включенной опции -S.

>Эти самые classless static routes dhcpcd умел ещё чёрт знает когда. Проблема в том, что в RFC для них один код опции, а в венде - другой. При том что формат пакета там один и тот же. *Вендовые* classless static routes dhcpcd умеет получать начиная с версии 3.2.0 при включенной опции -S.

Да!Да!Да! У меня в dhcp-сервере для каждого сабнета стоят коды и виндовые и невиндовые одновременно. Но я не мог написать красивое простое руководство для своих пользователей, как с помощью линукс легко и просто работать в нашей сети. Чтоб юзеры не лазили в редактирование файлов (они же не админы), а просто в менюшках всё сделали и получили результат. Так вот теперь это становится реальным! Теперь остаётся следить, в какой дистрибутив новая версия этого клиента войдёт из коробки, чтоб всё это работало само собой...

Хех.. http://bugs.gentoo.org/show_bug.cgi?id=235643

Да прям празднег какой-то сегодня, еще и vlc-0.9 вышел)

>> У меня в dhcp-сервере для каждого сабнета стоят коды и виндовые и невиндовые одновременно. Но я не мог написать красивое простое руководство для своих пользователей, как с помощью линукс легко и просто работать в нашей сети. Чтоб юзеры не лазили в редактирование файлов (они же не админы), а просто в менюшках всё сделали и получили результат. Так вот теперь это становится реальным!

Хм... Невендовые CSR он всегда нормально получал.

>> Хех.. http://bugs.gentoo.org/show_bug.cgi?id=235643

ЫЫЫЫЫ! Свежый рилиз: http://roy.marples.name/dhcpcd/dhcpcd-4.0.1.tar.bz2 ! Кто запостит новость? =)

Т.е. уже всего через пару релизов можно будет апдейтить 2.0.5?

>У меня в dhcp-сервере для каждого сабнета стоят коды и виндовые и невиндовые одновременно.

Никогда не понимал провайдеров и сетевиков, у которых клиентам нужно прописывать статические маршруты.

ИМХО маршруты нужно прописывать на шлюзе, который должен быть при необходимости ещё и VPN-сервером, работающим в связке с единым радиус-сервером и биллингом.

В нашей говнолокалке, например, статические маршруты нужны, когда народ у себя включает vpn и из-за этого меняется дефолт и, соответственно, для него отваливаются другие подсети.

>Никогда не понимал провайдеров и сетевиков, у которых клиентам нужно прописывать статические маршруты.

>ИМХО маршруты нужно прописывать на шлюзе, который должен быть при необходимости ещё и VPN-сервером, работающим в связке с единым радиус-сервером и биллингом.

Немного это оффтоп, но вопрос понятен. Если сеть большая (10.0.0.0/8), её удобно побить на вланы (и подсети)по какому-то территориальному (сами выбираете себе какому) признаку, чтоб уменьшить бродкасты (для уменьшения бродкастов также из dhcp передаём тип нетбиос-узла H-node и указываем WINS). Все вланы должны роутиться через L3-свитч(и), которые не могут сразу быть РРТР-серверами. Проще сделать ещё один влан для серверов и роутеров доступа в интернет, и в нём разместить необходимое количество РРТР-серверов. При этом ай-пи этих серверов будут одинаковыми для всех юзеров независимо от того, из какого влана юзеры к нему коннектятся. На самом деле у меня всем юзерам передаётся лишь один статик -- 10.0.0.0/8, у которого шлюзом в каждом влане является ай-пи L3-свитча, который смотрит в этот влан. А уже когда юзер коннектится по РРТР -- тогда он получает 0.0.0.0/0 в Интернет.

>>Эти самые classless static routes dhcpcd умел ещё чёрт знает когда. Проблема в том, что в RFC для них один код опции, а в венде - другой. При том что формат пакета там один и тот же. *Вендовые* classless static routes dhcpcd умеет получать начиная с версии 3.2.0 при включенной опции -S.

>Да!Да!Да! У меня в dhcp-сервере для каждого сабнета стоят коды и виндовые и невиндовые одновременно. Но я не мог написать красивое простое руководство для своих пользователей, как с помощью линукс легко и просто работать в нашей сети. Чтоб юзеры не лазили в редактирование файлов (они же не админы), а просто в менюшках всё сделали и получили результат. Так вот теперь это становится реальным! Теперь остаётся следить, в какой дистрибутив новая версия этого клиента войдёт из коробки, чтоб всё это работало само собой... byteplayer (*) (25.08.2008 11:54:40)

Чему радуемся-то? ;) офтопиководы наклал в свое время на RFC, затем все наплодили сеток мимо RFC, теперь приходится всем отступать от RFC, что-бы юзеры "они же не админы" меньше капали на мозг.

Очередной RFC повержен, офтопик как всегда победил. Вот такой вот повод для веселья...

vsv

dhcpcd v4.0.0 и v4.0.1 круче барахла нет, возвернулся на dhclient

>Немного это оффтоп, но вопрос понятен. Если сеть большая (10.0.0.0/8), её удобно побить на вланы (и подсети)по какому-то территориальному (сами выбираете себе какому) признаку, чтоб уменьшить бродкасты (для уменьшения бродкастов также из dhcp передаём тип нетбиос-узла H-node и указываем WINS). Все вланы должны роутиться через L3-свитч(и), которые не могут сразу быть РРТР-серверами. Проще сделать ещё один влан для серверов и роутеров доступа в интернет, и в нём разместить необходимое количество РРТР-серверов. При этом ай-пи этих серверов будут одинаковыми для всех юзеров независимо от того, из какого влана юзеры к нему коннектятся. На самом деле у меня всем юзерам передаётся лишь один статик -- 10.0.0.0/8, у которого шлюзом в каждом влане является ай-пи L3-свитча, который смотрит в этот влан. А уже когда юзер коннектится по РРТР -- тогда он получает 0.0.0.0/0 в Интернет.

Да, необходимость выдавать статические маршруты обычно возникает в первую очередь именно из-за VPN, который сразу устанавливает маршрут по умолчанию и весь трафик, даже локальный, заруливается в туннель. В принципе можно маршрутизировать такой трафик на VPN-серверах, только это будет лишняя нагрузка на VPN-серверы. Поэтому, действительно, приходится выдавать статические маршруты. Но лично мне такие костыли всё равно не нравятся...

Зачем вообще провайдеры применяют VPN? Ответ - сэкономить белые IP, защититься от спуфинга, легко учитывать трафик большого количества пользователей на RADIUS-сервере.

В принципе всё это есть проявление недостатков существующих технологий: ограниченность адресного пространства IPv4, отсутствие защиты от спуфинга в Ethernet/IP, отсутствие подходящих средств "лёгкого" учёта трафика ("тяжёлой" альтернативой RADIUS является NetFlow).

Все задачи легко решались бы внедрением IPv6, в котором есть обязательная поддержка IPSec, и соответственно IP Accounting.

Хотя мне не нравится ни IPv6, ни IPSec всё-таки, на мой взгляд, это тот правильный путь решения сегодняшних проблем, который бы в своё время нужно было бы начать внедрять.

Однако гораздо проще (а проще ли?) обходиться костылями VPN и NAT, именно поэтому до сих пор нет практически никаких подвижек во внедрении IPv6.

Странно, у меня автоматом статические виндовые маршруты не находит :( В старом с опцией -S всё ок. Куда копать?