JDima

Осторожнее. Лишний трафик (вне зависимости от его характера) легко по биллингу (netflow например) обнаружится. Вряд ли они что-то с вами сделают, но нервы потрепать при желании смогут.

Cisco — ASA и ISR не реализует все функции.

Аса, понятно, бесполезна в этом сценарии, но вот ISR чем не устроили?

Локальная аутентификация wi-fi есть (зачем?)

Балансировка есть, причем весьма интеллектуальная — PfR, эта штука способна спасти качество сервиса для определенных (указанных) классов трафика при деградации связи, а не только при полном падении связи. Иначе — костыли на базе EEM с массой ограничений и минимумом интеллекта. В самом простом случае тупо ECMP.

Фильтрации по URL, IPS и прочие — к SM модулям.

VPN — не проблема. DMVPN для site-to-site и anyconnect для RA. Можно Flex настроить.

«быстрое обнаружение «узких мест»» — не понял вопрос. Но PfR вместе с QoS способны на многое в автоматическом режиме.

«повышение производительности сервисов, требующих широкой полосы пропускания, таких как VoIP и видеоконференции;»
Легко. Опять же, PfR, позволяющий указывать требования для разных классов трафика и автоматически выбирающий маршрут в зависимости от удовлетворения требований, плюс QoS на выходе.

«QoS;»
Запросто. Вдобавок, у ISR есть, насколько мне известно, уникальная фича «per-tunnel QoS». Суть: центральный офис будет знать про ширину канала у каждого из регионов, и сможет динамически применять политики QoS для каждого региона.

«шейпинг трафика — чтобы один сотрудник не мог занять канал когда возникает очередь, но мог использовать весь канал когда, например, он один в офисе или когда канал не полностью занят и нет очереди.»
Вы назвали это шейпингом, но на самом деле это как раз принцип работы приоритезации QoS, не имеющий к шейпингу никакого отношения.
Или подразумевается, что вешается шейпер, соответствующий ширине провайдерского канала, и в нем уже классические очереди? Это стандартная практика.

То есть по сути, ваш таргет — ISR G2, удовлетворяющий всем требованиям. Это бранчи. В центр, на терминацию VPN каналов лучше ASR1k поставить, благо они относительно недорогие — пиров многовато для ISR. Весь указанный выше функционал (кроме фильтрации URL и вирусов, который без проблем реализуется отдельной железкой) на них тоже есть.

Если есть локальная учетка на компьютере и учетка с тем же именем и паролем на сервере (отвечаю только за винду), то при обращении к сетевой папке аутентификация будет автоматической, и можно спокойно перманентно замапить диски.
Это если ну совсем-совсем никак нельзя поднять AD.

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

Какой результат получен при копировании и про прожигании iperf'ом?
Случайно не 11-12мб/с? :)

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

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

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

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

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

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

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

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

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

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

Data Communication and Networking (основной упор, был на типы сетей, протоколы, совсем немного про роутеры. но ничего не было про cloud, например).

Я не вижу смысла разработчику углубляться в сети. Однако, по опыту общения с разработчиками скажу: вы ОБЯЗАНЫ прекрасно понимать работу стека TCP/IP и в первую очередь самого протокола TCP, который на самом деле имеет массу нюансов. Но при этом то, каким образом роутеры осуществляют доставку пакета, вам едва ли потребуется, этим займутся другие люди.
Я давно сбился со счета, сколько раз мне доводилось анализировать дампы пакетов тормозящего сетевого приложения и к примеру объяснять разработчику, почему в Москве оно летает, а во Владивостоке страшно тормозит при слабо нагруженных каналах связи.
Упомянутый выше CCNA — это здорово в качестве базы. Но стоит попутно углубиться в работу TCP на конкретных конечных системах.

GSM — нельзя.
Вайфай — легко. Я сталкивался, но мое решение с большой долей вероятности не уложится в ваш бюджет, а с более дешевыми реализациями я не работал.

8-портовый управляемый свитч. По две сетевухи на компьютер с агрегацией. Формально будет «более 1гбит/с», т.е. при благополучном расположении звезд и многопоточной передаче — аж 2гб/с.

При подключении выбрать «public network». Неужели это не помогает?