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

в 3proxy

tcppm 80 host1 80
tcppm 8888 host2 8888

Так а в принципе работоспособность IPv6 проверили?
ping ipv6.google.com
проходит?
Если проходит, то в 3proxy достаточно сказать
users user:CL:password
auth strong
proxy -iIP4 -eIP6 -6 -a
IP4 и IP6 взять из ifconfig.

На уровне сети (IP) и транспорта (UDP, TCP) pid не передается. Процесс, которому предназначем полученные данные транспортного уровня, определяется по принадлежащему ему слушающему сокету, который определяется IP адресом, протоколом и портом.

На шлюз провайдера в данном случае пакет не уходит, если у вас единственное подключение и NAT настроен на вашем шлюзе.
Скорей всего происходит следующее - вы отправляете пакет на внешний адрес (шлюз), шлюз NAT'ит его на внутренний адрес сервера, сервер видит что пакет локальный и отвечает напрямую, минуя шлюз, поэтому пакет не NATится обратно и приходит с адреса локального интерфейса. Поскольку адрес ответа отличается от того, на который был послан пакет - ответ реджектится инициатором соединения.
Чтоб такого не было, обычно серверы выносят в отдельную зону (DMZ) которая роутится через шлюз.

Попробуйте понизить MTU на сетевой карте

netsh interface ipv4 set interface “Подключение по локальной сети” mtu=1200 store=persistent

В приложениях my.com MyMail и почтовой приложеньке Mail.Ru получение пушей происходит штатно, за счет серверной прослойки, которая забирает почту по IMAP и шлет пуш-уведомления. Возможно, это то, что вам требуется.

Возможно, у вас фильтруют подключенных через роутеры клиентов. Чаще всего это делается по диапазону портов или по TTL. Если по TTL - увеличьте дефолтный TTL на 1 (поищите по параметру регистра DefaultTTL), если по диапазону портов - это сложней.

Еще как вариант вы могли в какой-то момент перевести сетевую карту и беспроводую сеть в режим моста, и у сетевой карты и беспроводного контроллера может быть общий MAC, который вы прописали роутеру. Тогда отключите режим моста и/или смените MAC на беспроводном адаптере.

"Kernel bypass" может относиться к двум достаточно разным подходам: использование специальных ASIC на которые перекладывается задача обработки пакетов, например фильтрация или маршрутизация, или технологии, когда обработка сетевых пакетов полностью выносится в userspace. В любом случае, помимо аппаратной поддержки и/или специализированного оборудования, требуется поддержка технологии внутри приложения, причем во втором случае очень существенная, вплоть до реализации собственного стека TCP/IP, потому что все это идет мимо системного стека. Т.е. вы должны понимать, что вы будете получать "канальный" трафик, и работать примерно как через pcap-библиотеки.

Вы получите гораздо лучший результат, если воспользуетесь Google Apps, https://pdd.yandex.ru/ или https://biz.mail.ru/ и воспользуетесь пошаговыми инструкциями, потому что сейчас надо знать очень много нюансов, чтобы грамотно настроить почтовый сервер.

Существует такое понятие, как точка обмена интернет-трафиком (IX), например MSK-IX, SPB-IX, AMS-IX и т.п. Это точка, в которую приходит много каналов от разных провайдеров, и в которой провайдеры обмениваются трафиком между собой. Каждый из провайдеров, участвующих в обмене трафиком самостоятельно организует или арендует канал до IX. Обмен трафиком идет через оборудование и по стандартам поддерживаемым IX. Крупные сервисы не пользуются услугами провайдеров а присутствуют в IX самостоятельно, т.е. сами оперируют так же, как и провайдеры услуг. На этих же точках может вестись обмен трафика с крупными магистральными операторами, которые предоставляют в т.ч. зарубежный трафик, либо может арендоваться канал до одной из зарубежных IX.
P.S. через traceroute часто можно видеть, через какие точки обмена трафиком прошел пакет к тому или иному ресурсу.

Про DHCP и DNS выше написали, но еще совет - если вы расширяетесь только из-за увеличения адресного пространства, рассмотрите вариант со сменой сети 192.168.1.0/24 на, например, 192.168.0.0/22, это можно сделать без простоя сети и ребутов, сохранив текущие адреса и поменяв только маски.
Если просто хотите использовать адреса из другого диапазона, например с чем-то конфликтуете - не используйте 10.0.0.0/8, возьмите какую-нибудь подсеть не из самого начала, например 10.144.0.0/16 - это снизит вероятность конфликта адресов с чем-то еще в будущем и избежать еще одного ренамберинга.

Необходимо проверить настройку на роутере(виртуальном) которая обрезает количество открытых socket соединений.

поставьте легко проверяемое ограничение, например 2, и проверьте nmap'ом, что два nmap'а запустить и установтиь соединение дают, а в третьем соединение не проходит.

Разные порты=разные сокеты. Утверждение верно?

два разных соединения на один порт тоже требует два разных сокета.

По описанию очень похоже на т.н. проблему «black screen» в терминальной сессии, которая вызвана наличием на пути пакета канала с меньшим MTU (в вашем случае VPN-соединения). Т.е. не проходят крупные пакеты. Лечится уменьшением MTU на терминальном сервере.

Медиаконвертер (Media Converter) называется.

В данном случае провайдер нарушает закон.
В соответствии с п.21 правил оказания телематических услуг связи
«Договор, заключаемый с гражданином в целях пользования телематическими услугами связи для личных, семейных, домашних и иных нужд, не связанных с осуществлением предпринимательской деятельности, является публичным договором».
В соответствии с п.1 ст. 426 ГК «Коммерческая организация не вправе оказывать предпочтение одному лицу перед другим в отношении заключения публичного договора, кроме случаев, предусмотренных законом и иными правовыми актами.»

Можете смело обращаться в ФАС, прецеденты были, всегда решались в пользу абонента.

С тем, чтобы разные порты роутера прокинуть на разные серверы проблем быть не должно. Убедитесь что внешний порт у вас разный, а внутренний везде 443, попробуйте рестартануть роутер после сохранения настроек.

Можно сделать и несколько серверов на одном порту (решение, разумеется, не продуктовое, только если для себя):
1. (не обязательно) Делается сертификат на два имени (с использованием alternative names). Без такого сертификата будет ругань о несоответствии имени при подключении.
2. на одном из серверов ставится reverse proxy, например nginx
3. https пробрасывается на него
4. nginx получает содержимое от обеих серверов по Host: из запроса