- Доступ ко второму внешнему ip из локальной сети,
 Andrey, 22:24 , 11-Сен-14 (1)
> Есть 3 белых ip адреса(xx.xx.xx.120/29).
> На 1(хх.хх.хх.122) ip настроен нат из локальной сети(192.168.0.0/24)(Vlan1)
> Остальные 2(хх.хх.хх.123,хх.хх.хх.124 ) проброшены на коммутатор при помощи ip unnumbered
> (Vlan101 и Vlan102).
> Для проброшенных ip хх.хх.хх.123 и хх.хх.хх.124 маршрут по умолчанию хх.хх.хх.122.
> Интернет они видят. Но из локальной сети не видно двух внешних ip.
> Нужно из сети 192.168.0.0/24 видеть xx.xx.xx.123 и xx.xx.xx.124 помогите пожалуйста.
> При трасировке из локалки маршрут идет через хх.хх.хх.121(маршрут по умолчанию для внешней
> подсети).Принимайте канал свитчем. Можно тем-же самым 2960, отдельным VLAN. Можно любым другим свитчем, даже неуправляемым, SOHO формата. И раздавайте 3 IP на все ваши устройства. Так как сделано у вас - это: а)не правильно; б) занимает ресурсы вашего маршрутизатора. Сделаете как надо - будет вам счастье и нормально управляемая сеть. То, что есть сейчас - кошмар сетевого администратора и работать по заявленным требованиям не будет.
- Доступ ко второму внешнему ip из локальной сети, Zentor, 23:46 , 11-Сен-14 (2)
> Принимайте канал свитчем. Можно тем-же самым 2960, отдельным VLAN. Можно любым другим
> свитчем, даже неуправляемым, SOHO формата.Правильно я понимаю, что так сделать будет правильнее?
Канал с внешним IP входит в 2960 делится на 3 влана, создаем 3 саба, присваеваем например vlan100, vlan101, vlan102 и далее тот который для локалки(где нужен нат) пропускаю через маршрутизатор и возвращаю на этот же коммутатор, а остальные соответственным вланам? И раздавайте 3 IP на
> все ваши устройства. Так как сделано у вас - это: а)не
> правильно;б) занимает ресурсы вашего маршрутизатора. Сделаете как надо - будет
> вам счастье и нормально управляемая сеть. То, что есть сейчас -
> кошмар сетевого администратора и работать по заявленным требованиям не будет. Если понадобится какой-то из ip прокинуть через роутер(например появится внутренняя сеть которую нужно будет натить в интернет через другой ip) как лучше это сделать? использовать сабинтерфейсы с теми же вланами?
Для чего нужен ip unnumbered? для того, чтобы раздать нескольким пользователям прямые ip при этом не выделяя каждому, например, 30 подсеть ? Тоесть чтобы заработала представленная мной конфига нужен еще один ip из этой 29 сети и поставить локалку за него?
В локалке всего 40 пользователей, хочу понять как лучше использовать эти пушки.
- Доступ ко второму внешнему ip из локальной сети, Andrey, 10:52 , 12-Сен-14 (3)
> Правильно я понимаю, что так сделать будет правильнее?
> Канал с внешним IP входит в 2960 делится на 3 влана, создаем
> 3 саба, присваеваем например vlan100, vlan101, vlan102 и далее тот который
> для локалки(где нужен нат) пропускаю через маршрутизатор и возвращаю на этот
> же коммутатор, а остальные соответственным вланам?Зачем? Вы понимаете что такое бродкастовый домен?
У вас провайдер предоставляет подсеть из 4 IP (маска 29 бит), один из которых шлюз с IP хх.хх.хх.121, который находится на стороне провайдера. У вас остаются 3 рабочих IP. Один вы используете под внешний интерфейс Cisco. Оставшиеся 2 можно использовать для NAT или для других устройств (www, smtp сервера или еще под что-то). > Если понадобится какой-то из ip прокинуть через роутер(например появится внутренняя сеть
> которую нужно будет натить в интернет через другой ip) как лучше
> это сделать? использовать сабинтерфейсы с теми же вланами?
> Для чего нужен ip unnumbered? для того, чтобы раздать нескольким пользователям прямые
> ip при этом не выделяя каждому, например, 30 подсеть ? Тоесть
> чтобы заработала представленная мной конфига нужен еще один ip из этой
> 29 сети и поставить локалку за него?
> В локалке всего 40 пользователей, хочу понять как лучше использовать эти пушки. Найдите на сайте cisco тему про NAT на маршрутизаторах.
Если пользователю нужен будет внешний IP - либо запихиваете его в VLAN в котором у вас будет так-же работать внешний интерфейс вашего маршрутизатора, либо строите ему NAT 1:1 на внешний IP на Cisco.
- Доступ ко второму внешнему ip из локальной сети, elk_killa, 07:41 , 15-Сен-14 (5)
> Для чего нужен ip unnumbered? для того, чтобы раздать нескольким пользователям прямые
> ip при этом не выделяя каждому, например, 30 подсеть ? Тоесть
> чтобы заработала представленная мной конфига нужен еще один ip из этой
> 29 сети и поставить локалку за него?
> В локалке всего 40 пользователей, хочу понять как лучше использовать эти пушки. ip unnumbered нужен только для поднятия протокола на интерфейсе, не затрачивая адресов, не более. Это никак не помогает "пробрасывать", на эти сабы можно с тем же успехом навесить любые адреса. Вся ваша схема насилует проц роутера, насильно пихая траффик в интерфейсы через PBR и route /32 против правил обычной работы сети. Когда возникнет необходимость еще что-то прикрутить, все это накроется медным тазом. Если нет необходимости контролировать траффик "выставленных" хостов, как уже посоветовали, засуньте роутер и эти хосты в один влан с /29 сетью. Если обязательно нужно через роутер(firewall, netflow etc), то создайте для хостов "серую dmz" и тренслируйте статически серый адрес в белый.
- Доступ ко второму внешнему ip из локальной сети, ShyLion, 06:39 , 15-Сен-14 (4)
> Остальные 2(хх.хх.хх.123,хх.хх.хх.124 ) проброшены на коммутатор при помощи ip unnumberedЛинковочных адресов /30 нет? > interface GigabitEthernet0/2.101
> ip policy route-map SFT
> interface GigabitEthernet0/2.102
> ip policy route-map SFT
> access-list 2 permit xx.xx.xx.120 0.0.0.7
> route-map SFT permit 200
> match ip address 2
> set ip next-hop xx.xx.xx.121
> ! Не работает из-за этого.
Пакеты до хостов с реальными IP доходят, а обратно роутером принудительно отправляются к провайдеру, который о ваших внутренних сетях ничего не знает. В полиси нужно использовать extended ACL и вначале должны идти исключения (deny) для локального траффика. Ну и PBR это большой привет процессору. Если там будет реальный траффик - проц загнется. ЗЫ: Ну и как правильно заметили, лучше не изобретать велосипед. Суете линк с провайдером в вилан, и приземляете в нем хосты с реальным IP наравне с роутером.
- Доступ ко второму внешнему ip из локальной сети, Zentor, 00:36 , 17-Сен-14 (6)
> ЗЫ: Ну и как правильно заметили, лучше не изобретать велосипед. Суете линк
> с провайдером в вилан, и приземляете в нем хосты с реальным
> IP наравне с роутером.Уважаемые гуру! Я переделал всю конфигу исходя из ваших советов, но протестировал пока только в виртуальной среде - работает, все кого надо - видят, кого не надо - не видят. Подскажите корректная ли эта конфига? сети в влане 110 и 111 разделил RACL, обе сетки натятся на 2 разных IP
третий белый ip - уходит на устройство прямо из коммутатора через Ethernet1/0. Роутер:
interface Ethernet0/0
ip address хх.хх.хх.122 255.255.255.0
ip access-group FIREWALL in
ip nat outside
ip inspect FW out
ip virtual-reassembly in
!
interface Ethernet0/1
no ip address
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/1.110 (внутренняя сеть)
encapsulation dot1Q 110
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/1.111 (DMZ)
encapsulation dot1Q 111
ip address 192.168.10.1 255.255.255.0
ip access-group DMZ_in in
ip access-group DMZ_out out
ip nat inside
ip virtual-reassembly in
! ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip nat pool POOL_dmz хх.хх.хх.124 хх.хх.хх.124 netmask 255.255.255.0
ip nat inside source list NAT interface Ethernet0/0 overload
ip nat inside source list NAT_dmz pool POOL_dmz overload
ip route 0.0.0.0 0.0.0.0 хх.хх.хх.121
! ip access-list extended DMZ_in
evaluate inav_lan
deny ip 192.168.10.0 0.0.0.255 192.168.0.0 0.0.0.255
permit ip any any
ip access-list extended DMZ_out
permit tcp 192.168.0.0 0.0.0.255 any reflect inav_lan timeout 300
permit icmp 192.168.0.0 0.0.0.255 any reflect inav_lan timeout 300 ip access-list extended FIREWALL
permit ip any any
ip access-list extended NAT
permit ip 192.168.0.0 0.0.0.255 any
ip access-list extended NAT_dmz
permit ip 192.168.10.0 0.0.0.255 any
!
!
! Конфига коммутатора: interface Ethernet0/0
switchport access vlan 100
duplex auto
!
interface Ethernet0/1
switchport access vlan 100
duplex auto
!
interface Ethernet0/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 110,111
switchport mode trunk
duplex auto
!
interface Ethernet0/3
switchport access vlan 110
duplex auto
!
interface Ethernet1/0
switchport access vlan 100
duplex auto
!
interface Ethernet1/1
switchport access vlan 111
duplex auto
!
interface Ethernet1/2
switchport access vlan 110
duplex auto
!
- Доступ ко второму внешнему ip из локальной сети, ShyLion, 07:19 , 17-Сен-14 (7)
> Уважаемые гуру! Я переделал всю конфигу исходя из ваших советов, но протестировал
> пока только в виртуальной среде - работает, все кого надо -
> видят, кого не надо - не видят.Вопрос: должны ли хосты в DMZ быть доступны по реальным адресам?
Если да, то нужно убрать динамический нат с пулом и для каждого хоста отдельный статический нат: ip nat inside static 192.168.10.x xxx.xxx.xxx.X
ip nat inside static 192.168.10.y xxx.xxx.xxx.Y
- Доступ ко второму внешнему ip из локальной сети, Zentor, 11:50 , 17-Сен-14 (8)
>> Уважаемые гуру! Я переделал всю конфигу исходя из ваших советов, но протестировал
>> пока только в виртуальной среде - работает, все кого надо -
>> видят, кого не надо - не видят.
> Вопрос: должны ли хосты в DMZ быть доступны по реальным адресам?
> Если да, то нужно убрать динамический нат с пулом и для каждого
> хоста отдельный статический нат:
> ip nat inside static 192.168.10.x xxx.xxx.xxx.X
> ip nat inside static 192.168.10.y xxx.xxx.xxx.Y Да! Только белый ip для DMZ только один, поэтому придется делать так: ip nat inside source static tcp 192.168.10.10 80 xx.xx.xx.124 80 extendable ip nat inside source static tcp 192.168.10.100 smtp xx.xx.xx.124 smtp extendable К концу недели протестирую на реальном железе!
Спасибо за помощь!
- Доступ ко второму внешнему ip из локальной сети, Zentor, 10:00 , 23-Сен-14 (9)
>> Уважаемые гуру! Я переделал всю конфигу исходя из ваших советов, но протестировал
>> пока только в виртуальной среде - работает, все кого надо -
>> видят, кого не надо - не видят.
> Вопрос: должны ли хосты в DMZ быть доступны по реальным адресам?
> Если да, то нужно убрать динамический нат с пулом и для каждого
> хоста отдельный статический нат:
> ip nat inside static 192.168.10.x xxx.xxx.xxx.X
> ip nat inside static 192.168.10.y xxx.xxx.xxx.Y Моя конфига работает на реальном железе! Спасибо за помощь!
Теперь ситуация усложнилась. Есть роутер с Yota. Она работает не стабильно но часто быстрее основного канала, поэтому задача - включить роутер во внутреннюю сеть и, чтобы заработал основной канал через нее. А DMZ должен ходить так же через основного прова. Тут как раз включаются ip sla и route-map.
В виртуальной среде получилась вот такая конфига. Помня рекомендации о том, что PBR это трудно для проца, прощу посмотреть и порекомендовать как быть в данной конфиге. В DMZ будет почтовый сервер и слабонагруженный http. (проброс портов на них еще не настроен снаружи).
Подсеть DMZ правильно натится только если ему сделан свой route-map. track 1 ip sla 1 reachability
delay down 5 up 5
!
track 2 ip sla 2 reachability
delay down 5 up 5
!
!
interface Ethernet0/0
ip address xx.xx.xx.122 255.255.255.0
ip access-group FIREWALL in
ip nat outside
ip inspect FW out
ip virtual-reassembly in
!
interface Ethernet0/1
no ip address
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/1.110
encapsulation dot1Q 110
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip policy route-map yota
!
interface Ethernet0/1.111
encapsulation dot1Q 111
ip address 192.168.10.1 255.255.255.0
ip access-group DMZ_in in
ip access-group DMZ_out out
ip nat inside
ip virtual-reassembly in
ip policy route-map dmz
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
ip forward-protocol nd
!
!no ip http server
no ip http secure-server
ip nat pool POOL_F xx.xx.xx.124 xx.xx.xx.124 netmask 255.255.255.0
ip nat inside source list NAT interface Ethernet0/0 overload
ip nat inside source list NAT_F pool POOL_F overload
ip route 0.0.0.0 0.0.0.0 192.168.0.111 track 1
ip route 0.0.0.0 0.0.0.0 xx.xx.xx.121 2 track 2
ip route 0.0.0.0 0.0.0.0 xx.xx.xx.121
ip route 8.8.8.8 255.255.255.255 192.168.0.111
ip route 8.8.4.4 255.255.255.255 xx.xx.xx.121
!
ip access-list extended DMZ_in
evaluate inav_lan
deny ip 192.168.10.0 0.0.0.255 192.168.0.0 0.0.0.255
permit ip any any
ip access-list extended DMZ_out
permit tcp 192.168.0.0 0.0.0.255 any reflect inav_lan timeout 300
permit icmp 192.168.0.0 0.0.0.255 any reflect inav_lan timeout 300
ip access-list extended FIREWALL
permit ip any any
ip access-list extended NAT
permit ip 192.168.0.0 0.0.0.255 any
ip access-list extended NAT_F
permit ip 192.168.10.0 0.0.0.255 any
ip access-list extended pbr
permit ip 192.168.0.0 0.0.0.255 any
!
ip sla 1
icmp-echo 8.8.8.8 source-interface Ethernet0/1.110
threshold 2000
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 8.8.4.4 source-interface Ethernet0/0
threshold 2000
frequency 10
ip sla schedule 2 life forever start-time now
!
route-map yota permit 10
match ip address pbr
set ip next-hop verify-availability 192.168.0.111 1 track 1
set ip next-hop verify-availability xx.xx.xx.121 2 track 2
!
route-map dmz permit 10
match ip address NAT_F
set ip default next-hop xx.xx.xx.121
!
- Доступ ко второму внешнему ip из локальной сети, ShyLion, 11:06 , 25-Сен-14 (10)
> Теперь ситуация усложнилась. Есть роутер с Yota. Она работает не стабильно но Один роутер и два инета - вечная головная боль и полиси-роутинг. Используй полиси там, где нагрузка будет меньше. Нормально решается вторым роутером. Или линуксами какими нибудь.
- Доступ ко второму внешнему ip из локальной сети, Andrey, 11:38 , 25-Сен-14 (11)
>>> Уважаемые гуру! Я переделал всю конфигу исходя из ваших советов, но протестировал
>>> пока только в виртуальной среде - работает, все кого надо -
>>> видят, кого не надо - не видят.
> Моя конфига работает на реальном железе! Спасибо за помощь!
> Теперь ситуация усложнилась. Есть роутер с Yota. Она работает не стабильно но
> часто быстрее основного канала, поэтому задача - включить роутер во внутреннюю
> сеть и, чтобы заработал основной канал через нее. А DMZ должен
> ходить так же через основного прова. Тут как раз включаются ip
> sla и route-map....
> В виртуальной среде получилась вот такая конфига.
> прощу посмотреть и порекомендовать как быть
> в данной конфиге. Хм... Попытка переложить ответственность со своей головы на сообщество? Может вам лучше открыть вакансию системного архитектора/инженера? Он будет предварительно проверять все конфигурации перед внедрением. И у вас будет человек, который будет отвечать за все косяки.
|
Версия для распечатки
Доступ ко второму внешнему ip из локальной сети, 
