>>> проще поднять отдельный NAT на реальном IP для таких арендаторов.
>> В том-то и дело, что им не нужен NAT. Вернее, им нужен
>> IP до NAT.
> Тогда играйся с мостом - твой внешний интерфейс и отдельный линк на
> клиента.
> Но при этом, ты не сможешь контролировать толщину клиентского канала.Есть еще Фоллшебная ффича proxy-arp. На линуксе делается достаточно легко, на фряхе посложнее. Я точно не знаю, можно ли сделать это на FreeBSD не выделяя для proxy-arp полную подсеть. На линуксе можно проксировать отдельный айпишник, поскольку:
На линухе можно так:
# ifconfig vif5.0
vif5.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff
inet addr:79.1.2.103 Bcast:79.255.255.255 Mask:255.255.255.255
# netstat -rn
1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 vif5.0
т.е. для хоста прописывается отдельное правило маршрутизации _в_устройство_...
командой "ip route addr ${addr} dev ${vif} src ${main_ip}"
где 79.1.2.103 - это основной айпишник хоста, висит на внешнем интерфейсе eth0. vif5.0 - внутренний интерфейс, его адрес в моем случае не имеет значения, потому что на клиенте сделано так:
srv05:~# netstat -rn
Kernel IP routing table
Destination_____Gateway Genmask Flags MSS Window irtt Iface
79.1.2.103______0.0.0.0 255.255.255.255 UH 0 0 0 eth0
0.0.0.0_________79.1.2.103 0.0.0.0 UG 0 0 0 eth0
Это позволяет пробросить внутрь сети айпишник из внешнего физического сегмента.
Во фре такой фокус не проходит:
[root@rpv ~]# route add 100.100.100.100 0.0.0.0 dev rl0
route: bad address: rl0
Еще в линуксе можно делать нечто типа такого:
/usr/sbin/arp -i eth1 -d $IP pub
правда по-моему, proxy-arp флаг на интерфейсе всеравно пришлось включить, как-то криво отрабатывалось одно подключение (опенвпн по tap) с клиентом на семерке.
----
Для фряхи наверное будет решение следующим:
1) клиенту назначается некоторый внутренний айпишник.
2) Выделяемый реальный адрес (100.100.100.100) маршрутизируется на хост клиента (10.2.3.4)
командой route add 100.100.100.100 10.2.3.4
2.1) На клиенте прописываем внутренний айпи + шлюз + дополнительный реальный айпи.
3) запустить магическую хрень choparp (есть в портах ;-) )
choparp rl1 00:30:84:9e:91:d1 192.168.0.176/28
Это будет отвечать на все запросы из сегмента rl1 к сети 192.168.0.176/28 указанным мак-адресом. В моем случае - это мак rl1.
Для вашего случая, вероятно, это будет choparp rl1 00:30:84:9e:91:d1 100.100.100.100/32
--
В результате внешний маршрутизатор по arp-ответу увидит наличие в сегменте хоста реального айпи адреса, отправит на него (на наш маршрутизатор) пакет, наш маршрутизатор пакет получит, и в соответствии с таблицей маршрутизации отправит его в сторону хоста клиента 10.2.3.4. Обратные пакеты с хоста клиента тупо пойдут в сторону нашего маршрутизатора, и промаршрутизируются "как обычно".
Вариант для распечатки
(ok) on 13-Фев-11, 21:08 
