Конфигурирование хитрых интерфейсов в Debian’е

Через /etc/network/interfaces, а не совсем вручную.
1) tun/tap:
iface tap10 inet manual
pre-up ip tuntap add tap10 mode tap user root
up ip link set dev tap10 up
post-down ip link del dev tap10

2) trunk, разделящий пакеты от разных VLANов по псевдоинтерфейсам, как оказалось, конфигурируется исключительно просто:
iface eth1.1 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1

iface eth1.5 inet static
address 192.168.20.30
netmask 255.255.255.0
Число после точки в имени интерфейса – это номер VLAN’а. Только чтобы оно заработало, в системе должен быть установлена программа vconfig (из пакета vlan).

3) Несколько IPшников, возможно, из разных подсетей, на одном интерфейсе. Типичный случай, когда в одном физическом сегменте используется несколько подсетей, или когда одна машина должна отзываться на несколько адресов:
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.1

iface eth0:0 inet static
address 192.168.100.150
netmask 255.255.255.0

iface eth0:1 inet static
address 192.168.200.10
netmask 255.255.255.0

На одном из этих eth0* можно вместо статического адреса использовать DHCP:
iface eth0 inet dhcp

4) А вот если хочется на одном физическом интерфейсе получить несколько разных адресов по DHCP, то придётся поизвращаться. Поскольку DHCP-сервер привязывает выдаваемые IP к MAC-адресам, а MAC-то у физического интерфейса только один, то больше одного IP ему не дадут. Так что придётся добавить к физическому интерфейсу (скажем, eth0) фейковый интерфейс с другим MAC-адресом:
iface eth0 inet dhcp

iface ethFake inet dhcp
pre-up ip link add link eth0 name ethFake address 00:01:02:03:04:05 type macvlan
up ip link set dev ethFake up
post-down ip link del dev ethFake
MAC указывать не обязательно. Если его нет, то ip link add сгенерирует случайный адрес.

А теперь хитрый вопрос для продвинутых сисадминов: поскольку обычно DHCP-сервер выдаёт клиенту адрес гейта, а DHCP-клиент приделывает его в качестве дефолтового маршрута (причём с указанием клиентского IP в качестве src), то при начальном конфигурировании этих двух интерфейсов и при последующих обновлениях дефолтовый маршрут будет перебрасываться с eth0 на ethFake и обратно, и тем ломать маршрутизацию и ронять установленные на тот момент соединения с другого клиентского IP. Как этого избежать?
(Если чё, я знаю ответ :)

Оригинал этой записи в личном блоге.