LINUX.ORG.RU
Форум — Admin  

Проброс белых IP в локалку VLAN


0

1 
Есть необходимость пробросить белые IP в локалку, имеется switch TrendNet s2600i думаю сделать так
порт 1 тут роутер ip 192.168.0.0/24
порт 2 тут белые ip 85.94.210.120/29
порты с 9 по 16 смотрят в локалку
и того:
vlan_1 (пользователи) порты 9...16
vlan_2 (ext_ip) порт 1 + (9...16)
vlan_3 (int_ip) порт 2 + (9...16)
Не «закольцую» ли я роутер
Имеет ли сие право на жизнь, или есть другие, более изящные решения?

Или можно перетоптаться двумя vlan-ами
vlan_2 (ext_ip) порт 1 + (9...16)
vlan_3 (int_ip) порт 2 + (9...16)

Вот схема



Последнее исправление: aksi2000 (всего исправлений: 1)
← Ссылки на проксируемом адресе
Подсчет тафика с пом. доп. цепочек в iptables, 2 примера (рабочий и не рабочий) →

Роутер не закольцуешь (что б ты под этим не подразумевал).

Все пользователи должны иметь доступ к обеим подсетям или «пользователи» делятся на две группы?
Если первое, то нафиг тебе это и роутер? Eсли второе — два VLANа, но я бы завёл на роутере третий интерфейс и в «белый» VLAN затолкал бы его и «белых» пользователей.

frob ★★★★★
()
Последнее исправление: frob (всего исправлений: 1)
Ответ на: комментарий от frob

На самом деле идея заключалась в том, чтоб по одному кабелю пустить и белые и серые ip, что если, подключается новый пользователь не тащить от серверной до него новый кабель, а воспользоваться уже проложенной сетью. Просто пулы белых ip лежат в разных подсетях и как их свести вместе пока не придумал.

aksi2000
() автор топика

Вы говорите про Port-based VLAN'ы ? Зачем нужен vlan_1 не понятно.

Да и в целом не понятно, что вы хотите добится от vlan'ов. Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса. Мне пока вобще не понятна роль маршрутизатора, как локалка будет изолироватся от интернета?

чтоб по одному кабелю пустить и белые и серые ip

Где на схеме этот кабель?

mky ★★★★★
()
Ответ на: комментарий от mky

Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса

Не понимаю как, внешний интерфейс в интернет смотрит, внутренний в локал

Мне пока вобще не понятна роль маршрутизатора, как локалка будет изолироватся от интернета?

Им и будет, он интернеты раздает, оно сейчас так и работает, только без вланов и проброса белых ip. Если ваш вопрос звучал в таком ключе..... то, наверное никак

Где на схеме этот кабель?

Самый нижний (порты 9...16) --> пользователи

aksi2000
() автор топика
Ответ на: комментарий от frob

но я бы завёл на роутере третий интерфейс и в «белый» VLAN затолкал бы его и «белых» пользователей

я об этом думал, но вот в чем фишка (возможно не догоняю) допустим
eth0 105.54.32.40/29
eth1 192.168.3.1/24
в этом случае алиас на eth1 аля
eth1:1 105.54.32.41/29
и получаем на выходе чистые 3 ip -это понятно, ноа что если на eth0 болтается второй пул адресов 105.54.50.120/29

aksi2000
() автор топика
Ответ на: комментарий от aksi2000

А ну и как бы из серверной что белые ip что серые идут по одному и тому же кабелю
вот как раз те порты 9...16 смотрят на этажи здания где стоят неуправляемые свичи

aksi2000
() автор топика
Ответ на: комментарий от aksi2000

Кажется пришла пора вернуться на первую клетку и разобраться зачем всё это нужно не в терминах «как бы мне пробросить белые IP».

Задача-то какая?

frob ★★★★★
()
Ответ на: комментарий от aksi2000

Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса

Не понимаю как, внешний интерфейс в интернет смотрит, внутренний в локал

Arp-запрос от порта 9 придёт и в порт 1 и в порт 2 (а там через неуправляемый свич и на второй интерфейс маршрутизатора).

Пока не понятно, как именно вам приходят эти пулы адресов. Лучше бы, чтобы провайдер предоставлял вам их через прописывания у себя маршрутов через ваш маршрутизатор. Если же эти пулы прописаны прямо на интерфейс его маршрутизатора/свича, то на вашем маршрутизаторе вам нужен proxy arp.

Вобще, сейчас в вашей схеме получается, что если любой из пользователей возмёт себе «белый»-ip адрес, то он спокойно получит доступ в инет?

mky ★★★★★
()
Ответ на: комментарий от mky

Лучше бы, чтобы провайдер предоставлял вам их через прописывания у себя маршрутов через ваш маршрутизатор. Если же эти пулы прописаны прямо на интерфейс его маршрутизатора/свича, то на вашем маршрутизаторе вам нужен proxy arp.

у нас стоит оборудование прова с него и сыпятся ip адреса

Вобще, сейчас в вашей схеме получается, что если любой из пользователей возмёт себе «белый»-ip адрес, то он спокойно получит доступ в инет?

да именно так, хоть оно и неправильно

aksi2000
() автор топика
Ответ на: комментарий от aksi2000

Ну, давай ещё разок попробуем... Зачем. Кому-то. Белый. IP.?

Чем не устраивает статическая трансляция адресов?
Что мешает сделать транк между свичом и роутером?

«В чём соль вопроса — в том и ответ.»

frob ★★★★★
()
Ответ на: комментарий от aksi2000

у нас стоит оборудование прова с него и сыпятся ip адреса

Ну вот и делайте proxy-аrp на маршрутизаторе, если, конечно, он потянет нагрузку от «белых»-ip адресов. Тогда все адреса будут проходить через маршрутизатор, там хотя бы можно будет сделать привязку адреса к mac-адресу клиента или сделать, чтобы «белые» ip адреса выдавались только через vpn (pptp или openvpn).

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от frob

Зачем. Кому-то. Белый. IP.?

маленький интернет проваидинг

Чем не устраивает статическая трансляция адресов? Что мешает сделать транк между свичом и роутером?

только начинаю в этом разбираться, плохо понимаю о чем вы =(
статическая трансляция, транк

aksi2000
() автор топика
Ответ на: комментарий от mky

Ну вот и делайте proxy-аrp на маршрутизаторе, если, конечно, он потянет нагрузку от «белых»-ip адресов. Тогда все адреса будут проходить через маршрутизатор, там хотя бы можно будет сделать привязку адреса к mac-адресу клиента

копать значит в сторону arp-proxy ага, или то, что выше советовали?

aksi2000
() автор топика
Ответ на: комментарий от aksi2000

Там много выше советовали, но если говорить о создании на вашем маршрутизаторе ещё одного интерфейса, то всё одно, сначала нужно добиться, что от провайдера трафик ко все ip-адресам сети 85.94.210.120/29 щёл через маршрутизатор. А раз провайдер не будет прописывать у себя маршрут через ваш маршрутизатор, значит proxy arp.

А уже дальше возможны различные варианты, но с моей точки зрения, если сеть построена на неуправляемых свичах, то «белые» ip-адреса раздавать в ней только по VPN (с авторизацией).

И раз каждый из портов (9...16) свича s2600i нагружен неуправляемым свичём и на этом порту могут быть как «серые», так и «белые» адреса, то особого смысла в VLAN'ах нет. В этой схеме, единственное в чём могут помощь VLAN'ы это сделать на маршрутизаторе 1 физический интерфейс, порт которого видит и провайдера и пользователй, а порт провайдера и порты пользователей разнести по разным VLAN.

mky ★★★★★
()
Ответ на: комментарий от mky

Усугубляется тем, что у меня есть еще и второй пул из другой подсети 85.94.200.100/29 и как вот это все сводить....

aksi2000
() автор топика
Ответ на: комментарий от aksi2000

Сводить по одной схеме.

Сначала включаете на интерфейсе, который смотрит в свич провайдера proxy arp:

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Потом прописываете маршруты ко всем белым сетям через другие интерфейсы:

ip route add 85.94.210.120/29 dev eth1

ip route add 85.94.200.100/29 dev eth1

Если вы хотите назначить маршрутизатору какой-либо из «белых» адресов, то даёте его на eth0 с суффиксом /32, допустим:

ip addr add 85.94.210.122/32 dev eth0

Маршрут по умолчанию пишите (если надо) со словом «onlink»:

ip route add default via 85.94.210.121 dev eth1 onlink src 85.94.210.122

В результате на arp-запросы для пулов белых ip-адресов маршрутизатор будет отвечать своит mac-адресом, но не будте считать, что эти ip-адреса пренадлежат ему. Получив пакет для «белого» ip-адреса он будет искать его на eth1.

mky ★★★★★
()
Ответ на: комментарий от aksi2000

Добавь к тому что сказал mky транк между роутером и свичом и отдельный VLAN на каждого «белого» пользователя.

frob ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Ссылки на проксируемом адресе
Admin
Подсчет тафика с пом. доп. цепочек в iptables, 2 примера (рабочий и не рабочий) →