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

Автор: admin от 26-07-2017, 16:10, посмотрело: 392

Когда мы получили блок 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



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





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

auto eth0

iface eth0 inet static

address 99.111.222.130

netmask 255.255.255.128

gateway 99.111.222.129





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

Источник: Хабрахабр

Категория: Системное администрирование, Linux, Сетевые технологии

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *