Jump to content

Подскажите с настройкой

alibek
 Share

Recommended Posts

alibek

alibek

Posted
Posted

Есть подсеть 10.102.0.0/16 со шлюзом 10.102.0.250.

В 10.102.0.0/24 обитает серверное оборудование, в остальных адресах обитает конечное оборудование (третий октет не превысит 9, т.е. с 10.102.1.0-10.102.9.255).

Нужно организовать доступ к 10.102.0.0/24 для отдельной группы ПК, при этом доступа к остальным хостам 10.102.0.0/16 быть не должно.

Для этого нужно на 10.102.0.250 навесить ACL, который будет разрешать доступ к 10.102.0.0/24 и запрещать остальное.

 

А если я эту группу отдельных ПК поселю в 10.102.200.0/24?

Получится ли в этом случае изолировать 10.102.200.0/24 от остальной подсети, за исключением серверной?

Допустим на маршрутизаторе (каталист 3750) интерфейс будет сделан так:

interface vlan xxx
ip address 10.102.0.250 255.255.0.0
ip address 10.102.200.250 255.255.255.0 secondary
no ip redirects
no ip unreachables
no ip proxy-arp

И на этот интерфейс навешу ACL.

 

Сработает?

Или лучше не изобретать хитрых схем и сделать непересекающуюся подсеть в другом VLAN?

 

Надежнее было бы сделать так:

interface vlan xxx
ip address 10.102.0.250 255.255.0.0
no ip redirects
no ip unreachables
no ip proxy-arp
interface vlan yyy
ip address 10.102.200.250 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp

Но на одном каталисте пересекающиеся подсети на разных интерфейсах не сделать.

Bat

Bat

Posted
Posted

Если я правильно понял то что вы хотите, то не получится. acl на int vlan работает только доступ непосредственно к виртуальному интерфейсу на вашей 3750. Транзитный трафик легко дойдет до ваших ПК. Чтобы изолировать ПК нужно вешать acl непосредственно на физических интерфейсах.

alibek

alibek

Posted
  • Author
Posted

Чтобы изолировать ПК нужно вешать acl непосредственно на физических интерфейсах.

Допустим у меня такой ACL:

ip access-list extended MY_SERVICES
remark Permit ICMP to servers
permit icmp 10.102.0.0 0.0.255.255 10.102.0.0 0.0.0.255
remark Permit admin access
permit tcp 10.1.144.0 0.0.0.255 10.102.0.0 0.0.0.255 eq 5555
permit tcp 10.1.128.0 0.0.0.255 10.102.0.0 0.0.0.255 eq 5555
remark Permit service access
permit tcp 10.1.144.0 0.0.0.255 10.102.0.0 0.0.0.255 eq 8080
permit tcp 10.1.128.0 0.0.0.255 10.102.0.0 0.0.0.255 eq 8080
permit tcp 10.102.200.0 0.0.0.255 10.102.0.0 0.0.0.255 eq 8080
remark Deny other
deny   ip any any

Я правильно понял, что мне этот ACL нужно навесить не на SVI, а на порт, в который подключена сеть с ПК?

Просто на этот каталист непосредственно устройства в access-порты не подключаются.

И сервера, и ПК приходят с транковых интерфейсов.

 

или vacl.

Речь про это?

Да, похоже на именно то, что мне нужно.

alibek

alibek

Posted
  • Author
Posted

Благодарю, завтра буду экспериментировать.

Насколько я понял, если я сделаю все в одном VLAN, то фильтрации будет подвергаться весь трафик и мне нужно будет прописывать разрешения и для 10.102.1.0-10.102.9.255?

И еще вопрос, нужно ли навешивать ACL на SVI, или не транзитный трафик (т.е. приходящий на 10.102.0.250 и 10.102.200.250) также будет подвергнут фильтрации?

semop

semop

Posted
Posted

Здравствуйте.

Я за сегментацию сети.

 

Но на одном каталисте пересекающиеся подсети на разных интерфейсах не сделать.

это скверно...

 

Любой бродкастовый шторм, петля и тп - расползется в обе сетки. Зачем так делать?

Зачем вообще берут на упр-е оборудованием в составе 5 серваков и пары копилок сетку класса В? А потом туда же втыкают все, что попало.

Bat

Bat

Posted
Posted

Я правильно понял, что мне этот ACL нужно навесить не на SVI, а на порт, в который подключена сеть с ПК?

Просто на этот каталист непосредственно устройства в access-порты не подключаются.

И сервера, и ПК приходят с транковых интерфейсов.

На транки тоже можно вешать acl. Нельзя только на Etherchannel, насколько помню.

NikAlexAn

NikAlexAn

Posted
Posted

Благодарю, завтра буду экспериментировать.

Насколько я понял, если я сделаю все в одном VLAN, то фильтрации будет подвергаться весь трафик и мне нужно будет прописывать разрешения и для 10.102.1.0-10.102.9.255?

И еще вопрос, нужно ли навешивать ACL на SVI, или не транзитный трафик (т.е. приходящий на 10.102.0.250 и 10.102.200.250) также будет подвергнут фильтрации?

 

Сложно советовать что либо без схемы.

В случае с vacl проверяться будет только тот трафик который проходит через коммутатор с включенным vacl, так что проанализируйте вашу сеть.

А никак не избавиться от 10.102.0.0/16?

alibek

alibek

Posted
  • Author
Posted

Ну схема то самая простая.

Есть несколько сотен IP-камер. Есть сервисное оборудование (сервера), работающее с этими камерами, их общее количество будет в пределах десяти хостов (максимум двадцати). По разным соображениям желательно камеры и сервера разместить в одном L2-сегменте.

Есть также пользователи, которые будут работать с серверами, пользователей планируется не более 30. Пользователи должны работать только с серверами, к остальным устройствам доступ им давать не нужно.

М1 и К2 на схеме — это физически одно устройство (Catalyst 3750).

 

IP-адресация:

Для всей сети выбрана 10.102.0.0/16. В /24 устройства не влезут, поэтому чтобы заморачиваться с учетом IP-адресов, она весьма прореженная.

10.102.0.0/24 выбрана для сервисного оборудования (к которому пользователям должен предоставляться доступ), 10.102.1.0-10.102.9.255 используется для IP-камер. Остальные адреса не используются.

Для пользователей я выбрал 10.102.200.0/24 из тех соображений, чтобы опять же не заморачиваться с учетом IP-адресов. То есть я знаю, что подсеть 10.102.0.0/16 целиком выделена для определенной задачи, и больше нигде ее использовать не буду.

10.102.0.0/16 полностью изолированная подсеть, в/к ней нет выхода в/из других сетей (за исключением 10.102.0.0/24, в которой через NAT прокинуто несколько сервисов).

 

Если бы пользователи и сервисная сеть терминировались на разных маршрутизаторов, тогда бы все было проще. Но сейчас (и в будущем) М1 и К2 это физически одно устройство, Catalyst 3750E.

Но мне тут напомнили про vrf-lite, это как мне кажется будет оптимальным решением.

vacl очевидно тоже потребуется,

 

На транки тоже можно вешать acl.

В случае транка ведь ACL будет применяться ко всем VLAN?

net.jpg

NikAlexAn

NikAlexAn

Posted
Posted

Но мне тут напомнили про vrf-lite, это как мне кажется будет оптимальным решением.

По моему при данных вводных это мимо.

Насколько помню киски не дадут создать интерфейсы с пересекающимися диапазонами а в таком случае как вы vrf-ы между собой соедините?

 

По моему с помощью VACL на К1 возможно ограничить доступ пользователей к камерам. Попробуйте.

Bat

Bat

Posted
Posted

В случае транка ведь ACL будет применяться ко всем VLAN?

Да.

 

А не лучше ли вам пользователей и камеры в отдельные VLAN поместить и на серверах поднять bond? К чему эти заморочки с ACL?

alibek

alibek

Posted
  • Author
Posted

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

Но чисто по организационным причинам было бы удобнее все разместить внутри 10.102. Мне так удобнее будет работать и проще вести адресное пространство.

Как вариант, можно поменять маску на 10.102.0.0/17, тогда и создать интерфейс 10.102.200.250/24 в отдельном SVI проблем не составит.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.