Аналог ip unnumbered в Linux системах или экономим IP адреса
Не так давно я столкнулся с проблемой аналога ip unnumbered на Linux, которая с легкостью реализовывается на оборудование Cisco.
При использование такого вида маршрутизации, не придется делить сеть глобально маршрутизируемых ip адресов на небольшие с маской /30 или /31. Достаточно присвоить, например, интерфейсу loopback сеть класса C ( /24 ), а клиентским интерфейсам указать на то, что вся обработка IP пакетов будет осуществляется с адресом присвоенным loopback interface. Тем самым вы получаете рациональное использование IP адресов.
Рассмотрим теперь выше сказанное на практике.
Входные данные
Постановка задачи
Необходимо создать 3 VLAN-а, для обслуживания трех абонентов и предоставить каждому по публичному IP адресу из сети 195.131.195.0/24.
Часть первая. Что бы вы сделали без ip unnumbered?
Чтобы мы сделали в таком случае, если бы не использовали ip unnumbered? Мы бы поделили нашу сеть на более мелкие, например, на сети с размерностью /30, тоесть маской подсети 255.255.255.252. И так, три клиента, три сети:
Сеть номер один: 195.131.195.0/30
Где: 195.131.195.0 – индификатор сети, 195.131.195.1 – IP, который выступает в роли шлюза для клиента, 195.131.195.2 – клиентский IP адрес и 195.131.195.3 – broadcast. По этой же аналогии разбиваем оставшиеся две сетки и получаем:
Сеть номер два: 195.131.195.4/30
Сеть номер три: 195.131.195.8/30
Теперь создаем конфиг на cisco router:
interface FastEthernet0/1.200
description Client-1 // описание интерфейса для первого клиента
encapsulation dot1Q 200 // используем dot1Q выставляя таким образом VID для VLAN
ip address 195.131.195.1 255.255.255.252 // присваиваем IP
!
interface FastEthernet0/1.201
description Client-2 // описание интерфейса для воторого клиента
encapsulation dot1Q 201
ip address 195.131.195.5 255.255.255.252 // присваиваем IP
!
interface FastEthernet0/1.202
description Client-3 // описание интерфейса для первого клиента
encapsulation dot1Q 202 // используем dot1Q выставляя таким образом VID для VLAN
ip address 195.131.195.9 255.255.255.252 // присваиваем IP
!
Конфиг для Cisco готов. Создадим похожую схему только уже на Debian router, для этого отредактируем файл /etc/network/interfaces
## Client 1
auto vlan200
iface vlan200 inet static
address 195.131.195.1
netmask 255.255.255.252
vlan_raw_device eth1
## Client 2
auto vlan201
iface vlan201 inet static
address 195.131.195.5
netmask 255.255.255.252
vlan_raw_device eth1
## Client 3
auto vlan202
iface vlan202 inet static
address 195.131.195.9
netmask 255.255.255.252
vlan_raw_device eth1
Подготовим коммутатор, к которому будут подключены наши виртуальные клиенты:
1 порт на коуммутаторе будет стоять в режиме switchport access vlan 200
2 порт — switchport access vlan 201
3 порт — switchport access vlan 202
Часть вторая. Переводим нашу схему на ip unnumbered.
Для этого сделаем следующие изменения на cisco router. Повесим нашу публичную сеть на loopback 200, следующим образом:
interface Loopback200
ip address 195.131.195.1 255.255.255.0
no ip redirects
Теперь поправим клиентские интерфейсы
interface FastEthernet0/1.200
description Client-1
encapsulation dot1Q 200
ip unnumbered Loopback200 // указываем на loopback 200, где висит наша сеть
ip virtual-reassembly // сбор фрагментов
!
interface FastEthernet0/1.201
description Client-2
encapsulation dot1Q 201
ip unnumbered Loopback200 // указываем на loopback 200, где висит наша сеть
ip virtual-reassembly // сбор фрагментов
!
interface FastEthernet0/1.202
description Client-3
encapsulation dot1Q 202
ip unnumbered Loopback200 // указываем на loopback 200, где висит наша сеть
ip virtual-reassembly // сбор фрагментов
И заключительный этап. Нам необходимо выдернуть всего один IP из нашей большой сети и предоставить клиенту. Сделаем это с помошью ip route:
ip route 195.131.195.2 255.255.255.255 FastEthernet0/1.200 // для клиента номер 1
ip route 195.131.195.3 255.255.255.255 FastEthernet0/1.201 // для клиента номер 2
ip route 195.131.195.4 255.255.255.255 FastEthernet0/1.202 //для клиента номер 3
Теперь для клиентов, необходимы настройки выходна в Internet: IP: 195.131.195.X, MASK: 255.255.255.0, а основной шлюз 195.131.195.1.
Почувствовали разницу? =)
А что же делать с нашим Debian router? Все просто. Изменим наш конфиг следующим образом. А вот что.
Создадим lo1 и повесим на него нашу публичную сеть.
auto lo1
allow-hotplug lo1
iface lo1 inet static
address 195.131.195.1
netmask 255.255.255.0
network 195.131.195.0
Теперь поправим клиентские VLAN сделующим образом:
## Client 1
auto vlan200
iface vlan200 inet static
address 0.0.0.0
netmask 0.0.0.0
vlan_raw_device eth1
## Client 2
auto vlan201
iface vlan201 inet static
address 0.0.0.0
netmask 0.0.0.0
vlan_raw_device eth1
## Client 2
auto vlan202
iface vlan202 inet static
address 0.0.0.0
netmask 0.0.0.0
vlan_raw_device eth1
И воспользуемся ip route:
ip ro add 195.131.195.2 dev vlan200 src 195.131.195.1 // Клиент номер 1
ip ro add 195.131.195.3 dev vlan200 src 195.131.195.1 // Клиент номер 2
ip ro add 195.131.195.4 dev vlan200 src 195.131.195.1 // Клиент номер 3
Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи
Что такое ip unnumbered?
Данный функционал реализованный в оборудовании Cisco позволяет сократить использование адресов IPv4 в условиях их дефицита.
Изначально был разработан для интерфейсов точка-точка типа Serial, при маршрутизации с участием таких интерфейсов не требуется знать адрес следующего хопа, так как это не широковещательная среда и пакет всегда достигнет своего получателя и он один, маршрутизатору достаточно «знать» что такой то префикс доступен за таким то интерфейсом.
Следовательно не требуется выделять подсеть /30 или /31 адресов на эти интерфейсы, достаточно указать на интерфейсе что вся обработка IP пакетов(а это нетранзитные пакеты к самому роутеру, либо пакеты сгенерированные самим роутером) будет осуществляться с адресом присвоенным другому интерфейсу, допустим адресом висящим на лупбеке, или на ethernet интерфейсе.
Краткая ремарка.
При не настроенном\не включённом ip unnumbered наблюдается следующая картина: начинают действовать ограничения на количество подключённых по vpn’y пользователей. К примеру, не больше 5 или 10 одновременно подключённых. Что бы этого избежать, настроим ip unnumbered.
Предположим, что настройка выдачи пула адресов для vpn’a настроена так:
ip dhcp pool vpn-pool
network 192.168.22.0 255.255.255.0
update dns both override
default-router 192.168.22.1
domain-name cisco.com
dns-server 192.168.22.217
lease infinite
update arp
Виртуальный интерфейс настроен так:
interface Virtual-Template1
ip address 192.168.22.1 255.255.255.0
ip access-group 110 in
ip nat inside
peer default ip address pool vpn-pool
ppp authentication pap callin
А теперь делаем изменения.
Создаём и настраиваем дополнительный интерфейс Loopback2:
interface Loopback2
ip address 192.168.22.1 255.255.255.0
ip nat inside
ip virtual-reassembly
а Virtual-Template1 перенастраиваем так:
interface Virtual-Template1
ip unnumbered Loopback2
Примечание.
Строка ip virtual-reassembly отвечает за сбор фрагментов пакетов. Она способствует не столько защите сколько о том, чтобы случайно не пропустить неправильные фрагментированные пакеты. Во многих современных IOS’ax она включена по умолчанию.
Аналоги в Unix системах
Существуют и аналоги в ip unnumbered в таких системах как Linux (подробнее описано здесь) и FreeBSD (подробнее описано здесь)
Cisco tips: непронумерованные IP-интерфейсы
В этом документе рассматривается концепция непронумерованных IP-интерфейсов и приводится несколько примеров конфигурации. Команда конфигурации «ip unnumbered» позволяет Вам сделать возможным обработку IP на последовательном интерфейсе без назначения ему точного адреса. Это хороший способ сохранения сетевого и адресного пространства.
IP и непронумерованные IP
В маршрутизаторе Cisco каждый интерфейс сети IP, который не подключен постоянно к общей «шине», должен принадлежать к уникальной подсети. Так работает интерфейс IP. На основе сетевой информации, которая содержится в таблице маршрутизации IP, к любой уникально идентифицируемой сети IP, напрямую не подключенной к маршрутизатору, можно добраться, направив пакет к следующему транзитному адресу сети, подключенной напрямую Когда сеть конечного пункта назначения соединена с интерфейсом, напрямую подключенным к пункту назначения, пакет без труда можно доставить конечному хосту (host).
Таблица маршрутизации IP состоит из маршрутов. Эти маршруты являются или маршрутами «подсети», или маршрутами «основной сети». Каждый маршрут имеет от одного и более вероятных адресов «последующих транзитных пунктов», которые являются адресами сети, подключенной напрямую. Маршруты подсетей замкнуты внутри основной сети. На каждом конце основной сети подсети агрегируются в один маршрут основной сети и объявляются другим основным сетям. Это позволяет сохранять размер таблиц маршрутизации небольшим.
Примечание: Приведенная выше схема агрегирования предполагает использование традиционного протокола маршрутизации дистанционных векторов, таких как RIP (Протокол маршрутизации для сетей TCP/IP) или IGRP (Внутренний протокол маршрутизации шлюза).
Предположим, что сеть класса B разбита на подсети с 8-разрядными адресами. Каждый интерфейс в сети с последовательными линиями связи будет требовать отдельную подсеть. Так как каждая последовательная линия связи имеет лишь два узла, то остаются неиспользованными 252 адреса на каждой последовательной линии. Вот где могут пригодиться непронумерованные IP. Для любой последовательной линии «точка-точка» (point-to-point) или интерфейса «точка-точка» непронумерованные IP позволяют «позаимствовать» адрес у какого-то интерфейса локальной сети для использования в качестве исходного адреса для маршрутизируемых обновлений (Update) и пакетов с этого интерфейса. Сеть полностью используется, и ценная область адресов не увеличивается.
Как же обновляется таблица маршрутизации? Обычно маршрутизатор, получающий пакет обновлений, будет использовать исходный адрес маршрутизируемого обновления в качестве следующего транзитного пункта, так как нам обеспечивается прямое подключение к сетям, посылающим это обновление (с помощью одного интерфейса одного типа сети).
Однако, так как удаленная последовательная линия «позаимствовала» адрес у удаленной локальной сети (LAN), нам не обеспечивается прямое подключение исходного адреса к маршрутизатору, получающему обновление. Поэтому, вместо простого перехода к адресу следующего транзитного участка на базе исходного адреса обновления, маршруты, опознанные по имени непронумерованного IP интерфейса, включаются в таблицу маршрутизации в качестве интерфейсных маршрутов. Это означает, что недействительный адрес следующего транзитного пункта, будет обходиться, а использоваться будет имя интерфейса, с которого мы получили данное обновление. Поэтому непронумерованные
IP имеют смысл лишь для линий связи «точка-точка».
Пример 1. С каждой стороны последовательной линии связи мы имеем ту же самую основную сеть с различными подсетями.
ip address 171.68.178.196 255.255.255.192
IP unnumbered в Debian или раздаем адреса экономно
Когда мы получили блок IP-адресов для новой технической площадки в Варшаве, автоматически возник вопрос о том, как им распорядиться экономнее — адресов никогда не бывает много, даже у свежеиспеченного LIR.
При проектировании сети в новом месте хотелось новых плюшек:
Тут на помощь приходит технология IP unnumbered. С ее помощью можно клиенту выдать хоть один адрес, хоть 6, хоть 99. На Хабре о ней уже писали, однако, статья уже довольно старая и в чистом виде нам не подошла — с той конфигурацией isc-dhcpd не слушает клиентские интерфейсы. Нам же хотелось сделать сетевую загрузку.
Итак, на входе у нас есть:
# Base interface for IP Unnumbered
auto eth1.3000
iface eth1.3000 inet static
address 99.111.222.129
netmask 255.255.255.128
И поднимаем сам интерфейс:
Адрес 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 комментируем опцию
Настройка загрузки машин по сети описана во многих источниках, потому здесь ее опустим. Нам важно, что сам DHCP-демон слушает эти интерфейсы, без этого точно ничего не загрузится.
Если клиентские машины должны друг друга видеть — добавляем в /etc/sysctl.conf:
И применяем это на лету:
Дальше осталось сконфигурировать коммутаторы.
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 живут клиенты.
Все, теперь клиент может на своем сетевом интерфейсе прописать обычные настройки вида
auto eth0
iface eth0 inet static
address 99.111.222.130
netmask 255.255.255.128
gateway 99.111.222.129
И получит только выделенные ему адреса, остальные просто не будут работать, что бы он не вешал на свой интерфейс. А мы потратили из своей сети ровно то количество адресов, которые клиент заказал.
Аналог ip unnumbered в Mikrotik RouterOS
Сразу скажу, что на написание поста меня вдохновила аналогичная статья, опубликованная на Хабре еще в 2009 году. Поэтому я не буду пересказывать ее содержимое и приводить конфигурацию Cisco-девайсов.
Сегодня, когда IPv4-адреса стали еще большим дефицитом, чем автомобиль «Москвич» во времена СССР, выделять клиенту сеть /30 или /31 — это преступление. В Cisco для обхода этих проблем есть режим «ip unnumbered», позволяющий назначить клиенту единственный адрес, не расходуя адреса впустую. Давайте посмотрим как это делается в Mikrotik RouterOS. Представим такую (сильно упрощенную) схему:
Наш шлюз (provider-gw) подключен интерфейсом ether1 к интернету посредством BGP (или другим способом, это не важно) и у нас есть собственная «большая» публичная сеть, например — 123.45.60.0/22. Первый клиент подключен к VLAN-интерфейсу vlan100, который, предположим, заведён в ether2. Второй — к vlan200.
/interface vlan add disabled=no name=vlan100 vlan-id=100 interface=ether2 comment=»Client 1″
/interface vlan add disabled=no name=vlan200 vlan-id=200 interface=ether2 comment=»Client 2″
Маршрутизатор должен иметь IP-адрес из нашей публичной сети. Допустим, 123.45.60.1 с маской /22. Этот адрес нужно назначить на любой свободный интерфейс или vlan, даже если они потом никак не будут использоваться. Пусть это будет vlan1000:
/interface vlan add disabled=no name=vlan1000 vlan-id=1000 interface=ether2
/ip address add interface=vlan1000 address=123.45.60.1/22
Теперь сделаем настройки на маршрутизаторе для наших клиентов. Для этого выделим им любые свободные IP из диапазона нашей публичной сети, допустим 123.45.60.5 и 123.45.60.6. Добавим статические маршруты для этих адресов, ведущие в соответствующие клиентские VLAN. При этом желательно указать preffered source адрес нашего маршрутизатора.
/ip route add dst-address=123.45.60.5 gateway=vlan100 pref-src=123.45.60.1 comment=»Static route to Client 1″
/ip route add dst-address=123.45.60.6 gateway=vlan200 pref-src=123.45.60.1 comment=»Static route to Client 2″
Настраиваем клиента №1:
IP: 123.45.60.5
Маска: 255.255.255.252 (или /22; да, тут мы указываем маску нашей «большой» публичной сети)
Шлюз: 123.45.60.1
Настраиваем клиента №2 аналогичным образом. Меняется только IP-адрес.
IP: 123.45.60.6
Маска: 255.255.255.252 (или /22)
Шлюз: 123.45.60.1
Всё. Этого достаточно. После этого IP клиентов будут доступны из интернета, без лишней траты адресов. Остальные клиенты включаются аналогичным образом, каждый — в свой VLAN. Но в данном случае у нас возникает такая ситуация: допустим, клиент №1 хочет передать ip-пакет клиенту №2. Поскольку адрес клиента №2 попадает под маску сети /22, клиент №1 считает что №2 находится с ним в одном широковещательном домене и попытается отправить пакет не через маршрутизатор, а напрямую, для чего попытается выяснить его MAC-адрес посредством протокола ARP. Само собой, у него это не выйдет, поскольку клиенты находятся в разных VLAN и не могут передавать друг другу ARP-запросы.
Если вам нужно изолировать клиентов друг от друга — можно оставить всё как есть, хотя с точки зрения интернета это неправильно (каждый узел должен иметь связь с другим узлом по протоколу IP). Решается такая ситуация включением proxy-arp на клиентских VLAN:
/interface vlan set vlan100 arp=proxy-arp
/interface vlan set vlan200 arp=proxy-arp
Теперь маршрутизатор будет отвечать на arp-запросы клиентов, подставляя свой MAC-адрес в ответе и клиенты смогут обмениваться IP-трафиком, словно находятся в одном сегменте.
Как вы могли догадаться, аналогичным образом можно назначать в один клиентский VLAN несколько IP-адресов или даже подсетей, просто создавая статические маршруты с соответствующим dst-address.
Как показала практика, гораздо лучше создавать не статические маршруты в /ip route, а просто добавлять на интерфейс IP-адрес маршрутизатора с указанием в поле network нужного IP-адреса, маршрут будет создан автоматически. Пример:
/ip address add network=123.45.60.5 interface=vlan100 address=123.45.60.1 comment=»IPoE Client 1″
/ip address add network=123.45.60.6 interface=vlan100 address=123.45.60.1 comment=»IPoE Client 2″
