res2001

Что делаете, что бы восстановить гигабит?

Проблемы могут быть на любом участке между компом и свичем:
1. дохнет или глючит свич/порт в свиче;
2. сетевой адаптер компа (но вы уже меняли на другой, так что это видимо не оно)
3. плохой контакт в одном из патчкордов, разъемов, розеток
4. кривые драйвера сетевого адаптера.

Что можно предпринять:
1.Найдите свежие драйвера для сетевого адаптера и переустановите
2.Замените патчкорды, которые сможете.
3.Переткните в другой порт на свиче, а лучше - в другой свич.
4. Для подключения компа используйте другую розетку

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

Найдите в сети книгу: У.Р. Ственс. Unix. Разработка сетевых приложений.
Одна из лучших книг по теме, хоть уже и старовата.
Не смотря на то что там UNIX, но подход один и тот же практически для всех ОС.

"Локальной сети нет" - это обычно не верное утверждение.
Возможно вашим WiFi пользуются соседи: пора сменить пароль, включить WPA2 и выключить WPS.

Похоже на глюк конкретной реализации.

1.Часто браузер для одного сайта открывает не одно соединение, а сразу пачку и качает ресурсы параллельно. Порты в этом случае для каждого соединения разные. Кроме того на одной странице могут быть ссылки ведущие на разные сайты, для них браузер открывает новые соединения.
2.Как было сказано порт выбирает ОС. При открытии сокета браузер указывает, что нужен "любой локальный порт". Считайте, что ОС выбирает первый свободный порт из динамического диапазона. На самом деле сложнее, конечно, но конкретный алгоритм обычно не важен.
3.В общем случае шлюз с NAT подменяет и адрес и порт, поэтому сервер увидит не адрес и порт отправителя, а адрес и порт шлюза. Все это происходит прозрачно для сервера и для клиента. Клиент думает, что он общается на прямую с сервером, а сервер думает, что клиент - это шлюз с NAT и не подозревает, что по пути пакета реальный адрес/порт клиента был подменен NATом.

Видимо NAT мешает. В подобном случае NAT всем мешает.
Нужно либо настраивать NAT на шлюзе (проброс портов), либо обмениваться трафиком через сервер, а не напрямую.
Если приложение "для внутреннего использования" или для узкого круга лиц, то обычно нет проблемы настроить NAT, если же предполагается массовое распространение, то это не вариант и нужно искать обходные пути.
Для UDP протокола есть вариант использовать внешний STUN сервер. Для TCP, по моему, этот вариант не работает.

Как альтернатива микротику - у асуса старшие модели не плохие, прошивки имеются.

STUN видимо. Это то же "хак" для обхода NATа. Есть еще вариант с UPnP, но по моему его мало кто использует.

Т.к. нет возможности все ПО настроить на хождение через прокси, то вместо него нужно использовать ВПН. Вариант с ВПН не зависит от поддержки ПО, он работает на более низком уровне. Нужен вариант ВПН, который бы поддерживался всеми платформами на которых вы работаете, например OpenVPN.
В остальном схему вы правильно описали.
Было бы удобнее арендовать для ВПН сервера VPS/VDS. В этом случае на ВПН сервере нужно будет поднимать NAT, но это не является проблемой.

Используйте не ВПН, а прокси. В прокси нет шифрования, поэтому гораздо выше пропускная способность.

Это возможно только если само устройство это умеет, иначе никак.
Роутеры/коммутаторы обычно поддерживают управление по ssh, а это уже можно как-то автоматизировать. Но тут нужно плясать от конкретной железки, чего-то универсального нет.

Минимальная частота дискретизации в вашем случае 10.2 КГц.

Видимо у вас в сети уже 2 DHCP сервера, конфликты получаются по тому что в одном случае первым успевает отдать адрес один сервер, а в другом - другой. Нужно просто выключить один из DHCP.

По большому счету это не сильно важно как у вас обжаты коннекторы, главное (в общем случае), чтобы с обоих концов они были обжаты одинаково.
Я как-то устроился работать в одну контору, там до меня двое парней обжимали пачкорды, каждый по своему. Ими была написана инструкция, там показано кто как обжимает в картинках, чтоб можно было найти виновного, если что :-) Потом еще долго выковыривал эти пачкорды из сети.

Скорее это поверх текущей инфраструктуры лег интернет и юзает ее, но это не означает, что он владеет инфраструктурой монопольно. Интернет способствует развитию сетей, протоколы интернет из-за своего широкого использования наиболее обкатаны и стабильны и их можно применять и в других сетях - уберите шлюз в интернет из любой локальной сети предприятия - вот вам частная сеть, построенная на технологиях интернет (то что в 90е называли Интранет).
Вам никогда не приходилось арендовать у оператора связи канал точка-точка? Грубо можно представить ГАС выборы как множество каналов точка-точка, объединенных где-то в ЦИК.

Подключайте все кабели в LAN порты, настраивайте на нем DHCP (на других выключайте).

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

Кучно пошло.
Вам поможет NAT.
Только вы боитесь прокси. А открывать слушающий порт в интернет вы не боитесь? Бойтесь! Как только вы выйдите в мир, вас тут же начнут ломать - начнутся подключения с левых адресов, подбор паролей и т.д. и т.п. Поэтому без серьезной подготовки софта лучше не выставлять его в инет.
Организуйте ВПН и выставляйте вашу программу внутри ВПН.