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

Скорей всего, есть фоновое приложение которое начинает работать при простое и съедает ресурсы, посмотрите по диспетчеру задач. Это может быть и что-то безобидное, например бекап по сети или синхронизация облачного диска, а может быть и какой-нибудь троян с майнером/прокси/DDoS, в последнем случае есть шанс его по диспетчеру задач не увидеть. Судя по собранной диагностике выжирается у вас скорей всего сетевой канал до провайдера.

В целом при доступности обоих сетей то, какая сеть будет использована зависит больше от клиентского ПО, в этом случае браузера, потому что именно клиент выполняет разрешение имени в адрес. В большинстве случаев используется IPv6 с фолбеком на IPv4 в случае медленного соединения (Happy Eyeballs о котором писали выше), туннели IPv6 over IPv4 так же обычно пессимизируются как заведомо более медленные . Можно либо попробовать поискать соответствующую настройку для браузера, которая будет задавать приоритет разрешения имен (если она, конечно, существует) либо можно попробовать установить локальный прокси, который будет разрешать имена в нужном приоритете, например для 3proxy можно использовать такую конфигурацию

proxy -64 -i127.0.0.1 -p12345

и прописать 127.0.0.1:12345 в качестве прокси

Есть два совершенно разных типа FTP прокси - FTP over HTTP и "нативный" FTP прокси,
1. FTP over HTTP раньше использовался исключительно для браузеров, на входе принимал HTTP запрос типа GET ftp://.... и отдавал или оглавление каталога в виде HTML или запрошенный файл, сейчас браузеры FTP не поддерживают и это практически вымерло. Обычно такая функция реализовалась в HTTP-проксях. В 3proxy такая функциональность поддержанва в http proxy (proxy).
2. Нативный FTP прокси - FTP не предусматривает наличие прокси, поэтому такие серверы не стандартны. Обычно с точки зрения клиента работает как FTP сервер, но поддерживает или дополнительную команду OPEN или ищет имя сервера назначения в имени юзера, т.е. чтобы попасть пользователем vasya на сервер example.com вы подключетесь по FTP к прокси-серверу, но в имени юзера пишется vasya@example.com (прелесть в том, что такой прокси можно использовать даже с клиентами не поддерживающими FTP прокси) или перед прочими FTP-командами дается команда CONNECT example.com (для этого клиент должен поддерживать FTP прокси). В 3proxy такая функцииональность поддержана в ftppr.

Стандарт говорит что таймаут должен быть (SHOULD) но его значение устанавливается конкретной реализацией, вы можете рассчитывать на разумное время, как минимум порядка секунд если в сети нет недостатка в пуле адресов.

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

расстояние между IP-адресами в сетях ничего не значит.

Вообще-то очень даже значит, но расстояние надо считать не как модуль разницы, а как количество нулей в минимальной общей маске (т.е. если адреса попадают в сеть /28 то расстояние между ними 4).

Иногда нормируют сеть до адреса сети по информации из BGP или whois или добавляют ASN, но такие сети не всегда точны. Иногда используют подход, что вначале берутся мелкие подсети, например /24, если смежные подсети имеют одинаковые признаки, то их объединяют в более крупную подсеть и так далее итеративно.

В любой NAT/PAT таблице всегда есть таймаут, иначе если бы оба конца соединения отвалились из-за сетевых проблем или из-за ребута или плохо настроенных фаерволов, запись оставалась бы в таблице навечно. В UDP вообще нет ни одного механизма удаления записи из NAT/PAT кроме таймаута.

С одной стороны, ваш провайдер прав - в любом случае при раборе через NAT/PAT необходимо настроить TCP KEEPALIVE, он настраивается в любом ssh-клиенте, например https://songhuiming.github.io/pages/2019/02/28/how... и это единственный гарантированный способ решения вашей проблемы.

С другой стороны, 240 секунд очень маленький таймаут (обычно используется время порядка 10 минут для UDP и порядка часа для TCP) а TCP KEEPALIVE умеют слать не все клиенты, поэтому стоит продолжить ругаться с техподдержкой чтобы таймаут или размер таблицы или диапазон NAT-портов увеличили дo разумных значений.

https://3proxy.ru/plugins/PCREPlugin/

но сейчас большая часть запросов идет по https и они не видны прокси. Можно использовать подмену сертификата
https://3proxy.ru/plugins/SSLPlugin/
но я бы не рекомендовал подмену сертификата на живых пользователях.

В случае входящих соединений, очевидного лимита в 65535 соединений нет, скорей всего вы упретесь в лимит на файловые дискрипторы (сокеты), для каждого соединения нужен сокет. При этом лимиты могут быть на уровне пользовательских лимитов (и надо учесть для сервисов запускаемых через systemd действуют отдельные лимиты, а не те, которые указываются в limits.conf). Обычно по умолчаню лимиты дискрипторов в районе 1024-4096, существенно ниже 65535. Для очень большого количества сокетов необходимо будет так же менять sysctl на максимальное число открытых файлов, а возможно и пересобирать ядро, чтобы обойти заложенные верхние ограничения.

В случае исходящих соединений, вы кроме сокетов упретесь в нехватку эфемерных портов, для каждого исходящего соединения требуется отдельный эфемерный порт. По умолчанию, их в районе 16k и можно расширить до 63k через соответствующие sysctl. Выше этого значения разрешить нехватку портов можно путем добавления дополнительных IP + в зависимости от системы, может потребоваться установка флагов SO_REUSEADDR/SO_REUSEPORT/SO_PORT_SCALABILITY). Как они действуют, и какие комбинации надо использовать зависит не только от системы,но и от версии ядра, попытка разобрать есть здесь:
https://stackoverflow.com/questions/14388706/socke...
Но в случае, если исходящий трафик идет через NAT (в случае виртуализации это почти всегда так), необходимо решать аналогичную проблему на уровне NAT.

Для очень большого количества соединений вы будете упираться и в другие лимиты - sysbuf'ы, память и другие.

1. У вас в договоре с провайдером нет SLA, и вообще это не договор на сетевое подключение, а договор оказания телематических услуг. Поэтому каких-либо претензий по доступу к конкретному серверу вы предъявить не можете. Можете разорвать договор и подключиться к другому провайдеру.
2. Нельзя ориентироваться на данные трассировки маршрута для определения качественных/количественных характеристик. Маршрутизаторы по-разному обрабатывают проходящий трафик и трафик который предназначен им или генерируются ими. Большая часть маршрутизаторов ограничивают генерацию службных пакетов, в том числе ответы на пинги и другие ICMP сообщения, поэтому в WinMTR очень часто будут видны потери даже при идеальной связи.
3. Таки по вашему скриншоту не очевидно, что проблема у вашего провайдера. Никто и никогда не будет гарантировать вам работу всего Internet. Провайдер в лучшем случае может гарантировать вам качество доступа до определенных точек обмена трафиком.

Работу за NAT можно сделать функцией вашего приложения (такая функция бывает в torrent-клиентах, например), но это не самый простой функционал.

Большинство бытовых маршрутизаторов поддерживают протокол UPnP SSDP/IGD и некоторые поддерживают NAT PMP.
https://en.wikipedia.org/wiki/Internet_Gateway_Dev...
https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol
Оба протокола позволяют сделать обратный проброс порта через NAT. Для этого сначала делается запрос на обнаружение маршрутизатора, затем делается запрос собственно на маппинг. Подробно и с разбором трафика по обоим способам есть в этой статье:
https://habr.com/en/post/279969/

Но предварительно стоит уточнить, поддерживает ли ваш маршрутизатор UPnP. Оборудование enterprise-уровня обычно не поддерживает UPnP по соображениям безопасности.

3proxy в devel-версии умеет привязываться к интерфейсу (-DeINTERFACE), но должен быть для этого запущен с правами root'а

Добавьте на windows 10 статический маршрут

route add -p 169.254.0.0 mask 255.255.255.0 ip
где ip - адрес самой Windows 10, либо просто пропишите адрес из этой сети + маску в настройках сетевого подключения как дополнительный

Симметричный ключ генерируется по протоколу Диффи-Хеллмана.

Даты действия сертификата определяет валидность сертификата, если сертификат будет предъявлен до начала действия или после окончания - он не считается валидным.

Если адреса находятся в единой броадкастной сети, пропингуйте адрес W.X.Y.Z с маршрутизатора, подключенного непосредственно к сети, после этого посмотрите командой
arp -a W.X.Y.Z (Linux, Windows)
show ip arp W.X.Y.Z (Cisco)
появилась ли запись в arp-таблице с ненулевым MAC-адресом. Даже если кто-то фильтрует IP-пакет (пинг), он все равно будет виден внутри локальной сети по arp.