После трёх с половиной лет разработки организация ISC (Internet Systems Consortium) опубликовала (https://lists.isc.org/pipermail/dhcp-announce/2014-February/...) новый значительный выпуск пакета DHCP 4.3.0 (https://www.isc.org/downloads/dhcp/430/) с реализацией сервера, транзитного релея и клиента для динамической настройки параметров сетевого соединения хоста с использованием протокола DHCP. Код проекта распространяется под лицензией BSD.
Основным направлением развития DHCP 4.3.0 стало обеспечение полнофункциональной поддержки IPv6 - большинство возможностей DHCPv4 теперь доступны и при использовании DHCPv6. В частности, для DHCPv6 обеспечена (https://kb.isc.org/article/AA-01093/201/Adding-class-support...) поддержка классов (class "имя" {...}), что позволяет использовать привычный для пользователей DHCPv4 стиль оформления настроек. Для DHCPv6 также обеспечена поддержка (https://kb.isc.org/article/AA-01094/201/Adding-support-for-o...) обработчиков "on commit", "on expiry" и "on release", улучшены возможности по ведению журнала назначения адресов, добавлены выражения (https://kb.isc.org/article/AA-01096/201/DHCPv6-support-for-r...) v6relay и v6relopt для доступа к опциям из DHCPv6-релея.
Из ограничений в поддержке IPv6 отмечается возможности использования только одного идентификатора в опции "host-identifier", невозможность одновременного использования клиентом и сервером DHCPv4 и DHCPv6 (для IPv4 и IPv6 нужно запускать раздельные экземпляры), поддержка указания в статусных сообщениях только текста на английском языке, ограниченное число поддерживаемых платформ (Solaris, Linux, FreeBSD, NetBSD и OpenBSD).Другие улучшения (https://kb.isc.org/category/201/0/10/Software-Products/DHCP/.../):
- Поддержка (https://kb.isc.org/article/AA-01091/201/ISC-DHCP-support-for...) стандартной реализации динамического DNS-сервер (DDNS), соответствующего актуальным требованиям RFC 4701, 4702, 4703 и 4361 и предоставляющего возможность совместного использования записей DDNS между клиентами DHCPv4 и DHCPv6. Поддержка стандартного режима включается опцией "ddns-update-style standard". Возможность использования режима "ddns-update-style interim" сохранена, а реализация режима "ddns-update-style ad-hoc" удалена, так как он был объявлен устаревшим ещё в выпуске 4.2;- Возможность (https://kb.isc.org/article/AA-01092/201/OMAPI-support-for-cl...) динамического добавления и удаления классов и субклассов при помощи OMAPI (http://ipamworldwide.com/dhcp-api.html) (Object Management Application Programming Interface) без необходимости изменения файла конфигурации и перезапуска сервера;
- Возвращена поддержка использования DDNS без определения зоны. Указанная возможность присутствовала в ветке 4.1, но была убрана в 4.2 из-за добавления новой асинхронной реализации DDNS;- Добавлена опция "dont-use-fsync yes" для отключения вызова fsync(), что позволяет повысить производительность серверов с большим числом операций обновления БД, но ценой этому является повышение вероятности нарушения целостности хранилища в случае сбоя;
- Добавлены опции "ddns-local-address4" и "ddns-local-address6" для определения адреса с которого следует отправлять DDNS-обновления;
- Для сервера добавлена опция "ignore-client-uids" для несохранения идентификаторов пользователей, что может оказаться полезным в конфигурациях, в которых UID могут меняться после перезагрузки, но MAC-адрес остаётся неизменным.
URL: https://lists.isc.org/pipermail/dhcp-announce/2014-February/...
Новость: http://www.opennet.me/opennews/art.shtml?num=39002
IPv6 prefix delegation всё так же несовместим с ppp-интерфейсами? Или исправили наконец?
> IPv6 prefix delegation всё так же несовместим с ppp-интерфейсамиу меня -- работает нормально.
конфигурационный файл для DHCP -- генерируется на лету -- скриптом /etc/ppp/ipv6-up.d/99-my-internet.sh ..
(а не прописывается заранее статически... ведь заранее мы не знаем даже номера для ppp-интерфейса. он может оказаться ppp0,ppp1,ppp2,ppp3,ppp4 -- так что заранее прописать конфиг-файл -- точно не возможно)
в файле /etc/ppp/ipv6-down.d/99-my-internet.sh --- происходит останов DHCP и удаление его конфигурационного файла.
----------------------------------------
это я говорил не про DHCPD , а про DHCPCD :-)
----------------------------------------
а при самой работе сервера DHCPCD -- при событии получения IPv6 Prefix (или при событии изменения этого префикса) -- динамически создаётся конфигурационный файл для RADVD , и запускается RADVD
(раньше времени запускать RADVD -- нельзя -- так как в этом случае RADVD может "заснуть" и уже не реагировать на то что появился новый префикс)
вобщм сложный костыль :) , но работает отлично :)
----------------------------------------
по хорошему -- нужно было бы написать одного демона-манагера, который бы всё время висел бы в памяти (учитывал бы актуальное состояние) и управлял бы всеми этими DHCPCD и RADVD и их конфигурационными файлами (запускал бы, останавливал бы, создавал конфиг, удалял конфиг)..
а производил бы это своё управление --- исходя из информации о поступающих событиях:
-- появился новый pppX интерфейс
-- разъединился pppX интерфейс
-- появился IPv6 PD Prefix
-- изменился IPv6 PD Prefix
-- продлился (без изменений) IPv6 PD Prefix
-- удалился IPv6 PD Prefix
> это я говорил не про DHCPD , а про DHCPCD :-)Спасибо, попробую dhcpcd. А то сабжевый dhclient при попытке получения префикса на ppp выдаёт «Unsupported device type 512 for "ppp0"». Сколько ни мучился, так и пришлось откапывать и собирать древний и неподдерживаемый wide-dhcpv6 как единственный, о котором до меня дошли "истории успеха". Будет время - попробую переделать на dhcpcd.
а вот я даже не пробовал использовать wide-dhcpv6слишком уж не стандартное оно (wide-dhcpv6).. тем более если справляется DHCPCD -- то зачем ставить не стандартный софт (?)..
dhclient -- да -- вроде бы не умеет IPv6 PD как пишут всякие там Wiki :-) -- это о нём новость?пример скрипта для владельцев DHCPCD:
------------------------------------------------------------
файл etc/ppp/ipv6-up.d/99-my-internet.sh :
#!/usr/bin/bash
if [ -z "$IFNAME" ] || [ "$LINKNAME" != "my_provider_linkname_blahblahblah" ]
then
true
exit
fi
lan_iface="br-lan"
modprobe ip6_tables
modprobe ip6table_filterip6tables -P FORWARD DROP && sysctl net.ipv6.conf.default.forwarding=1 && sysctl net.ipv6.conf.all.forwarding=1
if ! ip6tables -t mangle -C FORWARD -i "$lan_iface" -o "$IFNAME" -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
then
ip6tables -t mangle -A FORWARD -i "$lan_iface" -o "$IFNAME" -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
fiif ! ip6tables -C FORWARD -i "$lan_iface" -o "$IFNAME" -j ACCEPT
then
ip6tables -A FORWARD -i "$lan_iface" -o "$IFNAME" -j ACCEPT
fiif ! ip6tables -C FORWARD -i "$IFNAME" -o "$lan_iface" -j ACCEPT
then
ip6tables -A FORWARD -i "$IFNAME" -o "$lan_iface" -j ACCEPT
ficat >/var/run/custom-internet-dhcpcd.conf <<__END__
ipv6only
noipv6rs
ia_pd 1
__END__cat >/var/run/custom-internet-dhcpcd-hooks <<__END__
#!/usr/bin/bashif [ "\$reason" == "REBIND6" ] && [ "\$new_dhcp6_prefix" == "\$old_dhcp6_prefix" ]
then
true
exit
fiif [ "\$reason" == "BOUND6" ] || [ "\$reason" == "REBIND6" ] || [ "\$reason" == "STOP6" ]
then
if [ -f /var/run/custom-internet-radvd.conf ]
then
rm /var/run/custom-internet-radvd.conf
fi
if [ -f /var/run/custom-internet-radvd.pid ]
then
radvd_pid="\$(cat /var/run/custom-internet-radvd.pid)"
rm /var/run/custom-internet-radvd.pid
kill "\$radvd_pid"
fi
if [ -f /var/run/custom-internet-dhcpcd-addr.data ]
then
ip -6 addr del "\$(cat /var/run/custom-internet-dhcpcd-addr.data)" dev $lan_iface
rm /var/run/custom-internet-dhcpcd-addr.data
fi
fiif [ "\$reason" == "BOUND6" ] || [ "\$reason" == "REBIND6" ]
then
new_dhcp6_addr="\${new_dhcp6_prefix/%::\\/64/::1/64}"
if [ "\$new_dhcp6_addr" != "\$new_dhcp6_prefix" ]
then
echo "\$new_dhcp6_addr" >/var/run/custom-internet-dhcpcd-addr.data
ip -6 addr add "\$new_dhcp6_addr" dev $lan_iface
cat >/var/run/custom-internet-radvd.conf <<__INNER_END__
interface $lan_iface {
AdvSendAdvert on;
MaxRtrAdvInterval 10; # hack for broken mobile wifi-devices (normal default is 600)
AdvDefaultLifetime 1800; # hack for broken mobile wifi-devices (normal default is MaxRtrAdvInterval*3)
# see http://code.google.com/p/android/issues/detail?id=32662
prefix \$new_dhcp6_prefix
{
};
RDNSS 2001:4860:4860::8888 2001:4860:4860::8844
{
};
};
__INNER_END__
radvd -C /var/run/custom-internet-radvd.conf -p /var/run/custom-internet-radvd.pid
fi
fitrue
__END__
chmod +x /var/run/custom-internet-dhcpcd-hooksdhcpcd -B -f /var/run/custom-internet-dhcpcd.conf -c /var/run/custom-internet-dhcpcd-hooks "$IFNAME" &
true
------------------------------------------------------------
файл /etc/ppp/ipv6-down.d/99-my-internet.sh :
#!/usr/bin/bashif [ -z "$IFNAME" ] || [ "$LINKNAME" != "my_provider_linkname_blahblahblah" ]
then
true
exit
filan_iface="br-lan"
modprobe ip6_tables
modprobe ip6table_filterip6tables -t mangle -D FORWARD -i "$lan_iface" -o "$IFNAME" -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip6tables -D FORWARD -i "$lan_iface" -o "$IFNAME" -j ACCEPT
ip6tables -D FORWARD -i "$IFNAME" -o "$lan_iface" -j ACCEPTdhcpcd -x "$IFNAME"
rm /var/run/custom-internet-dhcpcd.conf
rm /var/run/custom-internet-dhcpcd-hooks
rm /var/lib/dhcpcd/dhcpcd-"$IFNAME".lease6true
Как обычно, в хучшем виде - три страницы простыней с конфигурацией размазанной по всему коду. А потом такие удивляются - за что мы инит не лю. За то что там за такими как этот тип приходится расчищать...
> Как обычно, в хучшем виде - три страницы простыней с конфигурацией размазанной по всему коду.это не код, а весёлый костыль. :-)
если ты захочешь этот костыль разбить на отдельные маленькие файлы -- то всё равно это ОСТАНЕТСЯ костылём -- но при этом ещё и будет находиться РАЗМАЗАННО внутри файловой системы...
(охринитально будет: файловая система будет усеяна мини-костылями! ну круто же! ещё больше непонятно-как связанных файлов! ещё сложнее система!)
уж пусть лучше костыль находится в одном файле. потому что это нормально, когда всё говно собрано в одном месте :) ..
а чтобы УСТРАНИТЬ костыльность этого кода (а не размазать говно по файловой системе) -- нужно сделать дополнительный сервис (запускаемый из systemd), который будет висеть в памяти и заниматься своей работой (а именно какой работой (?) заниматься согласованием сервисов: PPPD, DHCPCD, RADVD).
об этом я уже писал. см сообщение #2 (нижняя часть сообщения)
Таджикские админы! :)Если так приспичило разруливать ppp, то делается бридж и все динамические линки суются в него.
Точно. И ppp в бридж засунем, наш бридж, не такое может.
Молодец!
> Таджикские админы! :)на самом деле -- некоторые люди -- вообще думают что:
1. ppp-интерфейс это якобы всегда ppp0 (во всех скриптах хардкодно прописывается ppp0)
2. интернет якобы всегда имеет стабильный канал, и якобы всегда не рвётся (или если рвётся, то якобы только на 1 минутку, а не на 4 часа), и всегда подключается с первого раза (особенно с первого раза -- если компьютер в процессе своей загрузки). и т д ...
а если серъёзно подумать и учесть сколько разных может быть разных не стандартных нюансов -- вот тогда и приходит в голову написать демона-манагера (висящего в памяти, для целей разруливания всё как надо), про который я упомянул сообщения #2 (в низу) :-)
------------------------------------------------------------
> Если так приспичило разруливать ppp, то делается бридж и все динамические линки
> суются в него.ну а про bridge -- интересная мысль , спасибо за пищу для размышления , только как тогда получить site-local IPv6 при событии поднятия интерфейcа pppX
# UPDATED!
кажется я понял как получить site-local IPv6 если бы он был bridge .. надо ещё подумать :) [ну и вообще -- думать полезно, да]
> # UPDATED!
> кажется я понял как получить site-local IPv6 если бы он был bridge
> .. надо ещё подумать :) [ну и вообще -- думать полезно,
> да]Вы действительно, думаете, что, ppp можно засунуть в bridge?
>> Таджикские админы! :)
> Вы действительно, думаете, что, ppp можно засунуть в bridge?а почему это должно не получиться? (ни разу не пробовал, разумется)
потому что "протокол точка-к-точке" ?
Потому, что, есть теплое, а есть мягкое.
А если серьезно, попробуйте, или изучите, что есть что, и почему.
Для ленивых:
http://osdir.com/ml/linux.network.bridge/2008-06/msg00026.html
> Потому, что, есть теплое, а есть мягкое.Патамуша, Гладиолус - http://lartc.org/howto/lartc.tunnel.ip-ip.html
и не обязательно для этого подымать адский openvpn
ipip ты в бридж тоже не засунешь. однако, с gretap-ом прокатить.
Да вы батенька, не только сомоуверенный ..., но
еще, и не умеете признавать свои ошибки,
хотя пургу несете, порой, знатную.
> Да вы батенька, не только сомоуверенный ..., но
> еще, и не умеете признавать свои ошибки,
> хотя пургу несете, порой, знатную.Во я лошара, как же у меня работаю около 1000 тунелей в одном бридже, даже низнаю...
Мож из-за того, что лохов на опеннете не слушаю, как думаш?
> Во я лошара,Это точно. :)
Речь идет о "Point-to-Point Protocol" и его реализации в Linux.
Можно, глянуть на вывод "brctl show", где есть pppX?
> то делается бридж и все динамические линки суются в него.Ого, да ты хакир? :)
>по хорошему -- нужно было бы написать одного демона-манагера, который бы всё время висел бы в памяти (учитывал бы актуальное состояние) и управлял бы всеми этими DHCPCD и RADVD и их конфигурационными файлами (запускал бы, останавливал бы, создавал конфиг, удалял конфиг)..Тс-с, тихо, а то Поцтеринг услышит ;) Лучше пусть этот демон рулит сетевыми делами, а не всем в сиситеме.
> Тс-с, тихо, а то Поцтеринг услышит ;)Ага, и еще одним костылем станет меньше. Вот ведь изверг - последнее отнимает!
> Тс-с, тихо, а то Поцтеринг услышит ;) Лучше пусть этот демон рулит
> сетевыми делами, а не всем в сиситеме.Без поттера никакого демона вообще не будет, потому что феерический костыль на шелле - это юниксвей.
> Поддержка стандартной реализации динамического DNS-сервер (DDNS), соответствующего актуальным требованиям RFC 4701, 4702, 4703 и 4361 и предоставляющего возможность совместного использования записей DDNS между клиентами DHCPv4 и DHCPv6.А в BIND такая поддержка есть?
Кто нибудь знает, поддерживается ли failover при работе в режиме ipv6?
> Кто нибудь знает, поддерживается ли failover при работе в режиме ipv6?Какой еще фейловер для dhcp сервера ты хочешь? Достаточно хранить лизы в месте, доступном обоим серверам, а там уже до кого клиент раньше добежит. Никакой специальной поддержки не требуется.
Ну, я сейчас так и использую его, dhcpd6.leases лежит на glusterfs, pacemaker следит за состоянием демона dhcpd6. И это ни разу не круто.В ipv4 режиме фейловер то нормально работает, если его еще не сделали для ipv6, то думаю скоро должны это реализовать...
> Ну, я сейчас так и использую его, dhcpd6.leases лежит на glusterfs, pacemaker
> следит за состоянием демона dhcpd6. И это ни разу не круто.Зачем pacemaker? Ну упадет у тебя один dhcp-сервер, все запросы другому достанутся, они же мультикастовые, никакого переключения не требуется.
Просто pacemaker у меня уже рулил другими сервисами. Конечно ради одного dchpd его ставить не очень хорошая идея)
> Какой еще фейловер для dhcp сервера ты хочешь? Достаточно хранить лизы в месте, доступном обоим серверам, а там уже до кого клиент раньше добежит. Никакой специальной поддержки не требуется.Что, и никаких race condition не возникает?
о, ребят, может кто поможет
[br]
костыльно наверное, но
[br]
есть /48 подсеть, хочу в зависимости от маков рассовать в 3 разные /64 подсети
[br]
завел shared-network, в ней 3 subnet6 по /64, в них pool6 с allow known-clients; deny unknown-clients, в каждом pool6 своя group в которой определены host {} с идетификацией по маку(добавил и по uid, после прочтения манов)
[br]
так вот статику получают только чуваки с маками из первого pool6, все остальные(те, что определены во втором и третьем пуле) получают динамику из первого пула
[br]
параллельно работает dhcpd -4, там такая штука прокатывает - все получают статиту в том пуле, в котором описаны host
[br]
сломал голову, как его заставить смотреть дальше первого пула :(