Да, с развитием кластеризации и распараллеливания потребность в таких монстрах снижается. Лучше с точки зрения надежности иметь несколько серверов помельче в кластере, чем один большой. Да и охлаждать его сложнее.
Но всё равно, иногда сервера с большим количеством слотов выпускаются:
Серверные материнки тоже не имеют достаточного количества слотов памяти, чтобы туда все 78 плашек запихнуть. Придется, как бы, 4-5 мамок приобретать. А это тоже будет недёшево. Плюсом еще десяток процессоров, корпуса под нестандартный форм-фактор, системы охлаждения, блоки питания с резервированием.
В розницу всё это будет стоить гораздо дороже $20000.
Когда МСЭ с SPI для NAT обрабатывает такой пакет, он открывает псевдосоединение, в котором ждёт в ответ Echo reply с того же адреса, на который через него прошёл Echo request.
Но когда мы юзаем tracert, нам не приходит Echo request с целевого хоста. Нам приходит Time Exceeded совсем с другого промежуточного хоста.
Как тогда шлюз узнает, что этот ICMP-ответ и куда нужно транслировать, а не отвергать?
... у двух разных соединений с этих двух разных машин в таблице соединений МСЭ были разные ICMP ID.
Это Вы с двух разных внутренних хостов пинговали один внешний. А если наоборот - с одного внутреннего хоста пинговать разные внешние? Как тогда внутренний хост узнаёт, от какого внешнего хоста какой ответ пришёл?
... ответ на тот самый вселенский вопрос о смысле жизни и всего остального ...
Но вот я тут подумал и понял, что не понимаю, как организован исходящий NAT для ICMP.
Раз портов в ICMP нет, то нужно опираться на какие-то другие характеристики пакета. Например на ID ICMP-пакета.
Но вот в статье https://habr.com/ru/companies/ruvds/articles/763600/#diy автор утверждает, что в Windows у всех ICMP-пакетов одинаковый ID. И как тогда не путается комп с Window, пингуя одновременно несколько внешних хостов?
То ли автор той статьи чего-то не понял, то ли не нашел реального механизма сопоставления.
Я думал, мы ведем речь про конкретную программу, которую писал конкретный специалист на конкретном предприятии. И именно к данной конкретной ситуации относились мои слова. А оно вон куда Вас занесло - обобщать на случаи, про которые я не говорил.
Т.е. исходящий проброс будет открыт NAT на шлюзе для UDP, но обратно он будет пропускать и ICMP-ответы?
Но кое-что всё равно не ясно:
Вот послали мы UDP-пакет на некий IP на порт 33434. Но ответ при достижении TTL=0 придет совсем с другого IP.
Т.е., даже если включен на шлюзе Symmetric NAT или Adress Restricted NAT, то такой ICMP-ответ не будет сходу отброшен (как ответ для неизвестного вопрошающего), а сначала будет вскрыт, узнан порт исходящего UDP-соединения, адрес вопрошающего и ему туда ответ будет перенаправлен. Правильно понимаю?
Уж не знаю, кто и за что заминусил мой предыдущий пост. Наверное, счел информацию недостоверной.
Пришлось найти это письмо из Министерства и привести выдержку из него:
На основании вышеизложенного Министерство сообщает о необходимости представления следующей информации:
Не позднее 20 числа каждого месяца, начиная с августа 2025 года, направлять информацию о создании чат-ботов в мессенджере «МАХ» предприятиями ТЭК согласно форме 1 «Чат-боты РСО».
Еженедельно (каждый вторник) направлять информацию о чатах или информационных каналах, создаваемых предприятиями ТЭК в национальном мессенджере «МАХ», согласно форме 2 «Чаты и каналы РСО».
Об итогах использования мессенджера «МАХ», а также предложения по дальнейшей разработке нового функционала данной системы в срок до 01.09.2025.
Как, откуда? Сверху из Министерства маляву прогнали, мол каждую неделю по вторникам подавать сведения об используемых в MAX ботах, каналах информированиях, чатах и группах.
VPN и MAX - это костыли для узкого круга ограниченных лиц. Обход через VPN всё сложнее поддерживать в актуальном состоянии. А MAX нормальные люди себе не ставят на личные телефоны. Да и, кроме того, в MAX не достаточно просто написать бот - его еще во всяких реестрах ботов и каналов регистрировать надо.
Программа не для организации пишется, а для души и для облегчения собственной работы.
Коллега написал свою программу мониторинга сетевой инфраструктуры (10-Strike его категорически не устраивал).
Прога реально получалась хорошая. Позволяла достаточно легко определять, к какому порту какого коммутатора подключено устройство (что позволяло найти левый комп, роутер), обнаружить конфликт адресов, сделать пробив компов по имени/IP/MAC/пользователю, инициировать подключение по теневому RDP или с использование сторонних программ Remote Control, удаленно устанавливать программы и пр.
И система оповещений работала через бот Телеграма. А теперь не работает. А без системы оповещения 90% няшек этой проги теряются.
Linux, конечно, можно было бы рассмотреть. Но не факт, что на старое железо получилось бы его натянуть без танцев с бубнами по жопе.
А новый сервер, всё-таки, подороже будет, чем 10000 в год, которые мы платим за "Контур-Толк" (до 100 пользователей в одной конфе одновременно, но у нас на планерке не более 20).
И, что касается True Conf ... Вещь, безусловно, хорошая, но при выходе из бесплатного лимита пользователей приходится платить около 13000 в год за каждого пользователя, а не только за вышедших из лимита. Так при 11 пользователях придется заплатить 143000 в год.
Сравните с 10000 для "Контур-Толк". Правда, КТ не self-hosted, но в нашем случае это не критично и даже не сильно напрягает.
Мы некоторое время юзали бесплатный (до 10 пользователей) self-hosted сервер True Conf. Но с приходом ковида бесплатной версии стало не хватать. А потом, после очередного обновления, True Conf сервер отказался работать на старом сервере с Win2K8R2.
Начали подбирать ему замену. Так из всех претендентов Телемост оказался на последнем месте. Качество картинки, даже при групповой конфе на 4 человека - убогое. Возможности создать повторяющуюся или постоянную конференцию тогда не было - приходилось бы каждый день настраивать планёрку и сообщать её номер заново.
В общем, выбрали тогда Телеграм. Но осенью, когда его начали "замедлять", снова вернулись к поиску замены. Выбрали "Контур-Толк". Удобный, недорогой. Правда, регистрация заморочная - не только лишь все способны её пройти без подсказок даже по инструкции. Но качество связи весьма хорошее.
Да, с развитием кластеризации и распараллеливания потребность в таких монстрах снижается. Лучше с точки зрения надежности иметь несколько серверов помельче в кластере, чем один большой. Да и охлаждать его сложнее.
Но всё равно, иногда сервера с большим количеством слотов выпускаются:
https://3dnews.ru/1108212/gigabyte-vipustila-servernuyu-platu-r283zk0-standartnogo-razmera-2u-osnashchyonnuyu-48-slotami-dlya-operativnoy-pamyati-ddr5-rdimm?ysclid=moa8v6sl9a511276313
У нас есть один сервак с 32 слотами. Но используются пока что только 8 из них.
Серверные материнки тоже не имеют достаточного количества слотов памяти, чтобы туда все 78 плашек запихнуть. Придется, как бы, 4-5 мамок приобретать. А это тоже будет недёшево. Плюсом еще десяток процессоров, корпуса под нестандартный форм-фактор, системы охлаждения, блоки питания с резервированием.
В розницу всё это будет стоить гораздо дороже $20000.
Вот спёр то, что самому ему не нужно. Пока будет покупателя искать - цены упадут, а потом DDR4 ECC RDIMM вообще станет никому не интересна.
Нужно было сервер целиком выносить - больше шансов пристроить.
Но когда мы юзаем tracert, нам не приходит Echo request с целевого хоста. Нам приходит Time Exceeded совсем с другого промежуточного хоста.
Как тогда шлюз узнает, что этот ICMP-ответ и куда нужно транслировать, а не отвергать?
Это Вы с двух разных внутренних хостов пинговали один внешний. А если наоборот - с одного внутреннего хоста пинговать разные внешние? Как тогда внутренний хост узнаёт, от какого внешнего хоста какой ответ пришёл?
Неужели, "42"?
Спасибо. Это именно то, что я хотел уточнить.
Но вот я тут подумал и понял, что не понимаю, как организован исходящий NAT для ICMP.
Раз портов в ICMP нет, то нужно опираться на какие-то другие характеристики пакета. Например на ID ICMP-пакета.
Но вот в статье https://habr.com/ru/companies/ruvds/articles/763600/#diy автор утверждает, что в Windows у всех ICMP-пакетов одинаковый ID. И как тогда не путается комп с Window, пингуя одновременно несколько внешних хостов?
То ли автор той статьи чего-то не понял, то ли не нашел реального механизма сопоставления.
Я думал, мы ведем речь про конкретную программу, которую писал конкретный специалист на конкретном предприятии. И именно к данной конкретной ситуации относились мои слова. А оно вон куда Вас занесло - обобщать на случаи, про которые я не говорил.
Ого!
Т.е. исходящий проброс будет открыт NAT на шлюзе для UDP, но обратно он будет пропускать и ICMP-ответы?
Но кое-что всё равно не ясно:
Вот послали мы UDP-пакет на некий IP на порт 33434. Но ответ при достижении TTL=0 придет совсем с другого IP.
Т.е., даже если включен на шлюзе Symmetric NAT или Adress Restricted NAT, то такой ICMP-ответ не будет сходу отброшен (как ответ для неизвестного вопрошающего), а сначала будет вскрыт, узнан порт исходящего UDP-соединения, адрес вопрошающего и ему туда ответ будет перенаправлен. Правильно понимаю?
Не совсем понятно, как будет проходить обратный ICMP-пакет через NAT?
Особенно, если на промежуточных роутерах включен Symmetric NAT или Port Restricted NAT или Adress Restricted NAT?
В оригинале, должно быть, просто 1 + O(1/logx). Так же как и Sum(O(1/a*loga)).
К сожалению, ссылка на оригинал у меня не открывается:
https://www.erdosproblems.com/forum/thread/1196
Уж не знаю, кто и за что заминусил мой предыдущий пост. Наверное, счел информацию недостоверной.
Пришлось найти это письмо из Министерства и привести выдержку из него:
Не позднее 20 числа каждого месяца, начиная с августа 2025 года, направлять информацию о создании чат-ботов в мессенджере «МАХ» предприятиями ТЭК согласно форме 1 «Чат-боты РСО».
Еженедельно (каждый вторник) направлять информацию о чатах или информационных каналах, создаваемых предприятиями ТЭК в национальном мессенджере «МАХ», согласно форме 2 «Чаты и каналы РСО».
Об итогах использования мессенджера «МАХ», а также предложения по дальнейшей разработке нового функционала данной системы в срок до 01.09.2025.
Как, откуда? Сверху из Министерства маляву прогнали, мол каждую неделю по вторникам подавать сведения об используемых в MAX ботах, каналах информированиях, чатах и группах.
VPN и MAX - это костыли для узкого круга ограниченных лиц. Обход через VPN всё сложнее поддерживать в актуальном состоянии. А MAX нормальные люди себе не ставят на личные телефоны. Да и, кроме того, в MAX не достаточно просто написать бот - его еще во всяких реестрах ботов и каналов регистрировать надо.
Программа не для организации пишется, а для души и для облегчения собственной работы.
Ну, Вы еще спросите, распространяются ли законы РФ на соцсети, электронные СМИ и ОРИ других стран :D
Не появится.
Есть у нас закон, обязующий хостеров блокировать доступ от себя к запрещенным ресурсам.
Он пока что не работает. Но и блокировка VPN тоже не сразу работать начала.
Так что, либо зарубежные хостеры будут блокировать доступ, либо доступ к ним самим заблокируют.
В какую сумму обходится?
Наверное, поднимать VRS ради одного бот-сервера, совершенно не имеет смысла.
Сервер, я же говорю, был старый. Hyper-V не поддерживал. VMWare - не вариант.
Единственно, VirtualBox можно было попробовать. Но городить такую матрёшку ради дорогущего True Conf сервера - не интересно.
Бизнес - это хорошо. Но как в МАХ создать бота частному лицу?
Боты - это боль.
Коллега написал свою программу мониторинга сетевой инфраструктуры (10-Strike его категорически не устраивал).
Прога реально получалась хорошая. Позволяла достаточно легко определять, к какому порту какого коммутатора подключено устройство (что позволяло найти левый комп, роутер), обнаружить конфликт адресов, сделать пробив компов по имени/IP/MAC/пользователю, инициировать подключение по теневому RDP или с использование сторонних программ Remote Control, удаленно устанавливать программы и пр.
И система оповещений работала через бот Телеграма. А теперь не работает. А без системы оповещения 90% няшек этой проги теряются.
Linux, конечно, можно было бы рассмотреть. Но не факт, что на старое железо получилось бы его натянуть без танцев с бубнами по жопе.
А новый сервер, всё-таки, подороже будет, чем 10000 в год, которые мы платим за "Контур-Толк" (до 100 пользователей в одной конфе одновременно, но у нас на планерке не более 20).
И, что касается True Conf ... Вещь, безусловно, хорошая, но при выходе из бесплатного лимита пользователей приходится платить около 13000 в год за каждого пользователя, а не только за вышедших из лимита. Так при 11 пользователях придется заплатить 143000 в год.
Сравните с 10000 для "Контур-Толк". Правда, КТ не self-hosted, но в нашем случае это не критично и даже не сильно напрягает.
Мы некоторое время юзали бесплатный (до 10 пользователей) self-hosted сервер True Conf. Но с приходом ковида бесплатной версии стало не хватать. А потом, после очередного обновления, True Conf сервер отказался работать на старом сервере с Win2K8R2.
Начали подбирать ему замену. Так из всех претендентов Телемост оказался на последнем месте. Качество картинки, даже при групповой конфе на 4 человека - убогое. Возможности создать повторяющуюся или постоянную конференцию тогда не было - приходилось бы каждый день настраивать планёрку и сообщать её номер заново.
В общем, выбрали тогда Телеграм. Но осенью, когда его начали "замедлять", снова вернулись к поиску замены. Выбрали "Контур-Толк". Удобный, недорогой. Правда, регистрация заморочная - не только лишь все способны её пройти без подсказок даже по инструкции. Но качество связи весьма хорошее.