Владимир Дубровин

Ответ на ваш вопрос примерно такой: вместе с командой include добавляйте команду monitor.
Правильный ответ такой: не надо вообще так делать ни в коем случае. Никогда не надо мониторить много файлов. Прокси не перечитывает отдельные файлы, он перечитывает конфигурацию целиком. Если вы записываете несколько файлов и их мониторите, всегда есть шанс что прокси считает неполную конфигурацию, т.к. какой-то другой файл будет записан только наполовину. Поэтому при сложной конфигурации мониторить надо отдельный, специально созданный для этого файл, например 3proxy.cfg.version. При обновлении конфигурации - обновлять все файлы, после этого менять 3proxy.cfg.version.

55 мегабайт в секунду (440 мегабит в секунду) это вполне нормальная скорость передачи файла по локальной гигабитной сети. Ethernet - асинхронная сеть, верхний предел в ней в принципе недостижим, он теоретический. Помимо собственно данных, передаются заголовки разных уровней, передаются широковещательные запросы, в зависимости от общей нагрузки на сеть происходят коллизии, протокол прикладного уровня может вносить свои задержки. Вы можете попытаться несколько увеличить скорость в пределах нескольких процентов за счет
- Увеличения MTU (если канальное оборудование поддержживает Jumbo Frame'ы)
- Увеличения размера окна TCP
- Сегментации сети, с целью снижения количества широковещательных запросов.
- Переход на другой прикладной протокол передачи файлов

Любые работы за пределами здания считаются строительством сооружения связи, для этого необходимо
1. Проект (должен быть выполнен организацией, имеющей лицензию на проектирование сооружений связи). Это самое сложное, потому что иногда хотят несоразмерно много денег.
2. Строительство (должно быть выполнено организацией, имеющей лицензию на строительство сооружений связи). Здесь как правило достаточно устоявшиеся цены.
А потом вам это сооружение связи придется брать на баланс.

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

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

P.S. очень часто необходимые лицензии есть у самих провайдеров. Пообщайтесь неформально с вашим менеджером, узнайте смогут ли они у вас построить или может быть дадут координаты своего подрядчика.

+ ICMP, IGMP.

На DNS все это как правило не влияет, т.к. размер DNS-пакета обычно ниже MTU. Работа TCP-соединений при неправильно выставленном MTU зависит от выставленного параметра TCP MSS со стороны сервера (многие крупные сервисы специально его занижают, т.к. неправильно сконфигурированный MTU это весьма распространенная проблема) и функционирования в системах клиента и сервера алгоритмов blackhole router detection (PMTU Black Hole Detection / PMTU probing) которые включены по умолчанию в Windows, и доступны практически во всех системах. Поэтому можно достаточно долго не замечать проблем с MTU или замечать их только в определенных ситуациях, например при отправке формы с большим количеством данных или загрузке файла на сервер.
Если проблема всплыла на ютубе, скорей всего это означает что там используется дефолтный MSS и не используются алгоритмы PMTU Black Hole Detection для видеопотоков, возможно из-за использования каких-нибудь специальных железяк с урезанной поддержкой TCP.

Попробуйте перед этим проверить, что можете подключиться к компьютеру через
net use \\IP address\IPC$
если получите ошибку, то проблема именно в этом, попробуйте подключиться анонимно
net use \\IP address\IPC$ "" /u:""
или с указанием логина/пароля эккаунта на конечном компьютере
net use \\IP address\IPC$ /user:ИМЯ_ПОЛЬЗОВАТЕЛЯ

Посмотрите
netstat -na | find "27500"
возможно у вас уже открыт порт из-под другого юзера?

Проблема может быть в том, что между клиентом и сервером NAT и на роутере из-за неактивности "протухает" запись в таблице NAT. Но решение, которое подсказали выше (keep-alive) поможет и в данном случае, только помимо собственно keep-alive'а необходимо установить keep-alive timeout секунд в 300 хотя бы, т.к. дефолтное значение (обычно 7200 секунд) вас не спасет. Т.е. помимо SO_KEEPALIVE необходимо установить TCP_KEEPIDLE/SIO_KEEPALIVE_VALS в зависимости от системы. В качестве альтернативы вы можете предусмотреть отправку keep-alive пакетов на уровне прикладного протокола. Обычно протоколы, рассчитанные на длинные соединения с небольшим трафиком, например мессенджеры, используют именно протокольные keep-alive.

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

Я думаю, что TCP здесь не причем, если только клиент не закрывает соединение не считывая ответа сервера, тогда это возможно, если на сокет не установлен linger. Но скорей всего, это просто ошибка в клиенте, разработчики не учли, что функция send() может отправить не все данные из буфера, такую ошибку разработчики не имеющие опыта написания сетевых клиентов делают достаточно часто.

Это зависит от конфигурации не только прокси, но и вашего сервера. Например, сервер может выполнять запросы наружу (типа загрузки аватара пользователя по переданному им URL) или иметь уязвимость SSI, которые раскроют его положение, или разрешать имена клиентов, что позволит определить расположение по источнику DNS-запросов. Необходимо запрещать любой исходящий трафик с сервера или перенаправлять его в прокси.

Я бы сказал, что может не просто быть 2 DMZ и больше, а вообще понятие DMZ постепенно начинает устаревать. В современной практике МСЭ, фильтры все чаще настраиваются индивидуально для каждого сервера в виде централизвоанно администрируемой политики, а для пользовательских хостов вообще используются виртуальные соединения точка-точка с авторизацией, шифрованием и политиками доступа + используются средства фильтрации на уровне системы. Т.е. фактически каждый хост с точки зрения экранирования можно рассматривать как отдельную зону. Причем фильтрация внутри хоста может быть не только по сетевым адресам и портам, а еще и по приложениям и пользователям, т.е. граница зоны безопасности с точки зрения экранирования может быть даже не на уровне хоста, а на уровне отдельного приложения или пользователя.