Короткое примечание:
Хорошо я думаю, что мог бы иметь решение, но должен доказать его сначала.
Относительно NAT на Hardwarerouter к каждой строке WAN, кажется, только делают NAT для его собственной подсети, таким образом, я должен буду просто сделать, чтобы они сделали NAT на других подсетях также...
Соединит ответ когда его работа.
Спасибо.
Я настраиваю Xen-гипервизор для замены 3 из моих старых машин с этим.
Основой является Поршень Dell PowerEdge 2950 16GB, который содержит двух физических Надежных людей сервера Ubuntu NICs 14,04 всех сделанных обновлений.
Моя установка является немного странной, но у меня есть 4 сети на моей стороне интранет, которая разделена на
192.168.0.0/26 - all routing devices, accesspoints and servers
192.168.0.64/26 - all office and top prio devices
192.168.0.128/26 - entertainment stuff and kids
192.168.0.192/26 - low prio and open dhcp area for guests
это было то, потому что я должен выключить пропускную способность на гостях и низком материале prio для достаточно резервирования для работы. Все сделанные с tc и iptables. Это все еще активно на старом Internetline, который только имеет 0,5MBits/s DL и 96kBit/s УЛ., на которой мы придерживались в течение 13 лет теперь.
С прошлой недели я поместил LTE (4G) 50MBit/s DL 10MBit/s Строка УЛ. в дополнение к старой для ускорения ежедневной работы. НО 4G основана на transferpackages 30 ГБ и может быть расширена на 30 ГБ для дополнительных затрат. Так как моя старая строка будет оставаться в течение по крайней мере еще 2 лет, пока Транкинг SIP не будет avaiable для меня, я хочу использовать старую неограниченную строку для всего вида интенсивных вещей как обновления и большие загрузки, которые не должны быть готовы в установленное время или резервные копии ftp и т.д.
до сих пор это - моя ситуация.
Теперь я хочу к созданному поле Linux, которое сделает следующее около некоторого другого общего материала как ЛАМПА и Почта и т.д.
сохраните мои 4 сети и сохраните их managable как, они были прежде для резервирования пропускной способности для лучшего Prio как прежде, но теперь для двух строк.
используйте аппаратный маршрутизатор/шлюз для каждой строки, которые делают NAT, и Коммутируемый доступ (имейте wrt54gl для медленной абонентской линии DSL и Huawei B593u-12 для стороны LTE), предпочтительный, они должны быть на 192.168.1.0/24, но я объясню это позже.
таким образом, моя установка похожа на это:
LTE (B593u-12)
192.168.1.20
DELL2950 Dom-0 Clients
(eth1 192.168.1.5) (192.168.0.XXX/26)
(Xenbr0:X 192.168.0.XXX/26)
DSL (WRT54GL)
192.168.1.21
теперь нам нужна некоторая маршрутизация от 192.168.1.0/24 до различных сетей 192.168.0.0/26, 192.168.0.64/26, 192.168.0.128/26, 192.168.0.192/26, которые все находятся на Xenbr0 (192.168.0.5), Xenbr0:1 (192.168.0.105), Xenbr0:2 (192.168.0.175), Xenbr0:3 (192.168.0.205)
У меня есть проблема для установления статических маршрутов к каждому маршрутизатору WAN, в котором я не нуждаюсь к NAT на моем Поле Linux, поэтому прямо сейчас я поместил 4 дюйм/с на каждый маршрутизатор WAN, чтобы иметь его доступный в каждой сети.
Ядро ip_forwand включено! Я добавил полный, ПРИНИМАЮТ политику в отношении iptables ВПЕРЕД, ВВОДЯТ и т.д. таблицы, чтобы удостовериться, что это не отбросит никого в течение времени, я сортирую маршрутизацию на iproute2 стороне.
iptables-nvL
Chain INPUT (policy ACCEPT 5418K packets, 762M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT 1406K packets, 107M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out vif4.0 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif4.0 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out vif3.0 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif3.0 --physdev-is-bridged
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 5215K packets, 9072M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68
Xen сделал его vif и virbr0 дополнения устройства в таблицах, но они не интересны для моей проблемы afaik.
Включит iptable наборы позже и будет нуждаться в подсказке на них также, если это возможно. Действительно ли ядро в состоянии направить между всеми мостами без дополнительной конфигурации, или я пропускал что-то здесь?
IP выставочная основная таблица маршрута
default via 192.168.1.20 dev eth1
192.168.0.0/26 dev xenbr0 proto kernel scope link src 192.168.0.5
192.168.0.64/26 dev xenbr0 proto kernel scope link src 192.168.0.105
192.168.0.128/26 dev xenbr0 proto kernel scope link src 192.168.0.175
192.168.0.192/26 dev xenbr0 proto kernel scope link src 192.168.0.205
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
224.0.0.0/4 dev xenbr0 scope link
и подобный на iproute2 для основанной на правиле маршрутизации:
IP выставочная таблица LTE маршрута
default via 192.168.1.20 dev eth1
192.168.0.0/26 dev xenbr0 proto kernel scope link src 192.168.0.5
192.168.0.64/26 dev xenbr0 proto kernel scope link src 192.168.0.105
192.168.0.128/26 dev xenbr0 proto kernel scope link src 192.168.0.175
192.168.0.192/26 dev xenbr0 proto kernel scope link src 192.168.0.205
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5
IP выставочная таблица DSL маршрута
default via 192.168.1.21 dev eth1
192.168.0.0/26 dev xenbr0 proto kernel scope link src 192.168.0.5
192.168.0.64/26 dev xenbr0 proto kernel scope link src 192.168.0.105
192.168.0.128/26 dev xenbr0 proto kernel scope link src 192.168.0.175
192.168.0.192/26 dev xenbr0 proto kernel scope link src 192.168.0.205
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5
И насколько я знаю, что должен добавить статические маршруты назад от каждого маршрутизатора WAN до Linuxbox так, чтобы он мог найти 192.168.0.0/26 и так далее...
Это возможно на WRT54GL благодаря Проекту DD-WRT, и на LTE один я получил корневой доступ и настроил сценарий запуска, который может сделать подобные вещи к полю как, я могу на DD-WRT.
таким образом, я попробовал бы это на каждом устройстве:
route add -net 192.168.0.0 mask 255.255.255.192 gw 192.168.1.5
route add -net 192.168.0.64 mask 255.255.255.192 gw 192.168.1.5
route add -net 192.168.0.128 mask 255.255.255.192 gw 192.168.1.5
route add -net 192.168.0.192 mask 255.255.255.192 gw 192.168.1.5
Каждый клиент заставляет подходящий IP Dom-0 относительно их сети достигать Dom-0 как стандартного шлюза. Таким образом, это хорошо работает. Весь SMB и Доли CIFS доступны во всей Инфраструктуре.
теперь я могу сделать следующее: проверьте с помощью ping-запросов Dom-0 от каждой оболочки маршрутизаторов WAN (и eth0 и Xenbr0), проверяют с помощью ping-запросов каждый маршрутизатор WAN от любого устройства в другом 0. Сети XXX/26.
так, очевидно, маршрутизация себя, кажется, работают.
НО так или иначе я не могу выяснить, почему я не могу соединиться с Интернетом от клиентов?! Само Поле Linux онлайн в этом сценарии и может получить доступ к обеим строкам и Интернету NATted каждого маршрутизатора WAN.
Таким образом, здесь я теперь. Считали миллион и одна страница о гнинии, статических маршрутах и всем виде.
в конце я хочу смочь использовать IFB на eth1 для формирования входящего трафика вниз к сумме набора на каждой строке для различных правил как подсеть, l7-метка, src и dst IP и т.д. для выбора, которые выравнивают сервис, будет использовать и сколько bandwith это доберется через tc и iptables.
моя установка моста хорошо?
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr0 8000.001d0904bbb4 yes eth0
vif3.0
vif3.0-emu
vif4.0
vif4.0-emu
vif3 и vif4 являются моими Гостями Xen (используйте их для разработки на mysql и т.д.), они могут получить доступ к целой сети включая все Доли и могут проверить с помощью ping-запросов каждое устройство в сети. Так примерно я думаю, что это должно быть в порядке. Не уверенный в той Опции STP...
Я немного смущен прямо сейчас, так как я не вижу, что проблема... надеется, что некоторые из Вас люди знают это лучше ;)
приветствует из Германии...