Владимир Пилипчук

Архитектура решения не верная в корне. Кто это делал? Сын маминой подруги в героиновом трипе?
Прикрепите схему коммутации решения. Уверен, там у вас все очень интересно.

У вас как минимум несколько функциональных доменов:

1. Networking
   
2. Applications
   
3. Infrastructure
   
4. Backups
   

Держать все это в одном сегменте - не лучшее решение. Плохо предсказуемое поведение и практически не управляемое.

Лучше все же использовать inter-vlan routing и строить управление L2/L3 отдельно.

Например, если хочется активной балансировки, multi-homing и всего такого - поднимаем нужное количество VLAN, BGP/EIGRP, и упариваемся в shortcut/TE.

Если все же физически сервер один, и приобретать дополнительные не хочется (при условии того, что ресурсов достаточно) - превратите железку в полноценный сервер на базе VMware / Hyperv и поднимите на нем все необходимое по отдельности. Разделите уровни пользователя, приложений и инфраструктуры. они не должны пересекаться и аффектить друг на друга.

Udp натится с оговорками. И одна из причин прописана в rfc. И порт обязательно будет меняться. Только конусный нат возможен.
Читайте разницу в трансляциях tcp и udp.

Павел Межуев хороший вариант предложил.
Я бы дополнил следующим:

SNR-S2982G-8T - не достаточно для построения такой топологии. Я бы использовал что-то помощнее. Либо L3-коммутатор, либо маршрутизатор.

Разбить сеть на /24 VLANы
- в каждом офисе для пользователей свой VLAN
- для серверной подсети свой VLAN
- для сети управления свой MGMT VLAN
Связность между бранчами лучше городить на L2, если есть возможность. И если так, то лучше использовать QinQ на транспорте, чтобы нативно иметь связность между офисами на L2 и получить PortMash сеть. Вдруг нужно будет потом VLAN из одного офиса кинуть в другой/другие. Это более универсальная топология, позволяющая менять архитектуру СПД on-the-fly.
Между CE поднимаем OSPF/BGP/EIGRP/etc. Это позволит более эффективно управлять маршрутизацией.

Вопроса два - кто занимается указанием MIME и какие типы указаны в конфигурации?
"В лоб" решение - в нужном location указать add_header Content-Type image/jpg; Но это не очень правильно.

Вот тут найдете ответ

Тот который ему присвоит оператор сети. ipv4/v6 очевидно. Скорее всего из приватного диапазона.
Белый/серый... это такие условности... в любом случае Вам нужно эти вопросы задавать не здесь, а оператору.

BVI обычно используется для подсети доступа к самой точке. На него обычно садят подстеть управления, а пользовательские вайфаи отдают vlan-ами на сабинтерфейсах. BVI - это бридж. Для чего его использовать или нет - решать Вам.

Отсутствует роутинг. Отсутсвует NAT целевых vlan.
маршрутизации 0.0.0.0/24 на 10.99.100.1 - это роутинг локального трафика самого коммутатора, а не ваших vlan. Их вы должны сроутить на маршрутизаторе, и там же настроить NAT.

Для EIGRP нет необходимости в DR/BDR, так как каждый роутер знает всю топологию и все возможные маршруты до узла назначения, выбирая при этом лучший(лучшие) маршрут в зависимости от дистации, загрузки канала, задержки и т.д. Для "тупиковых" роутеров можно указать STUB-сеть в анонсах, со всеми вытекающими.
Это позволяет организовать балансировку трафика между узлами, указав нужный variacnce. Например, если до точки назначение имеется 2 маршрута, то при указании variance 2 в таблицу маршрутизации попадет 2 "лучших" маршрута, между которыми будет распределен траффик примерно 50/50.

show arp разве там нет?

sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.38.20.56            67   a88e.2437.403a  ARPA   Vlan382
Internet  10.38.40.4             77   0008.3100.0e03  ARPA   Vlan384
Internet  192.168.192.168         -   9c4e.20d0.9941  ARPA   Vlan5
Internet  10.38.0.45             13   1cb7.2c1c.cded  ARPA   Vlan38

Простите, но хотелось бы понять сакральный смысл сего действа. Возможно вам будет удобнее пойти иным путем.
Что касается сетевого оборудования Cisco (маршрутизаторы и коммутаторы), то мне не известен функционал IOS/IOS-XE который бы позволял так глубоко вмешиваться в трафик.
Serial оборудования можно получать и по SNMP. А вот если у вас стоит идентификация устройства в топологической иерархии по данному параметру, то здесь, мне кажется, нужно не к Serial а к Hostname привязываться, который легко шьется тем-же SNMP.
Чтобы ничего не перенастраивать в боевой среде, необходимо настраивать оборудование до его установки в прод. Это называется "ввод в эксплуатацию". В противном случае costЫl.sh будет сопровождать Вас вечно.

Прроблема в маршрутизации, если сервер настроен верно и нет проблем с шифрованием.
При поднятии PPTP необходимо прописать необходимые маршруты на клиенте.
PPTP не инжектит маршруты клиентам.
Как там Windows работает с VPN - мало осведомлен, так как уж очень много там "магии", однако в никсах все решается добавлением нужного маршрута.

я делаю так (до известного BT-трэкера)

#!/bin/sh
# обозначаем возможные переменные для проверок
ifname=$1        # имя интерфейса pppd (e.g. ppp0)
ttyname=$2       # Имя tty-устройства 
speed=$3         # скорость tty-устройства
localip=$4       # локальный IP интерфейса
remoteip=$5      # IP-адрес удаленного "конца" туннеля
ipparam=$6       # текущий IP address до подключения к VPN

#192.168.0.1 - адрес Вашего VPN-шлюза

case "$remoteip" in
    192.168.0.1)
        /sbin/route add -net 195.82.146.0/23 -interface $ifname
        ;;
esac
exit 0;

Если у вас гостиница, то я бы настаивал на инвестиции в нормальные коммутаторы.
По стоимости получите то-же самое, а вот в управлении получите профит:
Для обеспечения изоляции клиентов на L2 и простого роутинга - настраиваете private vlan.
Для беспроводных клиентов, на Uni-fi можно настроить релей option 82 и option 43 (если захотите)
Собираете аплинки всех коммутаторов на магистрали и одним проводом отдаете транк на любой линуксовый или аппаратный роутер, с поддержкой танков. Раскрываете нужные вам vlan на сабинтерфейсах и маршрутизируете как пожелаете.
ТАкой подход избавит вас от паразитного трафика, снизит нагрузку на маршрутизаторах и коммутаторах, а управление всей сетью станет простым и прозрачным. Ну и РКН будет сложнее докопаться.

После курения разных мануалов и путей самурая решил вопрос сделующим образом

ip nat inside source static tcp 10.10.45.2 25 ISP1_IP 25 extendable
ip nat inside source static tcp 10.10.45.20 25 ISP2_IP 25 extendable

ip route 0.0.0.0 0.0.0.0 ISP1_IP
ip route 0.0.0.0 0.0.0.0 Dialer0 10
!
ip access-list extended NAT
permit ip 10.10.45.0 0.0.0.255 any
ip access-list extended SRV1
permit ip host 10.10.45.2 any
permit ip host 10.10.45.3 any
ip access-list extended SRV2
permit ip host 10.10.45.20 any
permit ip host 10.10.45.30 any
!
route-map NAT-CLIENT-ISP2 permit 10
match ip address NAT
match interface Dialer0
!
route-map NAT permit 100
match ip address SRV1
set default interface FastEthernet0
!
route-map NAT permit 200
match ip address SRV2
set default interface Dialer0
!
route-map NAT-CLIENT-ISP1 permit 10
match ip address NAT
match interface FastEthernet0

Вроде работает.

Спасибо за ответ, проблема оказалась куда забавнее — от меня до серверов фэйсбука и некоторых других (с учетом моих двух роутеров) было более 255 хопов.
Наши провайдеры расчитаны в основном для домашних пользователей и предполагают, что шнурок втыкается на прямую в комп. После смены роута у провайдера все заработало.