Сервер делегации префикса DHCPv6 для Linux?

Кажется, что у Вас нет поддержки "кодовой страницы cp437" в ядре.

Попытайтесь Посмотреть в своем/proc/config.gz файле и искать строку как CONFIG_NLS_CODEPAGE_437=m или CONFIG_NLS_CODEPAGE_437=y. Если Вы не находите его, необходимо будет перекомпилировать ядро для добавления необходимого модуля.

8
02.01.2012, 03:19
4 ответа

Программа, которая действительно снабжает префиксом делегацию, radvd (Демон объявления маршрутизатора). Другие хосты IPv6 на ссылке должны автоматически настроить глобально routeable адрес от префикса, о котором объявляют.

IPv6 не требует NAT как хостов, которые требуют, чтобы доступ в Интернет, как ожидали, будет иметь глобально routeable адреса. Необходимо быть осторожными в правилах Брандмауэра предотвратить проникновение от Интернета.

ISPs, как ожидают, выделят/48 или/56 сетевой блок их клиентам. Это требует, чтобы немного ум на стороне ISP гарантировало, что каждый маршрутизатор получает уникальный блок. Один/64 блок будет, вероятно, использоваться в качестве восходящего канала к сети IPS. Маршрутизатор затем свободен объявить о стольких же / 64 сколько от остальной части блока, как это желает. Вероятно, только один использовался бы в этом сценарии.

Также существует реализация DHCP IPv6.

Одна быстрая установка, которая была сделана, должна настроить маршрутизатор для использования 6to4 туннелирование. radvd будет автоматически конфигурироваться для этой установки, но это требует публично routeable адреса IPv4.

Править: В то время как radvd не может подделегировать префиксы, это может автоматически объявить о/64 префиксе на основе доступные routeable адреса. Это также имеет Base6to4 для автоматического объявления 6to4 префикс маршрутизатора. Подделегация требует некоторого планирования и вне того, что должно ожидаться конфигурации Plug and Play.

EDIT2: Как IPv4 IPv6 не имеет метода для определения, какая сеть принадлежит в сетях, подключенных к eth1 или основе eth2 на адресе, присвоенном интерфейсу eth0. После того как у Вас есть несколько сегментов сети, необходимо начать управлять адресами, присвоенными каждому сегменту. Хорошие новости, это может обычно делаться однажды.

IPv6 помогает, поскольку 5 и 8 может легко быть дан/49 или/50 подсети/48, делегированного к 3. Альтернативный подход должен был бы настроить 3, 5, и 8 как мосты на той же/64 подсети. В такой конфигурации они работали бы переключателями. Автоматическое поколение подсети рискует маршрутизаторами 5 и 8 оба желания делегировать ту же подсеть.

Включите и молитесь, чтобы маршрутизаторы для домашнего использования просто использовали частный блок адреса по умолчанию. Они быстро ломаются при конфигурировании как показано в схеме. Смешивание маршрутизаторов с различными блоками адреса по умолчанию может работать. Иначе необходимо удостовериться, что каждый маршрутизатор имеет различный блок адресов.

1
27.01.2020, 20:12
  • 1
    я - вполне уверенный radvd, не может сделать делегации Префикса, по крайней мере, не отдельно. Это должно быть настроено, чтобы иметь флаг, который указывает на использование DHCPv6, и затем сервер DHCPv6 может делегировать префиксы. Я ищу программное обеспечение, которое может запросить делегацию префикса и затем подделегировать это, включая меньшие делегации префикса. –  Azendale 02.01.2012, 00:04
  • 2
    В ответ на редактирование: С IPv4 потребитель может включить маршрутизатор и подключить компьютеры через него. IPv4 использует NAT, чтобы сделать это. Как маршрутизатор IPv6 делает это? Разве этому не нужен блок адресов для присвоения его нисходящему потоку? Мой вопрос ищет программное обеспечение, которое просит блок адресов и затем присваивает это нисходящему потоку, является ли тот нисходящий поток клиентами или другим маршрутизатором с большим количеством клиентов позади него. –  Azendale 02.01.2012, 03:28
  • 3
    Так, я предполагаю одну ситуацию, которую я видел NAT позади NAT, был случай удачных. Я предполагаю, что это - возможность для IPv6 для добиваний большего успеха, чем IPv4. От задавания этого вопроса по tunnelbroker.net/forums/index.php?topic=2212.0 очевидно, что то, что я спрашиваю, может быть сделано в то время как все еще после протокола. Таким образом, я все еще ищу программное обеспечение, чтобы сделать то, что я хочу. –  Azendale 03.01.2012, 04:58

Похож на Вас, нуждаются в протоколе маршрутизации, таком как RIPng. Вы могли установить quagga на тех полях, настроить интерфейсы, которым нужен протокол маршрутизации (после того как) и от Вас идут.

-1
27.01.2020, 20:12

В приятеле можно установить дополнительные часовые пояса. Перейдите по пути Настройки часов - > Местоположения - > Добавить . После завершения щелкните часы для изменения текущего часового пояса. Отчет о погоде должен быть соответствующим образом обновлен. ( источник )

Также можно попробовать другое погодное приложение. индикатор-погода от ppa: weather-indicator-team/ppa , похоже, имеет ту функцию, которую вы ищете.

-121--114396-

Это не полный ответ, поскольку я все еще работаю над некоторыми проблемами, но вот что у меня есть до сих пор, пытаясь развернуть почти идентичную установку (хотя по несколько другим причинам).

Хорошая новость в том, что это можно сделать в рамках спецификаций. На самом деле, спецификации были явно разработаны для поощрения такого рода субделегации префиксов, в основном для того, чтобы избежать необходимости болезненных нескольких уровней NAT, в то же время обеспечивая гибкость в том, как сети структурированы.

Плохая новость заключается в том, что нет «готового» программного обеспечения, которое запросило бы префикс от восходящего направления, сконфигурировало бы адреса и маршруты локально и выдавало бы субприборы в нисходящие сети. Черт, даже не представляется возможным подключить уже существующие части программного обеспечения в Linux (без исправления), чтобы сделать то, что необходимо сделать. Хуже всего то, что это не похоже на то, что кого-то это волнует.

Что у меня есть настройка и работа до сих пор выглядит следующим образом:

  • Я использую WIDE DHCPv6 client ( dhcp6c ) для запроса префикса из «восходящей» сети; Я выбрал этот клиент вместо DHCP-клиента ISC, потому что на момент настройки он был единственным DHCPv6 клиентом, который автоматически назначал адреса из полученного префикса другим интерфейсам. Я хотел бы думать, что другие клиенты DHCP улучшились с тех пор, но меня не могли беспокоить проверки на данный момент.

    К сожалению, он не предоставляет делегированные детали префикса своему внешнему скрипту hook, что означает, что вы не можете (легко) переписать «нисходящий» конфигурационный элемент dhcpd.

  • Сервер ISC DHCP (в режиме v6) для назначения префиксов «дочерней» сети. Я выбрал это, потому что DHCP-сервер WIDE, насколько я могу судить, может делегировать префиксы только статически, а не динамически. Относительно легко настроить сервер ISC DHCP для динамического делегирования префиксов, что удивительно; что-то такое простое, как это сделает хитрость:

     subnet6 2001: db8: 1234: ffff: :/64 {
    prefix6 2001:db8:1234:a000:: 2001:db8:c0f:aff0::/60;
    }
    

    Он прослушивает любой интерфейс с адресом в 2001: db8: 1234: ffff: :/64 и выдает/60s из указанного диапазона. До тех пор, пока вы можете принудительно dhcp6c обновить вышеупомянутый конфигурационный элемент (следующий!), вы можете автоматически обновить конфигурационный элемент dhcpd при изменении делегированного суперпрефикса.

  • dhcp6c будет, как упоминалось выше, использовать параметр script в файле конфигурации для запуска при получении DHCPv6 ответа. К сожалению,он предоставляет только такие параметры, как сервер SIP и DNS-распознаватели, а не полезную информацию, как делегированный префикс. Итак, у меня есть следующий сценарий, чтобы сделать это для меня:

     # !/bin/sh
    
    (сон 3;
    
    base_prefix="$ (ip -6 ad sh eth0 | grep 'scope global' | cut -d '-f 6 | cut -d: -f 1-4 | sed' s/00 $/') "
    
    если [«$ base _ prefix» = «»]; тогда
    выход 0
    fi
    
    cat < < -EOF >/etc/dhcp/dhcpd6.conf
    время аренды по умолчанию 1800;
    максимальное время аренды 7200;
    
    subnet6 $ {базовый _ префикс} 00: :/64 {
    префикс6 $ {base _ prefix} a0:: $ {base _ prefix} f0: :/60;
    }
    EOF
    
    svc-t/etc/service/dhcp6d) &
    
    выход 0
    

    Выполнение всей работы в субоболочке означает, что я могу немного подождать ( sleep 3 ), чтобы клиент DHCP фактически настроил интерфейс (похоже, он запустит сценарий перед конфигурированием интерфейса). Работает достаточно надежно. Обратите внимание, что мой Интернет-провайдер делегирует мне /56 , поэтому я снимаю только два нуля с полученного префикса. Если вам посчастливится получить целый /48 , конвейер для назначения базового префикса _ будет намного проще.

То, чего уже нет , и что, я уверен, требует исправления исходного кода, - это настройка маршрутов при делегировании префикса. Насколько я вижу, ни один DHCP-сервер не имеет встроенной возможности добавлять маршрут автоматически (я внимательно изучил WIDE dhcp6s , он, конечно, не может сделать это, и я не могу найти ничего на трубках ', чтобы предположить, что ISC DHCP делает это). Даже нет возможности выполнить внешнюю команду, которая принимает делегируемый префикс и локальный адрес клиента (ISC DHCP имеет при фиксации {execute (...)} , но не может получить локальный адрес клиента для отключения).

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

Я только что разработал исправление для ISC DHCP, чтобы предоставить дополнительное «выражение данных» для функциональности оценки; это позволяет мне замаскировать внешнюю программу, которая затем может добавлять/удалять маршруты при назначении префиксов и освобождении/истечении срока действия; патч доступен по адресу https://github.com/mpalmer/isc-dhcp/commit/4c8ae763bcf83c9068d57a5d9f570690a581b6d6 (против ISC DHCP 4,3,1); У меня нет сценария для добавления маршрута (еще), но я, вероятно, добавлю его под contrib в этой ветви, как только я получу его запись.

ДОБАВЛЕНИЕ: Оказалось, что для повторного удаления маршрутов необходимо дальнейшее изменение; который теперь добавлен в ветвь client-address-data-expression вместе с небольшим сценарием Ruby, который показывает, как все это может быть объединено вместе.

5
27.01.2020, 20:12

Я обнаружил, что сервер dhcpv6 dibbler предоставляет необходимую информацию в своем файле AddrMgr.xml. Он содержит ссылку -на локальный адрес запрашивающего маршрутизатора и делегированный префикс. Я собираюсь поэкспериментировать с этим позже.

РЕДАКТИРОВАТЬ:

Я написал небольшой PHP-файл, который может создавать все маршруты, просто прочитав XML-файл. Как использовать:

  1. Установите необходимое программное обеспечение на сервер:sudo apt install php php-xml

Important: You need to have radvd and dibbler-server configured to do this, but I think there are enough resources for radvd on the internet and dibbler-server comes with a standard configuration.

  1. Получить файл изhttp://185.248.140.213/project/Sub/RouterHelper/routen.php.tar.gz
  2. Переместить файл в /var/www/html/
  3. Войдите в систему как пользователь root с sudo suи введите:root@machine:~# echo "YOURLANINTERFACENAME" > /var/www/html/lanif.txt
  4. Изменить привилегии:sudo chmod 777 /var/www/html/lanif.txt
  5. Создайте crontab для пользователя root:sudo runuser -l root -c 'crontab -e'Добавьте следующую строку:

* * * * * php /var/www/html/routen.phpЗатем сохраните файл. Сделанный! При подключении другого маршрутизатора обновление таблицы маршрутизации занимает от нескольких секунд до одной минуты, но потом все работает!

1
27.01.2020, 20:12

Теги

Похожие вопросы