alibek Опубликовано 21 октября, 2014 · Жалоба Есть подсеть 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 Но на одном каталисте пересекающиеся подсети на разных интерфейсах не сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bat Опубликовано 21 октября, 2014 · Жалоба Если я правильно понял то что вы хотите, то не получится. acl на int vlan работает только доступ непосредственно к виртуальному интерфейсу на вашей 3750. Транзитный трафик легко дойдет до ваших ПК. Чтобы изолировать ПК нужно вешать acl непосредственно на физических интерфейсах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 21 октября, 2014 · Жалоба или vacl. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 21 октября, 2014 · Жалоба Чтобы изолировать ПК нужно вешать 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. Речь про это? Да, похоже на именно то, что мне нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 21 октября, 2014 · Жалоба да, для транзитного трафика именно оно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 21 октября, 2014 · Жалоба Благодарю, завтра буду экспериментировать. Насколько я понял, если я сделаю все в одном VLAN, то фильтрации будет подвергаться весь трафик и мне нужно будет прописывать разрешения и для 10.102.1.0-10.102.9.255? И еще вопрос, нужно ли навешивать ACL на SVI, или не транзитный трафик (т.е. приходящий на 10.102.0.250 и 10.102.200.250) также будет подвергнут фильтрации? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 21 октября, 2014 · Жалоба VACLs provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 21 октября, 2014 · Жалоба Здравствуйте. Я за сегментацию сети. Но на одном каталисте пересекающиеся подсети на разных интерфейсах не сделать. это скверно... Любой бродкастовый шторм, петля и тп - расползется в обе сетки. Зачем так делать? Зачем вообще берут на упр-е оборудованием в составе 5 серваков и пары копилок сетку класса В? А потом туда же втыкают все, что попало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bat Опубликовано 21 октября, 2014 · Жалоба Я правильно понял, что мне этот ACL нужно навесить не на SVI, а на порт, в который подключена сеть с ПК? Просто на этот каталист непосредственно устройства в access-порты не подключаются. И сервера, и ПК приходят с транковых интерфейсов. На транки тоже можно вешать acl. Нельзя только на Etherchannel, насколько помню. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Merridius Опубликовано 21 октября, 2014 · Жалоба Но на одном каталисте пересекающиеся подсети на разных интерфейсах не сделать. Вообще-то сделать, 3750 поддерживает VRF-Lite. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 22 октября, 2014 · Жалоба Благодарю, завтра буду экспериментировать. Насколько я понял, если я сделаю все в одном 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 22 октября, 2014 · Жалоба Ну схема то самая простая. Есть несколько сотен 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 22 октября, 2014 · Жалоба Но мне тут напомнили про vrf-lite, это как мне кажется будет оптимальным решением. По моему при данных вводных это мимо. Насколько помню киски не дадут создать интерфейсы с пересекающимися диапазонами а в таком случае как вы vrf-ы между собой соедините? По моему с помощью VACL на К1 возможно ограничить доступ пользователей к камерам. Попробуйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bat Опубликовано 22 октября, 2014 · Жалоба В случае транка ведь ACL будет применяться ко всем VLAN? Да. А не лучше ли вам пользователей и камеры в отдельные VLAN поместить и на серверах поднять bond? К чему эти заморочки с ACL? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rainmib Опубликовано 23 октября, 2014 · Жалоба А может пользователей вывести в другую сеть 10.103.0.0/24 и дать им доступ в сеть 10.102.0.0/24 никаких проблем не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 октября, 2014 · Жалоба Ну я с самого начала так и писал, такой способ очевидный и сложностей в нем нет. Технически неважно, какие IP-адреса будут у пользователей. Но чисто по организационным причинам было бы удобнее все разместить внутри 10.102. Мне так удобнее будет работать и проще вести адресное пространство. Как вариант, можно поменять маску на 10.102.0.0/17, тогда и создать интерфейс 10.102.200.250/24 в отдельном SVI проблем не составит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...