Прекрасно понимаю, что подобный вопрос мог подниматься уже не раз и не два. Если ткнете мордой лица в готовое решение - буду благодарен.Вопрос в следующем: в конторе стоит сервак на FreeBSD (6.x) с ipfw и natd. Ставил его практически по мануалам, поскольку в nix-системах разбираюсь весьма слабо. На входе имею канал с пятью внешними IP, выделенными ISP (использую только один). На внутреннем интерфейсе имею стандартную сетку 192.168.0.x. До последнего времени все работало как часы, спал как младенец. Никаких конфигов не привожу, поскольку они тривиальны до безобразия.
Но тут появились хитрые арендаторы, которым потребовался реальный IP для создания всяких там виртуальных каналов и прочей ip-телефонии. Я им готов отдать один из своих внешних адресов, поставить на роутер еще одну сетевуху, чтобы через нее весь трафик, идущий на этот IP, уплывал на их маршрутизатор. Проблема лишь в том, куда и что нужно для этого дописать?
Как я понимаю, необходимо добавить статический маршрут и, возможно, в ipfw добавить правила для пропуска трафика по этому ip/интерфейсу. Отсюда вытекает ламерский вопрос: надо ли интерфейсу, смотрящему в арендаторскую сетку, назначать какой-то ip (и должен ли он быть внешним), либо это надо расписать просто через имя интерфейса? И второй вопрос: а нужен ли вообще этот дополнительный интерфейс, или они свой трафик могут снимать с моего внутреннего интерфейса?
Прошу прощения за сумбурность изложения, как и говорил, опыта в данном вопросе у меня совсем немного.
> Но тут появились хитрые арендаторы, которым потребовался реальный IP для создания всяких
> там виртуальных каналов и прочей ip-телефонии.проще поднять отдельный NAT на реальном IP для таких арендаторов.
> проще поднять отдельный NAT на реальном IP для таких арендаторов.В том-то и дело, что им не нужен NAT. Вернее, им нужен IP до NAT.
>> проще поднять отдельный NAT на реальном IP для таких арендаторов.
> В том-то и дело, что им не нужен NAT. Вернее, им нужен
> IP до NAT.Тогда играйся с мостом - твой внешний интерфейс и отдельный линк на клиента.
Но при этом, ты не сможешь контролировать толщину клиентского канала.
>>> проще поднять отдельный 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. Обратные пакеты с хоста клиента тупо пойдут в сторону нашего маршрутизатора, и промаршрутизируются "как обычно".
мне вот кажется есть ещё 2 варианта на подумать:1) если у тебя 5 IP адресов - то тебе выделена сеть /29 - т.е. 8 адресов и её в принципе можно разделить на 2 по 4 адреса(/30). Одну себе оставишь, одну клиенту. Правда расход адресов приличный в этом случае.
2) поднять например PPPoE/PPtP - и выдать на конец туннеля реальный IP. ТОгда всего 1 адрес потратишь. Но надо поднимать PPPoE/PPtP сервер.
> 2) поднять например PPPoE/PPtP - и выдать на конец туннеля реальный IP.
> ТОгда всего 1 адрес потратишь. Но надо поднимать PPPoE/PPtP сервер.В таких случаях внутри системы формируется некоторое подобие proxy-arp, аналогичное тому, что я расписал в ответе выше. Создается новый канал к клиенту, сервер начинает отвечать на арп-запросы адреса клиента (proxy-arp-like), ну и поскольку появился новый канал - в него прописывается маршрут. Имеется все три составляющих - канал, маршрут в него, proxyarp-ответ.
Как оно работает на линухе, мне понятно, а как делается в случае pptp на FreeBSD - я не разбирался.
Поставить карточку в сервер, привязать ip алиасом к внешней карточки и прокинуть один ip на комп арендаторов, пусть они с ним бодаются...
> Поставить карточку в сервер, привязать ip алиасом к внешней карточки и
> прокинуть один ip на комп арендаторов, пусть они с ним бодаются...что же вы стесняетесь, расскажите чем отличается ситуация от текущей при наличии дополнительной карточки в сервере ?
пусть они с ним бодаются, придут на сайт опеннета и скажут - нам тут "прокинули" айпишник.... как нам.... ... Коллег не жаль ? )
Похоже я недооценил сложность проблемы. Я, честно говоря, думал, что подобные проброски в nix-системах - обычное явление. Наверное надо предложить им компромисный вариант:на моем роутере имею 5 внешних ip: 100.100.100.101-105 (oif)
моя внутренняя подсетка: 192.168.0.0/255 (iif1)
клиент: 192.168.1.0/255 (iif2), подразумевается, что его роутер будет 192.168.1.1
адрес 100.100.100.101 используется, как и сейчас, как dgw
все, что приходит на 100.100.100.102, выдавливаем на 192.168.1.1 (через natd), это будет типа их внешний ip
все, что идет из подсетки 192.168.1.0, выкидываем наружу через natd.Здесь снова 2 вопроса:
1. Надо ли прописывать для клиентской подсети отдельный маршрут, или ipfw сам на основании правил разберется куда завернуть пакет?
2. При получении пакета из клиентской подсети natd разберется, что его надо конвертнуть на 100.100.100.102 а не на 100.100.100.101?PS: спасибо за предложенные варианты решения. Однако мои познания в BSD не позволяют (пока) производить подобные насильственные действия на работающем роутере :).
> Похоже я недооценил сложность проблемы. Я, честно говоря, думал, что подобные проброски
> в nix-системах - обычное явление. Наверное надо предложить им компромисный вариант:
> все, что приходит на 100.100.100.102, выдавливаем на 192.168.1.1 (через natd), это будет
> типа их внешний ipИменно что "типа" :-)
На самом деле, надо более подробно все обговаривать, вдруг ваши арендаторы захотят взять все на себя, в результате вам единственное, что надо делать, это прокидывать ip и смотреть трафик, и то может быть просто ограничить их канал...
>[оверквотинг удален]
> маршрутизатор. Проблема лишь в том, куда и что нужно для этого
> дописать?
> Как я понимаю, необходимо добавить статический маршрут и, возможно, в ipfw добавить
> правила для пропуска трафика по этому ip/интерфейсу. Отсюда вытекает ламерский вопрос:
> надо ли интерфейсу, смотрящему в арендаторскую сетку, назначать какой-то ip (и
> должен ли он быть внешним), либо это надо расписать просто через
> имя интерфейса? И второй вопрос: а нужен ли вообще этот дополнительный
> интерфейс, или они свой трафик могут снимать с моего внутреннего интерфейса?
> Прошу прощения за сумбурность изложения, как и говорил, опыта в данном вопросе
> у меня совсем немного.DNAT + 802.1q
Снова привет всем.
Сделал примерно так, как описал в последнем посте: занес клиентов во внутреннюю подсеть на отдельный интерфейс (msk2 192.168.2.1, адрес их внутреннего роутера соответственно 192.168.2.2). Появилась проблема следующего характера. Когда я для ipfw прописываю правила nat-конвертации для этой подсети, выглядит это примерно так:${ipfw} add 113 divert ${client_port} ip from ${client_net} to any out xmit ${wan1}
то есть, все пакеты, проходящие из клиентской подсетки на внешний интерфейс, пропускаются через свой демон natd.
${ipfw} add 114 divert ${client_port} ip from any to ${client_wan_ip} in recv ${wan1}
этим правилом мы все пакеты, приходящие на внешний ip, выданный клиенту, заворачиваем через natd, запущенный для клиента.
Инет у клиента в этом случае не работает. Проблема в том (как я понял), что после пропуска через правило 113 система все исходящие от клиента пакеты после nat-преобразования выпускает с моего стандартного wan-ip-адреса, а не с адреса, назначенного клиенту. Соответственно, сервер в инете отвечает по нему же. Как только правило 114 меняю на:
${ipfw} add 114 divert ${client_port} ip from any to ${default_wan_ip} in recv ${wan1}
все сразу же начинает летать. В общем, "Париж открыт, но мне туда не надо". Есть ли какие-то мысли, как все исходящие запросы от клиента заворачивать на алиасный ip внешнего интерфейса, назначенный персонально клиенту?