JDima

Ну это как бы интеллектуальное оборудование высокой доступности, ему _обычно_ положено работать годами без профилактики.
На cisco.com есть datasheet'ы по их железу. Но там немного не то. В случае серверов — с точки зрения железа периодическая их остановка на профилактику тоже не предусмотрена.

Задача какая? Обычно работы планируют по мере необходимости (например, вылез критический баг). Иногда есть политики периодического обновления с целью устранения багов по части безопасности, но и это редкость в случае сетевого железа. Да и оборудование с резервированными супами обычно умеет обновляться без прерывания связи.

По-вашему мнению это нормальная практика или нет?

Абсолютно нормальная. И любой адекватный инженер осознает необходимость этого. И ваш руководитель полностью прав. Не с юридической, а с… нравственной что ли точки зрения.
У нас платят за реально потраченное время. От первого звонка дежурных до момента решения инцидента (или возвращения домой). В период дежурства нужно быть трезвым и максимум в получасе от компьютера или любого другого средства удаленного доступа.

Вы когда выбирали профессию — не могли не понимать, что внеурочная работа — часть профессии сетевика.

Откуда уверенность, что задействованные ЦАП и динамик способны воспроизвести ультразвуковые частоты?

Стесняюсь спросить: а разбить одну большую площадь на несколько маленьких и поставить L3 ethernet коммутаторы с 10G аплинками и SFP/медными гигабитными портами — нельзя?
Почитайте это. Само собой, не без предвзятости, но там много весьма объективных моментов. Например: про наличие множества единых точек отказа. В случае правильно построенной ethernet сети можно выдернуть любую оптику или отрубить по питанию любую железку (из центральных) — и мало какой клиент заметит, что что-то случилось.

Конечно да.
Cisco.
Приличных размеров (сколько-то тысяч сотрудников).
Да никаких минусов. Работает стабильно.
TMG уже end of life. Это уже причина в скором времени менять его на что-нибудь. О других причинах сказать ничего нельзя, потому что вы не озвучили требования.

Да как бы ничего больше в голову не приходит…

Смотря какой анализ нужен. Если фиксировать наличие заранее известных пакетов, то можно разрешающий ACL повесить (если заранее известно, что пакетов очень мало, то можно даже попробовать со словом «log», но лучше без этого).

Нужна именно беспроводная? Есть проводная G19.

Варианты с балансировкой на уровне DNS не предлагать.

Почему? Все решают эту задачу именно методом DNS балансировки. См. Citrix GSLB, Cisco GSS. Метод: DNS балансировщик, держащий зону, отслеживает доступность систем и по запросам выдает адреса с нулевым TTL. Как только сервер перестал отзываться, его адрес перестает выдаваться.
Но браузеры все равно будут кешировать записи, так что если сервер упал в тот момент, когда клиент по нему бродит, где-то в течение минуты будут проблемы. dyn.com/web-browser-dns-caching-bad-thing/

Что до предложенного вами подхода с обычным балансировщиком: он предназначен не для глобальной, а для локальной балансировки.

сервером принято называть бесперебойное и непроблемное оборудование

ХА-ХА-ХА-ХА-ХА

Сделайте route print.

1) Проще всего сделать два SSID, один для полноценного просмотра, другой для редиректа через сервер.
2) Прогон трафика через прокси и обратно можно сделать средствами policy-based routing либо разделением на vrfы и статическими маршрутами в каждом (но тогда 100% трафика будет идти через прокси, что в целом тоже неплохо).

Если в требовании «Как перенаправить все запросы определенных пользователей по http на локальный сервер?» можно выделить «определенных пользователей» по IP адресу, то PBR определенно выглядит интереснее.
Только не забудьте сделать его в обе стороны.

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

В крайнем случае можете обычным графитовым карандашом зарисовать дорожки. Но очень осторожно, чтобы не было КЗ. Или наоборот, можно в первую очередь карандашом, чтобы убедиться, что проблема именно в этом.
За долговечность не ручаюсь, но в свое время «карандашные вольтмоды» были весьма популярны…

А как понимать «очень грелся мост»? Сколько градусов?

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

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

1) Договориться с тем, кто присылает вызовы.
2) Купить аналоговый шлюз на 4 FXO и 4 FXS (бессмысленно).
3) Перейти на IP телефонию, заказав у провайдера SIP на те же номера.

А может, проще SSL VPN?

1) Вопросы определенно к ТТК. После третьего хопа пакеты улетают куда-то не туда.
2) Скорее всего, это не баг, а фича. Может, внутри ОПК какие разборки, и для ТТК дешевле было пустить трафик через Франкфурт.

В любом случае, любые телодвижения с вашей стороны определенно бесполезны.

Запустите любую нагрузку. Множители сразу подскочат до положенных по уставу уровней.
Нет никакой проблемы.