Есть необходимость пробросить белые 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)
Роутер не закольцуешь (что б ты под этим не подразумевал).
Все пользователи должны иметь доступ к обеим подсетям или «пользователи» делятся на две группы?
Если первое, то нафиг тебе это и роутер?
Eсли второе — два VLANа, но я бы завёл на роутере третий интерфейс и в «белый» VLAN затолкал бы его и «белых» пользователей.
На самом деле идея заключалась в том, чтоб по одному кабелю пустить и белые и серые ip, что если, подключается новый пользователь не тащить от серверной до него новый кабель, а воспользоваться уже проложенной сетью. Просто пулы белых ip лежат в разных подсетях и как их свести вместе пока не придумал.
Вы говорите про Port-based VLAN'ы ? Зачем нужен vlan_1 не понятно.
Да и в целом не понятно, что вы хотите добится от vlan'ов. Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса. Мне пока вобще не понятна роль маршрутизатора, как локалка будет изолироватся от интернета?
Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса
Не понимаю как, внешний интерфейс в интернет смотрит, внутренний в локал
Мне пока вобще не понятна роль маршрутизатора, как локалка будет изолироватся от интернета?
Им и будет, он интернеты раздает, оно сейчас так и работает, только без вланов и проброса белых ip. Если ваш вопрос звучал в таком ключе..... то, наверное никак
но я бы завёл на роутере третий интерфейс и в «белый» 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
А ну и как бы из серверной что белые ip что серые идут по одному и тому же кабелю
вот как раз те порты 9...16 смотрят на этажи здания где стоят неуправляемые свичи
Маршрутизатор будет получать arp-запросы от локалки на оба интерфейса
Не понимаю как, внешний интерфейс в интернет смотрит, внутренний в локал
Arp-запрос от порта 9 придёт и в порт 1 и в порт 2 (а там через неуправляемый свич и на второй интерфейс маршрутизатора).
Пока не понятно, как именно вам приходят эти пулы адресов. Лучше бы, чтобы провайдер предоставлял вам их через прописывания у себя маршрутов через ваш маршрутизатор. Если же эти пулы прописаны прямо на интерфейс его маршрутизатора/свича, то на вашем маршрутизаторе вам нужен proxy arp.
Вобще, сейчас в вашей схеме получается, что если любой из пользователей возмёт себе «белый»-ip адрес, то он спокойно получит доступ в инет?
Лучше бы, чтобы провайдер предоставлял вам их через прописывания у себя маршрутов через ваш маршрутизатор. Если же эти пулы прописаны прямо на интерфейс его маршрутизатора/свича, то на вашем маршрутизаторе вам нужен proxy arp.
у нас стоит оборудование прова с него и сыпятся ip адреса
Вобще, сейчас в вашей схеме получается, что если любой из пользователей возмёт себе «белый»-ip адрес, то он спокойно получит доступ в инет?
у нас стоит оборудование прова с него и сыпятся ip адреса
Ну вот и делайте proxy-аrp на маршрутизаторе, если, конечно, он потянет нагрузку от «белых»-ip адресов. Тогда все адреса будут проходить через маршрутизатор, там хотя бы можно будет сделать привязку адреса к mac-адресу клиента или сделать, чтобы «белые» ip адреса выдавались только через vpn (pptp или openvpn).
Ну вот и делайте proxy-аrp на маршрутизаторе, если, конечно, он потянет нагрузку от «белых»-ip адресов. Тогда все адреса будут проходить через маршрутизатор, там хотя бы можно будет сделать привязку адреса к mac-адресу клиента
копать значит в сторону arp-proxy ага, или то, что выше советовали?
Там много выше советовали, но если говорить о создании на вашем маршрутизаторе ещё одного интерфейса, то всё одно, сначала нужно добиться, что от провайдера трафик ко все ip-адресам сети 85.94.210.120/29 щёл через маршрутизатор. А раз провайдер не будет прописывать у себя маршрут через ваш маршрутизатор, значит proxy arp.
А уже дальше возможны различные варианты, но с моей точки зрения, если сеть построена на неуправляемых свичах, то «белые» ip-адреса раздавать в ней только по VPN (с авторизацией).
И раз каждый из портов (9...16) свича s2600i нагружен неуправляемым свичём и на этом порту могут быть как «серые», так и «белые» адреса, то особого смысла в VLAN'ах нет. В этой схеме, единственное в чём могут помощь VLAN'ы это сделать на маршрутизаторе 1 физический интерфейс, порт которого видит и провайдера и пользователй, а порт провайдера и порты пользователей разнести по разным VLAN.
Сначала включаете на интерфейсе, который смотрит в свич провайдера 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.