Маршрутизація між VLAN: кілька VLAN, лише одна повинна бути доступною для всіх. Має сенс?


2

Я намагаюся сегментувати мережу нашої компанії. Моя головна мета - мати багато невеликих доменів мовлення замість гігантських, тому я подумав призначити одну VLAN на відділ.

Однак у нас є багато принтерів і централізований файловий сервер, який повинен бути доступний на будь-якому пристрої в компанії. Отже, я думаю, що ці сервіси повинні належати до окремої VLAN, яка, в свою чергу, спілкуватиметься з локальними локальними мережами через адресацію L3.

Оскільки у нас є комутатор L3 Cisco, маршрутизація між VLAN, здається, є правильним способом. Але коли я експериментую з цим, я помічаю, що мені потрібно призначити IP-адресу кожному інтерфейсу VLAN (таким чином розподіляючи кожен відділ у власну підмережу), і, як тільки я дозволяю ip routingна комутаторі L3, пристрої можуть пінг не лише принтери або файловий сервер, а також будь-який інший пристрій будь-якого іншого відділу.

Я знаю, що домен мовлення не є однаковим між однією підмережею та іншою, але я подумав, що було б якось безпечніше, якби ці VLAN не змогли спілкуватися між собою.

Коли це було сказано, ось мої сумніви з цього приводу:

1) Для безпеки краще ізолювати ці відділи VLAN таким чином, що вони можуть бачити лише VLAN принтерів / файлів (не бачачи один одного)?

2) Якщо так, то який найкращий спосіб зробити це? Єдиний здійсненний підхід, який я можу придумати, - це використання ACL, але вони не здаються практичними, оскільки я б мав багато записів для обробки.


1
Можливо, вам потрібен брандмауер?
Марки

1
Ось фразу, яку я люблю використовувати для таких питань: Нахил на вітряках. Ви реалізуєте VLAN на основі нечітких уявлень про "безпеку" та "домени трансляції". У вас є реальна проблема, яку можна вирішити за допомогою VLAN, або ви просто робите це, тому що ви думаєте, що ви повинні, або тому, що хтось сказав вам, що ви повинні, або тому, що десь читаєте, що вам слід?
joeqwerty

Я думаю, що домени трансляції навряд чи можна вважати невиразною ідеєю. Заборонити клієнтам діставатися один до одного досить важко в ці дні, що користувачі можуть просто вирішити використовувати хмарні сервіси для вирішення їхньої проблеми, за межами vlans потрібно зовсім небагато думок. Найгірший випадок створює проблему безпеки, там, де її не було.
ЕрікЕ

@Marki - блокувати трафік між відділом можна легко за допомогою перемикача L3, який у нього вже є - тут немає необхідності в брандмауері.
ETL

@joeqwerty Я не надто детально описувався, бо боявся, що моє питання буде надто обширним; можливо я це спростив, не знаю. В основному я хочу розділити мережу через три речі: 1) Обмеження обсягу - наскільки це можливо, питання одного відділу не повинні поширюватися на інші відділи. 2) Краще відстеження - просто переглянувши адресу хоста, я міг би знайти його. 3) Продуктивність - зараз трансляція штормів може поставити під загрозу всю нашу мережу. Я не прив’язаний до VLAN або підмережі, вони були лише можливим рішенням, про який я міг придумати. Сміливо дайте будь-які ідеї.

Відповіді:


1

1) Залежить від ваших вимог безпеки. Якщо ваші вимоги полягають у тому, щоб користувальницький ПК мав змогу спілкуватися лише з серверами / принтерами, а не між ПК, тоді так, вам слід мати ACL на інтерфейсі VLAN, щоб блокувати трафік за своїм бажанням. Що найбезпечніше - добре блокувати все, але те, що дійсно потрібно, є найбільш безпечним.

2) Для цього просто реалізуйте ACL та застосуйте ACL до інтерфейсу VLAN. Оскільки ви намагаєтеся дозволити ПК на серверах / принтерах, ваші ACL повинні бути простими ... чимось у порядку:

припустимо, що у ваших підмережах 10.0.0.0, а ваші сервери / принтери в 10.1.1.0/24:

permit ip 10.0.0.0 0.255.255.255 10.1.1.0 0.0.0.255
deny ip any any log

Це, очевидно, проста версія, вам потрібно буде підправити звідти, щоб отримати точний бажаний результат. За допомогою цього прикладу ви можете застосувати це до всіх інтерфейсів VLAN вашого ПК так, як це написано загальним способом, який буде працювати для всіх ваших VLAN.

Ви можете знайти інший приклад в іншому запитанні, на яке я відповів минулого тижня: Тримайте інтерфейси маршрутизатора ізольованими


Чи є Ваша пропозиція вирішити весь доступ до Інтернету через проксі?
ЕрікЕ

@ErikE - Не особливо, оскільки в питанні про ОП не було згадок про Інтернет. Він намагається перекрити рух між відділами. Але я маю весь Інтернет-трафік через проксі, я б рекомендував так, щоб краще контролювати те, що дозволено з міркувань безпеки - якщо тільки отримати деякі журнали.
ETL

Дякую за відповідь. Синтаксис ACL трохи уточнив речі. Щодо першого пункту, я не розробив вимог безпеки - в основному через брак знань. Як би ви сказали, чи можливі загрози передачі комунікацій між усіма пристроями через мережевий рівень? На вашу думку, чи варто блокувати спілкування між секціями організації?

@Renato - важко сказати, не знаючи більше типу бізнесу, розміру мережі та інших заходів безпеки на ваших машинах. Але візьмемо цей приклад, заражена вірусом машина A починає вражати всі ваші машини через відкрите з'єднання RPC і поширюється ... ну якщо ви заблокуєте трафік між вашим відділом, ви принаймні пом'якшите це. Що робити, якщо у вас є вимоги безпеки щодо документів, і ви виявите, що Джо в кафедрі А є мудрецем і налаштував себе на можливість VNC для всіх інших департаментів ... ви могли б заблокувати це і т.д.
ETL

0

Це дуже поширена ситуація, і, на жаль, початкова відповідь не повинна бути технічною. Маршрут Inter-Vlan - це добре, якщо він працює для вашої компанії. Так, можливі проблеми із безпекою та працездатністю, але чи є у вас персонал для управління вимогами, якщо ви блокуєте свої системи?

Поки ви правильно спроектували свою мережу, ви повинні мати можливість захищати маршрутизацію між собою і обмежувати необхідні зміни після факту. І так само, як ви сказали, забезпечуючи свій vlan, ви знижуєте ризик для безпеки, підвищуєте продуктивність і дозволяєте встановити елементи контролю для відстеження IP-адрес та пристроїв.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.