IP unnumbered в Debian или раздаем адреса экономно

    Когда мы получили блок IP-адресов для новой технической площадки в Варшаве, автоматически возник вопрос о том, как им распорядиться экономнее — адресов никогда не бывает много, даже у свежеиспеченного LIR.

    При проектировании сети в новом месте хотелось новых плюшек:

    • В некоторой степени изолировать серверы клиентов от чужого трафика;
    • Не дать недобросовестным клиентам повесить себе на интерфейс адреса добросовестных;
    • При необходимости иметь возможность без особой нагрузки порезать трафик;
    • Иметь возможность дать клиенту любое количество IP-адресов.

    Теоретически, все эти моменты решаются с помощью обычных VLAN. Однако, возникает проблема с перерасходом адресов — все же жалко клиенту, заказавшему сервер с одним адресом, отдавать сеть /30 и терять три адреса впустую. Также жалко адреса и в обратной ситуации — клиенту надо 6 доступных адресов, а в сеть /29 он уже не поместится, приходится выдавать сеть /28 и терять 7 штук.

    Тут на помощь приходит технология IP unnumbered. С ее помощью можно клиенту выдать хоть один адрес, хоть 6, хоть 99. На Хабре о ней уже писали, однако, статья уже довольно старая и в чистом виде нам не подошла — с той конфигурацией isc-dhcpd не слушает клиентские интерфейсы. Нам же хотелось сделать сетевую загрузку.

    Итак, на входе у нас есть:

    • Сеть большого размера, например, 99.111.222.129/25
    • Маршрутизатор на базе Linux Debian 8/9
    • Layer-2 коммутатор, например, Cisco/Juniper
    • Три клиента, которым надо выдать 1, 2 и 3 IP-адреса
    • DHCP-сервер, который должен слушать клиентские виланы

    Сначала создадим технический VLAN, на котором будет большая сеть. Добавляем в /etc/network/interfaces:

    # Base interface for IP Unnumbered
    auto eth1.3000
    iface eth1.3000 inet static
    address 99.111.222.129
    netmask 255.255.255.128


    И поднимаем сам интерфейс:

    ifup eth1.3000

    Адрес 99.111.222.129 будет выступать шлюзом для клиентских машин, в сетевых настройках которых не должно быть никакой экзотики — клиентский админ не должен вникать в нюансы нашего построения сети.

    Дальше добавляем клиентские интерфейсы в /etc/network/interfaces:

    # Клиент 1
    auto eth1.3111
    iface eth1.3111 inet static
    address 10.31.11.1
    netmask 255.255.255.0
    up ip ro add 99.111.222.130 dev eth1.3111 src 99.111.222.129
    down ip ro del 99.111.222.130 dev eth1.3111 src 99.111.222.129

    # Клиент 2
    auto eth1.3112
    iface eth1.3112 inet static
    address 10.31.12.1
    netmask 255.255.255.0
    up ip ro add 99.111.222.131 dev eth1.3112 src 99.111.222.129
    up ip ro add 99.111.222.132 dev eth1.3112 src 99.111.222.129
    down ip ro del 99.111.222.131 dev eth1.3112 src 99.111.222.129
    down ip ro del 99.111.222.132 dev eth1.3112 src 99.111.222.129

    # Клиент 3
    auto eth1.3113
    iface eth1.3113 inet static
    address 10.31.13.1
    netmask 255.255.255.0
    up ip ro add 99.111.222.133 dev eth1.3113 src 99.111.222.129
    up ip ro add 99.111.222.134 dev eth1.3113 src 99.111.222.129
    up ip ro add 99.111.222.135 dev eth1.3113 src 99.111.222.129
    down ip ro del 99.111.222.133 dev eth1.3113 src 99.111.222.129
    down ip ro del 99.111.222.134 dev eth1.3113 src 99.111.222.129
    down ip ro del 99.111.222.135 dev eth1.3113 src 99.111.222.129


    И поднимаем их:

    ifup eth1.3111
    ifup eth1.3112
    ifup eth1.3113


    Адреса вида 10.31.11.1 на интерфейсах нужны с одной целью — чтобы dhcp-демон слушал эти интерфейсы. Больше они нигде не фигурируют и клиент о них не знает.

    Чтобы на клиентских интерфейсах работал isc-dhcpd, добавляем в /etc/dhcp/dhcpd.conf:

    subnet 10.31.11.0 netmask 255.255.255.0 {}
    subnet 10.31.12.0 netmask 255.255.255.0 {}
    subnet 10.31.13.0 netmask 255.255.255.0 {}


    Также, чтобы не править его каждый раз при добавлении клиента, в /etc/default/isc-dhcp-server комментируем опцию

    #INTERFACES=...

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

    Если клиентские машины должны друг друга видеть — добавляем в /etc/sysctl.conf:

    net.ipv4.conf.all.proxy_arp=1

    И применяем это на лету:

    sysctl -w net.ipv4.conf.all.proxy_arp=1

    Дальше осталось сконфигурировать коммутаторы.

    Пример для Juniper
    set vlans vlan3111 vlan-id 3111
    set vlans vlan3112 vlan-id 3112
    set vlans vlan3113 vlan-id 3113
    set interfaces xe-0/1/0 unit 0 family ethernet-switching port-mode trunk
    set interfaces xe-0/1/0 unit 0 family ethernet-switching vlan members 3111-3113
    set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
    set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
    set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access
    set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members 3111
    set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 3112
    set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members 3113

    Здесь порт xe-0/1/0 смотрит на наш маршрутизатор, а на портах ge-0/0/0 — ge-0/0/2 живут клиенты.

    Пример для Cisco
    vlan 3111
    name vlan3111
    vlan 3112
    name vlan3112
    vlan 3113
    name vlan3113
    interface GigabitEthernet0/48
    switchport mode trunk
    switchport trunk allowed vlan add 3111-3113
    interface GigabitEthernet0/1
    switchport mode access
    switchport access vlan 3111
    interface GigabitEthernet0/2
    switchport mode access
    switchport access vlan 3112
    interface GigabitEthernet0/3
    switchport mode access
    switchport access vlan 3113

    Здесь порт GigabitEthernet0/48 смотрит на наш маршрутизатор, а на портах GigabitEthernet0/1 — GigabitEthernet0/3 живут клиенты.

    Все, теперь клиент может на своем сетевом интерфейсе прописать обычные настройки вида

    auto eth0
    iface eth0 inet static
    address 99.111.222.130
    netmask 255.255.255.128
    gateway 99.111.222.129

    И получит только выделенные ему адреса, остальные просто не будут работать, что бы он не вешал на свой интерфейс. А мы потратили из своей сети ровно то количество адресов, которые клиент заказал.
    Поделиться публикацией

    Комментарии 10

      0

      Интересная идея, как раз сейчас думаю над чем то подобным для клиентских виртуальных машин. Есть пара вопросов:
      1) Зачем нужен Dhcp, если в конце статьи настраивается статический адрес?
      2) У vlan есть ограничение в 4094 сетей, думаю можно ли сделать подобное с vlan, или вообще затунеллировать в gre?

        0
        1. У нас машины не виртуальные, а физические. DHCP нужен, чтобы сработала сетевая загрузка инсталлятора ОС/rescue-образа. В это время на клиенте ничего не сконфигурировано и ему надо выдать адрес, образ ОС и т.д…
        2. Ограничение с виланами в принципе не такая большая проблема. Закончились виланы — поставили рядом второй маршрутизатор со своим свитчом, у них будет еще 4k виланов.
          0
          1)дхчп выдает адреса клиентам, а статикой забиты адреса на роутере.
          2)можно уложить несколько машин в один влан или использовать qinq.
            0

            Я вот тоже об этом подумал — настроить qnq на порядок проще

          0
          RFC 3021 поможет сохранить еще пару адресов
            0
            Смотрели, все равно получается расход 2 адреса на подключение клиента, требующего один. В нашей схеме расход технических адресов 3шт на весь большой блок — начало сети, броадкаст и шлюз. Дальше любое количество клиентов подключается без оверхеда.
              0
              можно использовать accel-ppp в режиме ppp. он автоматически подготавливает vlan, адреса на шлюзе и немного другой подход к проксиарп.
                0
                Мм, возможно, я слишком бегло глянул описание, но вроде у нас задача несколько другая. У нас есть пачка клиентских выделенных серверов, у которых интерфейс должен быть сконфигурирован просто статически — администраторы клиентов не будут поднимать какие-либо VPN-сервисы, чтобы получить свой адрес. Для них все должно выглядеть как обычное конфигурирование сетевухи и не более.

                Плюс на самом деле у нас есть еще панель управления этими серверами для клиентов. Она вообще не в курсе этой схемы и думает, что все серверы в обычной большой подсети. Так что так или иначе, при выдаче машины клиенту эту часть приходится конфигурировать руками.
                  0
                  ipoe режим смотрите там.

                  делает всё тоже, что описанно в статье, но более автоматизированно.

                  при должном подходе можно избавиться от ручной настройки
                    0
                    Спасибо, почитаю обязательно.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое