Akina

Хост 100.124.0.1

Провайдер врёт, что он в душе не гребёт, какой это [censored] использует этот адрес. Потому что этот [censored] - именно сам твой провайдер. Это же второй хоп - ну о чём вообще речь? Ну или ты попадаешь на первую линию техподдержки, где сидит нечто не очень грамотное, способное только зачитывать по телефону простейшие инструкции из ЧаВо...

К слову, это зарезервированный адрес:

RFC 6598

IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space.

The Shared Address Space address range is 100.64.0.0/10.

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

И лишь на 4 хопе ты выходишь на Совинтел (87.229.204.182).

PS. А если бы на месте этого адреса был бы какой-то 10.11.12.1 (или другой богон-адрес, но из широко известных серых подсетей) - тебе бы сильно это помогло? Хотя... тогда было бы проще доказывать провайдеру, что косяк на его стороне.

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

Может ли мобильный оператор блокировать интернет при подключении компьютера?

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

Destination Host Unreacheable, если перевести с буржуинского, означает "Хост назначения недостижим".
Если переводить дальше - на обывательский, то это означает "У меня нет маршрута (адреса шлюза), через который я должен послать пакет узлу назначения".

Следовательно, хост 192.168.0.108 не имеет необходимого для общения с указанным адресом 52.43.49.19 дефолтного либо частного маршрута.

А с узлами своей подсети он общается напрямую, без шлюза. То есть виртуальный коммутатор функционирует нормально.

Я бы

1. Убрал неуправляемый коммутатор и соединил серверы напрямую (необязательно, но зачем лишняя фигня в сети?)
   
2. Поставил на обоих серверах гигабитные интерфейсы в автополучение адреса
   
3. Отключил на 100-мегабитных картах NetBIOS over TCP/IP (хотя это уже зависит от того, какие ресурсы и через какие пространства имён нужны в сети)
   
4. Дождался бы самовыделения APIPA-адресов (169.254) на обоих серверах
   
5. Прописал перекрёстно полученные адреса и соответствующие им имена серверов в HOSTS и в LMHOSTS
   

Итоги:

1. Серверы доступны друг другу по имени
   
2. При обращении по имени связь будет устанавливаться через этот канал (через гигабитные карты), а не через 100-мегабитные карты
   
3. Гарантированно не будет пересечения по диапазону адресов с другими системами в сети
   

Я в упор не понимаю, зачем тут вообще маршрутизация.

Все интерфейсы 10G - NAS, компьютер и Mikrotik,- помещаем в одну подсеть.
Интерфейс 1G - компьютер и Mikrotik,- помещаем в другую подсеть.
Для исключения L3-петли в файрволе Микротика блокируем любой трафик от и на адрес 10G интерфейса компьютера.

На компе дефолтным шлюзом адрес 1G интерфейса Mikrotik.
На NAS дефолтным шлюзом адрес 10G интерфейса Mikrotik.

Микрот - с компьютером и NAS общается напрямую, ибо одна подсеть, а в Инет идёт через свой WAN.
NAS - с компьютером и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.
Компьютер - с NAS и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.

Т.е. никакие маршруты, кроме маршрутов по умолчанию, в системе вообще не требуются.

Хотя согласен с предыдущими ораторами - дополнительный 1G линк явно избыточен.

хотелось бы больше подробностей

Если коротко.

Из Инета можно обратиться только к "белому" адресу. На NAS - "серый" адрес. Значит, нужен посредник (NAT-роутер). На нём будет работать port forwarding.

Работает оно так. На роутере-посреднике два интерфейса - внешний белый и внутренний серый. Создаётся правило: "Если что-то пришло на внешний адрес на порт XXX, переслать это на внутренний адрес YYY на порт ZZZ". В соответствии с этим правилом клиент снаружи стучится на внешний белый адрес на порт XXX, роутер от своего имени шлёт этот пакет с внутреннего адреса на адрес YYY (NAS) порт ZZZ. То есть с точки зрения самого NAS к нему обращается не внешний клиент, а роутер. Он отвечает роутеру. Роутер по запомненным характеристикам соединения делает обратное преобразование и шлёт ответ NAS клиенту от своего имени.

Если внутренний сервис требует для работы более одного порта - для каждого будет создано своё правило преобразования.

Отслеживать - нет.
Можно написать скрипт, который будет получать текущую таблицу (interface bridge host print либо interface ethernet switch host print) и сравнивать с предыдущей версией. По результатам сравнения сообщать. Период запуска, само собой, меньше времени жизни записи в кэше.
Хотя разумнее одним скриптом сливать в файл, а потом другим скриптом обрабатывать и кляузничать - но уже не так часто. Или вообще в БД писать, для истории...

SNR-SFP-W35-3 1000BASE-X 3km, 6dB TX 1310nm/RX 1550nm - это одномодовый свисток. Одноглазый, кстати.
ML-SG-2DFM-31LD 1.25G SFP 1310nm 2KM DDM - это многомодовый свисток. Вообще двуглазый.

Они говорят на разных языках. Работают на разном волокне. И никогда друг друга не поймут.

Mission impossible.

Между маршрутизаторами внутри частной сети WAN или LAN?

Частная - это по-ихнему private.
Private network - это подсеть, которая не маршрутизируется в Интернете (явно или условно). В первую очередь подсети "серых" адресов (RFC 1918), но вообще таких подсетей (именуемых bogon networks) под полтора десятка.
Сеть, адресация которой построена на не маршрутизируемых глобально адресах - это LAN.

Суёшь линк/ярлык в
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Оборудование на другом конце - ситуация штатная. Тестер обязан её предусматривать, в т.ч. и вариант с PoE.

Про убитый тестером порт даже не слышал. Но если такое произойдёт, то это будет явно следствие неисправности тестера. Либо "после, но не вследствие".

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

Какое преимущество для текущей конфигурации обеспечивает настройка сетей VLAN?

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

В этом случае деление на VLAN однозначно убирает взаимную "видимость" узлов, включённых в разные VLAN, а также разделяет широковещательный трафик. Опять же безопасность и всё такое...

Можно же взять S1 и подключить к нему PC1, PC4 и т.д.

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

Так что никаких "можно же взять" - нельзя, и точка.

Есть 2 созданных сети на этом dhcp 10.0.0.1-10.0.0.100 и 10.1.1.1-10.1.1.100.

Это НЕ сети. Это диапазоны выделяемых адресов (scopes).

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

Gateway имеет ip адрес 10.0.0.1.

Это чей gateway? Операционной системы, на которой работает DHCP? Или это значение параметра в настройках скопа, отдаваемое сервером клиенту?

Это gateway куда? Шлюз по умолчанию? Шлюз в подсеть? Что-то ещё?

Каким образом можно указать для сети 10.1.1.1-100 gateway 10.0.0.1 , чтобы например, контейнеры proxmox, которые будут находиться в этой подсети имели выход в интернет ?

Самое простое - объединить скопы одной подсетью.
Соответствующая маска - /23 или шире.

не до конца наверное понимаю работу 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, конфигурациям и пр... чтобы в конце прийти к полной схеме.

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