Можно ли частично изменить маску подсети в сети организации?

Question

[Inkvee]

В организации используется сеть 10.0.100.0/23:

• 10.0.100.1 – центральный роутер/NGFW;
  
• 10.0.100.2–10.0.100.254 /23 – для хостов со статическим адресом;
  
• 10.0.101.0–10.0.101.254 /23 – для DHCP.
  

Сейчас адресов не хватает, и сеть необходимо расширить до /22, но менять статику на большом количестве оборудования (например, станков) невозможно.

План действий:

1. На роутере разрешить трафик от 10.0.100.0/22.
   
2. Расширить DHCP, чтобы включить новые адреса.
   

Вопросы:

1. Смогут ли хосты со старыми настройками (маска /23) выходить в интернет?
   
2. Будет ли работать проброс портов с роутера на статический хост со старыми настройками?
   

Comments

[Valentin Barbolin]

- Смогут ли хосты со статикой выходить в интернет со старыми настройками? (Шлюз прописан, и 22 маска вроде как включает в себя 23 маску)

да

- Будет ли работать проброс портов с роутера на статический хост со старыми настройками?

да

> ipcalc 10.0.100.0/22

Address: 10.0.100.0 00001010.00000000.011001 00.00000000
Netmask: 255.255.252.0 = 22 11111111.11111111.111111 00.00000000
Wildcard: 0.0.3.255 00000000.00000000.000000 11.11111111
=>
Network: 10.0.100.0/22 00001010.00000000.011001 00.00000000
HostMin: 10.0.100.1 00001010.00000000.011001 00.00000001
HostMax: 10.0.103.254 00001010.00000000.011001 11.11111110
Broadcast: 10.0.103.255 00001010.00000000.011001 11.11111111
Hosts/Net: 1022 Class A, Private Internet

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

Так же клиенты c адресами их подсетей 10.0.102.XXX и 10.0.103.ХХХ не смогут общаться с теми кто в 10.0.100.0/23, пока на старых клиентах не поменяется маска.

[German Jet]

Valentin Barbolin, на скорость никак не повлияет такая схема?

[Valentin Barbolin]

German Jet, неа

[rPman]

Valentin Barbolin, в смысле 'неа', между подсетями трафик пойдет через роутер, а не через локальные коммутаторы (которые оптимизируют доставку не нагружая другие сегменты сети)

[hrabrahrabr]

Поднимать маску это самый неправильный вариант, получается одна большая неуправляемая/неконтролируемая помойка. Надо наоборот резать сети на сегменты меньшего размера, маска /24 это и так много.
Сам разобрал сеть с /19 маски, на кучу мелких по /30 /25 и /24 в зависимости от функций групп.
А очень давно делали именно как вы с маски /22 поднялись до /19. обе маски работали одновременно т.к. на софтовом роутере на одной сетевой были два адреса 10.1.1.1/22 и 10.1.1.1/19 и работало нормально. но было очень давно.
У вас NGFW это видимо циска. могу порекомендовать использовать два интерфейса типа ЛАН, со старым адресом 10.0.100.1 /23 и настроить новый 10.0.102.1 /24 и соответственно правила обмена между этими сетями ЛАН, и оба физических интерфейса воткнуть в один ВЛАН, то есть как бы один броадкаст домен (реально будут два) но это только на первое время, как костыль. Потом всё таки рекомендую настроить коммутаторы, у вас их ведь больше 20-30 штук и управляемые (?), в плане отдельных сетей и ВЛАНов, и хотя бы статические маршруты между сетями, даже свичи уровня 2+ это умеют (не больше 20-30 получится).

[hrabrahrabr]

rPman, если сеть плоская а здесь более 500 устройств, никакая глобальная "оптимизация" трафика свичами не делается. любой хост может "простучать" всю сеть.
особенно большой выплеск трафика, при массовом включении компьютеров в начале рабочих смен.

[rPman]

hrabrahrabr, а так у тебя обычное копирование файлов с компа на комп положит сеть,.. но да, обычно в компаниях файловое хранилище на сервере им с соседнего компьютера ничего не копируется

[hrabrahrabr]

rPman, обычное копирование файлов с компа на комп положит сеть
На полностью плоской и ложило, особенно когда дибилы коротили два порта патчнуром.
на текущей сети через маршрутизацию нет проблем, всё копируется на максимуме портов или дисков.
Не стоит сравнивать и строить на одном и том же железе, домашнюю сеть и сеть где более 500 хостов!
Просто свичи/роутеры выбирать надо согласно нагрузке, она в центре сети и на её периферии разная! И нужно минимизировать "гирлянду" =кол-во проходных свичей от клиента до серверов/сервисов. это кроме уменьшения "латиенси" увеличивает надежность, меньше влияния при отключении проходных точек.

[Zerg89]

Может проще добавить еще один пул раздавемых адресов с /23 маской, прописать подсеть на роутере и настроить маршрутизацию между подсетями

[Inkvee]

так тоже можно, но есть другие причины почему вариант с маской мог бы быть предпочтительнее

[mikes]

Inkvee, если есть функционал завязанный на всяких бродкастах, то возможно стоит для доп сети использовать arp proxy и хосты смогут видеть друг друга без маршрутизации как таковой.

Но имхо использование таких больших масок не в провайдинге не оч хорошо. сегментация наше все.

Answer 1

[asmelnik]

Не стоит такого делать.
1. например 10.0.100.123 /23 никогда не свяжется с 10.0.102.123 /22
Причина -- 10.0.100.123 не ответит на ARP запросы из сети 10.0.102.... т.к. это НЕ его подсеть, а узлы из 10.0.102.../22 не пойдут на 10.0.100.../23 через шлюз, т.к. для этих узлов это "родная" сеть.

2. У этих сетей разный бродкаст.
Бродкаст 10.0.101.255 для 10.0.100.0/23 уже превращается в самый обычный IP для 10.0.100.0/22
И все, что завязано на бродкаст будет работать неизвестно как..
Причем это "неизвестно как" платформозависимо.
Например в одних реализациях в бродкаст пакете не проверяется IP, (только МАС проверяется). А в других IP тоже проверяется, вот и будет непоймичто.
Да, есть масса примеров из жизни "Я вот так делал, и у меня все работало..."
Поправочка -- вы не нарвались на то, что не работало.

В общем -- сделать можно, но при каждом глюкане начинать поиск решения с проверки -- а не тут ли собака порылась??

Comments

[hrabrahrabr]

Не стоит такого делать.
Да, есть масса примеров из жизни "Я вот так делал, и у меня все работало..."
Поправочка -- вы не нарвались на то, что не работало.
Вы правы - не стоит, но есть разные варианты "костылей" , которые будут вполне себе работать , но очень сильно зависят от моделей роутеров и свичей.
например 10.0.100.123 /23 никогда не свяжется с 10.0.102.123 /22
если на роутере на одном интерфейсе удастся (зухель и циска дают , АТ - нет) повесить два адреса 10.0.100.1/23 и 10.0.102.1/22 - то эти клиенты свяжутся.

Answer 2

[ky0]

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

Comments

[AUser0]

ky0, эммм, хосты из расширенного адресного пространства будут считать старые хосты "своими" - и шлюзом пользоваться не будут. Старые хосты буду отвечать им через шлюз. Неаккуратненько, однако...

Тогда уж лучше сделать вторую подсеть, но придётся настраивать правила для обнаружения NETBIOS, если он используется.

Answer 3

[res2001]

Есть смысл не расширять маску, а наоборот разбить сеть на несколько меньших сетей и настроить между ними маршрутизацию. Сетей может быть несколько, при этом каждую из них не делайте меньше 24. Таким образом останется адресное пространство для расширения в каждой отдельно взятой сети.

Comments

[hrabrahrabr]

не делайте меньше 24.
в интрасети класса А, то есть 10.0.0.0/8 , больше 16 мульёнов адресов, резать можно как угодно. хоть по два, если свичи умеют без ограничений SVI и маршруты, то какая разница ?
младшие элтексы вот больше 20 SVI - не дают :-(

[res2001]

hrabrahrabr,

то какая разница ?

Чтоб запас был для добавления новых хостов в подсеть, без очередного этапа расширения подсети.

[hrabrahrabr]

res2001, для этого нужно планирование нормальное. И опять вопрос зачем?? Пихать в ту же сеть клиента если можно сделать отдельную новую? В АСУ ТП вообще клиенты = станки не должны общаться между собой, только с сервером.
А здесь всё общим чохом и офис и станки. Ломанут и всё разом встанет.

Answer 4

[Dupych]

Вот вы там накрутили.
Читаю комменты и офигеваю.
Возьми в руки лан калькулятор онлайн.
Первое что бросается в глаза это маска 23 у простой сети в 254 адреса она 24....!!!!
Нагорожено хрен знает что.
Как сделано у меня с учетом на будущее.
10.1.x.x - первый офис
10.2.х.х - второй офис и тд
Все офисы между собой соединены туннелями на микротах.
10.х.1.0/24 - сервера и коммутаторы. Unifi wifi
10.x.2.0/24 - Пк и принтеры
10.х.3.0/24 - все IP телефоны.
По DHCP Yealink считывает 135 парамет и сам прыгает в нужный VLAN.
10.х.4.0/25 СКУД, пожарка, видеонаблюдение
10.х.5.0/24 - WIFI с доступом в локалку.
10.х.15.0/24 - Гостеввой wifi с DHCP на микроте + DNS 8.8.8.8. блок на доступ в любую сеть.
Везде прописаны маршруты. Я в любой момент могу соединить офисы через туннель другого офиса.
Я могу манипулировать маршрутами.
Могу перекрыть доступ из одной чети в другую оперируя только маршрутами.
Делай вторую сеть 10.0.102.0/24 и пиши мартрут между сетями вот и все.

Comments

[German Jet]

Есть подробный мануал, как туннели на микротах сделать? Копался много, но чувствуется нехватка знаний, нужно, чтоб максимально разжевано было

[hrabrahrabr]

Первое что бросается в глаза это маска 23 у простой сети в 254 адреса она 24....!!!!
вы не внимателен, там сеть 10.0.100.1- 10.0.101.255 с маской 23, с одним шлюзом, и да 10.0.100.** отдано по дхцп, 10.0.101.** по статике и только.
но в целом ваша концепция вполне логична, у меня очень похожее.
для интранета сеть 10.0.0.0/8 и её деление на подсети - почти не возможно исчерпать.
вот только диапазоны от 10.0.0.0 до 10.1.1.255 и от 192.168.0.0 до 192.168.1.255, стоит исключить, потому как много ленивых их используют по умолчанию.

[Dupych]

German Jet, Привет. На 2 микроте Локальные IP и Внешний меняешь местами.
IP понятное дело должны быть белыми. Ну и сектер свой поставь.
Туннели работаюк как часы более 3 лет.

/interface ipip
add allow-fast-path=no ipsec-secret="huiy798Y&(Y78ty68t567T^&*T%^&R5757T67T67" local-address=109.95.8.8 name="ipip-tunnel (Office_1)" remote-address=178.218.9.9

/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256,aes-192 hash-algorithm=sha256

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-128-cbc pfs-group=modp2048

Answer 5

[Maxim Iontzev]

И никто не обратил внимание, что в качестве центрального роутера используется NGFW. Между новыми и старыми хостами трафик будет ассиметричный, а для NGFW - это как красная тряпка для быка. Скорее всего такой трафик будет блокироваться. Еще и как идущий в сетку с адресацией интерфейса, с которого пришел