Akina

не до конца наверное понимаю работу vlan

VLAN в первом приближении - это не просто, а очень просто.

Первый шаг - это разделение по отдельным VLAN. Мысленно представляешь, что у тебя не один коммутатор, а несколько. Вот прям вместо коммутатора стоИт стопка один на другом. В первом - только VLANID=1, во втором VLANID=2, и так далее. Каждый коммутатор обслуживает строго один VLAN, а все остальные порты, на которых текущий VLAN отсутствует, тупо залиты цементом. Если коммутаторов несколько - то каждый в схеме размножается таким образом, а соединения между портами коммутаторов ещё и раскрашиваются, например, тегованный кабель синий, а нетегованный красный. Соответственно если у тебя есть транковая связь (гибридный или транковый порт) с каждой из сторон) - то в преобразованной схеме один кабель между такими коммутаторами размножается на несколько, каждый в схеме для своего VLAN. А если попадается случай, когда с одной стороны провода VLANID есть, а с другой стороны его нет - получается кабель, с одной стороны вставленный в порт, а с другой нет. И соответственно в схеме для именно этого VLAN связи между коммутаторами нет. Аналогично для случаев соединения "tag на untag" с одной стороны красный кабель, с другой синий, у обоих вторые концы "в воздухе", а связи нет.

Второй, дополнительный, шаг - это соединение меж собой нетегованных портов разных VLAN в преобразованной схеме, если такие соединения исходно существуют, невзирая на номера VLAN. Скажем, если на порте есть нетегованный VLANID=2 (возможно, с другими VLANID, но тегованными), и порт соединён кабелем с другим портом того же или другого коммутатора, на котором есть нетегованный VLANID=3, то в преобразованной схеме ты соединяешь соотв. порты коммутаторов разных слоёв, соответствующих этим VLAN.

Теоретически можно себе представить, что при настройке порта, один и тот же VLANID на порте прописан и как тегованный, и как нетегованный - но это явная ошибка конфигурации (если на порт придёт пакет в этом VLANID, коммутатор не знает, теговать его или нет, а дублировать пакет он просто не станет, не его это дело), и в подавляющем большинстве случаев конфигуратор такое просто не примет.

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

программа которая видит через какие маршрутизаторы и роутеры и т.д проходит отправляемый запрос

В общем случае получение полного маршрута - вообще без шансов.

Дело в том, что любой маршрутизатор в принципе-то может делать с маршрутизируемым пакетом что угодно. В том числе он запросто может и спрятаться - он просто увеличит TTL на единичку (точнее, не станет его уменьшать) и отправит дальше. Такой маршрутизатор мы в трассе просто не увидим, равно как и не увидим в этой трассе никаких иных ненормальностей.

на работе в серверной куча лапши из проводов и свичей

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

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

Любой маршрут пакета может быть представлен так:

(source IP1) - (IP2 router1 IP3) - (IP4 router2 IP5) - ... - (IPn destination)

У тебя весь маршрут точно известен. А потому временно добавляем на источнике (IP1) маршруты во все промежуточные подсети, если они не покрываются маршрутом по умолчанию или более широкими частными маршрутами, и с источника (IP1) начинаем последовательно пинговать IP2, IP3, IP4, .. и так до узла назначения.

Где-то возникнет проблема, и очередной IP не ответит. Вот именно знание, кто не ответил, и какой именно тип ошибки пинга возвращён, и позволит определить, на каком узле и по какой причине грабли. Конечно, следует понимать, что в маршруте может быть несколько последовательных ошибок, и даже несколько параллельных на одном узле.

Например, если проходит пинг на IP4, но не проходит на IP5, то в случае ответа No route to host проблема - в отсутствии маршрута в подсеть IP5 на узлах source (забыли добавить или сделали это неправильно) или router1, а в случае ответа Timeout проблемы с маршрутизацией на узле router2 или файрволом на любом из трёх задействованных в маршруте узлов.

Нужно изменить режим работы Роутера-2. Он должен работать в режиме не роутера, а точки доступа, т.е. просто служить конвертором интерфейса. Ну и, само собой, DHCP на нём отключить.
Тогда камера будет цепляться за него и через него слать запрос адреса на Роутер-1. Ну вернее слать запрос в проводной интерфейс, а там Роутер-1 единственный DHCP.
У ТПЛинка на сайте даже видео есть "Как превратить роутер в точку доступа?".

Не, вот зачем в такой простой и тупой сети столько маршрутизаторов?

PS. Как по мне, вся схема - одна большая ошибка.
PPS. И что вообще делают роутеры и брэндмауэр в L2-схеме?

Читайте договор.

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

Есть другая локальная сеть.

Eсли термин "другая локальная сеть" использован правильно, и речь идёт о физически изолированных сетях - то без объединения сетей - на самом сервере (вставить в него вторую сетевую) либо на отдельном устройстве в первой сети,- задача очевидно не решается.

Как сделать так что бы при вводе другого IP адреса с другой подсети пользователь попадал на сайт 10.2.2.10?

Если вопрос ставить ИМЕННО ТАК - то либо использовать destination NAT в варианте DMZ, либо socks proxy.

Любые остальные решения подходят только в случае, когда будут чётко определены конкретные протоколы и, для TCP/UDP - порты. И когда будет чётко и однозначно определено, что скрывается под загадочным термином "попадать".

Есть устоявшаяся практика: присваивать номер vlan номеру подсети

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

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

понятно ограничение на количество vlan на разном оборудовании

Если оборудование не поддерживает стандарт, который определяет 4к различных VLAN, то разумнее его не использовать - кто знает, что оно ещё делает не по стандарту...

Насколько крупный должен быть бизнес, чтобы человек был не админом-универсалом, а трушным сетевиком?

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

Мелкой, средней, и даже крупной конторе, но не имеющей разветвлённой сетевой инфраструктуры, выделенный сетевик в общем-то не нужен, как правило, вполне достаточно системного админа (или нескольких) с соответствующими скиллами.

Крупной конторе с разветвлённой сетевой инфраструктурой (как правило, речь о территориально распределённых) выделенный сетевик или даже отдел - нужны. А если проблемы в сетевой инфраструктуре способны сильно влиять на бизнес и приводить к серьёзным потерям - то такой отдел необходим.

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

является ли такой режим и график работы для сетевика нормой?

Для организации, имеющий соответствующий отдел и службу быстрого реагирования (последняя категория из описанных выше) - совершенно ненормально.

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

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

Без промежуточных? Расстояние - в пределах домена коллизий.
Однако даже в таком случае расчёт времени невозможен. Например, оно может увеличиться (и сильно), если перестраивается RSTP.

Документация на странице 7 утверждает, что девайс поддерживает полный набор виланов, все 4096 штук.

Прав в файловой системе - мало. Нужны ещё и права на саму шару (расшаренный ресурс). Результирующие права определяются только тем, что прошло через оба этих сита.

Мой компьютер - ПКМ - Управление - Общие папки - Общие ресурсы - нужный ресурс - ПКМ - Свойства - Разрешения для общего ресурса

Заодно проверьте в локальных политиках, разрешен ли доступ из сети с пустым паролем (у юзеров пароли же не установлены, верно?). И не запрещён ли кому вообще доступ из сети.

16 ноутбуков с выходом в интернет. Если подключить к коммутатору, то IP адресов не хватает. Думаю как-нибудь через маршрутизатор подключить, но пока не знаю, как это сделать и какой маршрутизатор для этого подходит. Маршрутизатор будет получать IP адрес от сервера школы.

Иными словами, в качестве маршрутизатора в инет и одновременно DHCP-сервера выступает этот самый "сервер школы".
Соответственно решение - на сервере в настройках DHCP-сервера создать ещё один скоп /27 или шире, и смаршрутизировать его в интерфейс/VLAN, через который подключается коммутатор класса.
Задача должна решаться администратором, а не первым попавшимся под руку неспециалистом.

1. В сети может быть несколько маршрутизаторов, и разные конечные узлы могут быть доступны через разные маршрутизаторы. Таблица позволяет знать, через кого слать трафик.
2. На компьютере может быть несколько внешних сетевых интерфейсов (а ещё есть localhost), и разные конечные узлы могут быть доступны через разные интерфейсы. Таблица позволяет знать, через кого слать трафик.

Нет такого понятия - "роутер создаёт подсеть". Подсеть просто существует - потому что может. А любое оборудование (в том числе и роутер) либо узел в этой подсети, либо нет. Либо, при ошибке настройки, попадает в эту подсеть, но из-за несовпадения маски функционирует частично неправильно.

Навскидку:

1. Звезда - плохо. Случись что, и сегмент отвалится. Я бы делал как минимум кольцо, и в него ERPS или RSTP (ещё лучше - кольцо на ERPS, а дальше RSTP). Ещё лучше - два кольца. И из тех же соображений надёжности - минимум два магистральных коммутатора на площадку/здание.
2. Неуправляемые коммутаторы - забудьте как страшный сон. Например, надо перестартовать камеру по питанию - что, бежать к камере? да даже элементарно посмотреть статус коннекта... ставьте PoE L2.
3. Транки я бы делал 10G.
4. Оптический коммутатор в центре достаточно L2 или L2+. У него вообще все порты будут в транке (tagged).
5. По части подсетей - для указанного количества оборудования я бы брал подсети /23 или /22 из 172.16. Избыток адресов ни на что не влияет, а их недостаток - это по определению геморрой. Оно надо?
6. Если подсеть исчерпала адреса - то перестраиваешь DHCP-сервер, раздающий адреса. Либо расширяешь подсеть, либо добавляешь ещё один скоп и организуешь маршрутизацию. Второе правильнее - ибо в любом сегменте найдётся оборудование со статическим назначением адресов (не статическое резервирование!), при изменении маски их придётся перенастраивать.
7. И я как-то не увидел управляющего VLAN, в котором будут только административные адреса коммутаторов.

понял что у меня каша в голове

Эт точно...

Достаточно неплохое определение бродкастового домена Вы можете найти в Вики:

Широковеща́тельный доме́н (сегме́нт) (англ. broadcast domain) — группа доменов коллизий, соединенных с помощью устройств второго уровня. Иными словами логический участок компьютерной сети, в котором все узлы могут передавать данные друг другу с помощью широковещания на канальном уровне сетевой модели OSI.

Обратите внимание - достижимость широковещательной передачи не ограничивается адресом бродкаста подсети. Мультикастовые рассылки - это тоже широковещание.

Но даже если ограничиваться только бродкастом подсети. Вот некий узел шлёт бродкаст. Он формирует пакет. Поскольку адрес назначения не является определённым узлом, то в пакете не указывается МАС-адрес. Пакет пошёл в сеть... И любой коммутатор, не имея этого неуказанного MAC в FDB-таблице, направит пакет на все интерфейсы, достижимые из порта источника в соответствии с его VLANID и иными настройками. Поскольку пакет идёт на L2, никаких подсетей тут нет, а потому никакое Ваше деление на подсети на распространение не влияет в принципе.

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

Ну и касательно деления вообще. VLAN поделили сеть на 2 уровне. С этого момента рассматривайте ту часть сети, которая объединяется одним VLANID, как полностью отдельную и изолированную от всех остальных сеть. Просто представьте, что коммутатор разделился на несколько маленьких, и к этому каждому маленькому подключен только один VLANID. Вот теперь в этой виртуально отделённой сети уже вводите следующий уровень деления - на подсети.

Да, смысл деления на подсети даже внутри одного VLANID - имеется. Но если Вы его не видите, значит. Вам в данный момент такое деление не нужно, и можете исповедовать принцип "в каждом вилане своя подсеть".