Несколько VLAN, одна сеть. Или: Несколько VLAN, та же сеть.

Я провайдер. У меня закончились IP4. Больше нет доступных распределений IP4.
Тем не менее, я использую 4 IP на 1 клиента, потому что коммутаторы оптоволоконной сети используют VLAN для маршрутизации к клиентам.

Как мне, например, предоставить 127 различным VLAN каждому уникальный IP из /25, чтобы каждый был там маршрутизирован?

Допустим, мой IP 3.8.3.1/25. Как мне выделить 3.8.3.2 для vlan 3001, 3.8.3.3 для vlan 3002, … 3.8.3.127 для vlan 3127?

• Требование 1: Эти IP должны иметь возможность общения друг с другом.
• Требование 2: DHCP
• Требование 3: Должно быть совместимо с формированием трафика.

Я использую 4 IP на 1 клиента, потому что коммутаторы оптоволоконной сети используют VLAN для маршрутизации к клиентам.

Я предполагаю, что это означает, что вы используете /30 на VLAN в данный момент. Промежуточным улучшением было бы использование /31 (с двумя адресами хоста и нулевыми резервированными адресами) – не все системы поддерживают это пока, так как это относительно недавно стандартизированный специальный случай, но многие уже делают; и хотя это не так плотно, как вы спрашиваете, тем не менее, это в 2 раза эффективнее, чем традиционное /30, а также проще в реализации, чем запрос.

192.168.5.4/30
  192.168.5.4 - устаревшая широковещательная рассылка
  192.168.5.5 - хост A
  192.168.5.6 - хост B
  192.168.5.7 - стандартная широковещательная рассылка

192.168.5.4/31
  192.168.5.4 - хост A
  192.168.5.5 - хост B
  нет резервированных адресов

Дальше можно использовать пару /32 – то есть, вовсе без “подавления”, но с явным маршрутом к адресату. Linux поддерживает это, это обычно называют “point-to-point” конфигурацией, как и большинство BSD, и очень часто это используется с одинаковым локальным адресом на нескольких интерфейсах – это не вызывает проблем, потому что /32 не расширяется в какие-либо пересекающиеся маршруты подсетей. Это был бы один из двух методов для реализации того, что вы запрашиваете – при условии, что все вовлеченные системы поддерживают это.

eth0.3 - ip addr add 192.168.5.1/32 peer 192.168.5.3/32
eth0.4 - ip addr add 192.168.5.1/32 peer 192.168.5.4/32
eth0.5 - ip addr add 192.168.5.1/32 peer 192.168.5.5/32
...

Что на самом деле является сокращением для “адрес 192.168.5.1/32, а также маршрут 192.168.5.3/32 через этот интерфейс”, так же как маски подсети являются краткой формой маршрута устройства.

Проблема с этим в том, что я не уверен, возможно ли развернуть противоположную конфигурацию через DHCP. (Хотя это было бы довольно распространено для PPP соединений, таких как PPPoE.)

Чтобы использовать DHCP, вам нужно добавить Proxy-ARP, чтобы устройства ваших клиентов думали, что они находятся в /25, даже если это не настроено как /25 с вашей стороны. То есть, они могут получать стандартную аренду DHCP, указывающую на маску сети /25, и они могут успешно ARP для IP-адреса другого клиента (получая вместо этого MAC вашего шлюза) – в то время как с вашей стороны у вас все еще есть только /32 на каждом интерфейсе VLAN, как в предыдущем примере.

Linux имеет встроенный Proxy-ARP как установку интерфейса (для “глобального” проксирования) или в виде специальных записей кэша соседей (для более точного проксирования), но также существуют реализации в пространстве пользователя; например, я использую parpd для проксирования /26 в другой VLAN по историческим причинам.

Это должно быть в основном совместимо с DHCP-серверами, хотя не будет никакой автоматической ассоциации между арендами и маршрутами – вам, вероятно, придется вручную убедиться, что VLAN с Клиентом А имеет правильно маршрутизированный /32. (либо как параметр ‘peer’, либо как обычный статический маршрут, не имеет значения).