Клиентское приложение не может «полностью» подключиться к серверу виртуальной машины, кроме как через VPN.

Этот случай оказался для меня крепким орешком. Слишком жестко. Я думаю, что это может стать хорошим вызовом для гуру.

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

Виртуальные машины разделены на различные подсети с помощью мостов (vmbr0, vmbr1 и т. д.). Основной сетевой адаптер подключен к vmbr0, имеющему общедоступный IP-адрес.

Я настроил переадресацию и маскировку IP (собираюсь изменить это на SNAT после всего, что я недавно узнал об устранении неполадок). Все виртуальные машины подключены к сети и почти все работает отлично.

На хосте установлен прокси-менеджер NGINX, который помогает перенаправлять запросы на правильный внутренний IP-адрес и оборачивать их в SSL, что прекрасно работает.

Теперь в одном из этих веб-приложений, работающих на одном из серверов Windows 2019, есть приложение для получения оповещений и уведомлений (это для системы RTLS, для тех, кто знает, что это такое). Это приложение предназначено для работы на клиентских компьютерах (в настоящее время тестируется на домашнем ноутбуке и подключается к порту 80 сервера. Чтобы обойти обратный прокси-сервер, я перенаправил порт 8081 на внутренний IP-адрес виртуальной машины:80, и приложение подключается, сообщая всем серверам подключен зеленый свет.

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

Я подумал, что это из-за настройки сети, и попытался подключить клиентский ноутбук напрямую к виртуальной машине с помощью Wireguard VPN, и тогда все работает отлично, что почти доказывает, что это проблема с сетью.

Я запустил tcpdump на клиентском ноутбуке, хосте и виртуальной машине, пытаясь определить, где что-то идет не так, но не вижу ничего плохого. Кстати, это все TCP. Самое близкое к проблеме, которое я видел, это то, что иногда я вижу некоторые пакеты с флагом «F», у которых обратный порт отличается от обычного обратного порта. Всякий раз, когда пакет покидает клиента с обычным обратным портом, он получает ACK и отправляется туда и обратно, но этот пакет с другим обратным портом и флагом F, похоже, никогда не получает ответа, поэтому клиент снова отправляет его обратно. и еще раз, но так и не получил ответа. Я вижу, что этот пакет обычно снова и снова подтверждает один и тот же порядковый номер.

Должны ли пакеты, помеченные буквой F, вообще получать ACK? Я не знаю, реальная ли это проблема или нет. Кстати, все межсетевые экраны в настоящее время отключены для тестирования.

Некоторые другие странные вещи, которые могут помочь, а могут и не помочь пролить свет на проблему: если я подключаюсь через VPN, но говорю приложению подключаться через общедоступный IP-адрес и перенаправленный порт, я вижу в tcpdump, что оно делает то, что сказано, но всякий раз, когда он получает предупреждение, он начинает отправлять трафик через VPN! И тогда это работает... tcpdump по какой-то причине не позволяет мне заглянуть внутрь интерфейса wg, поэтому я не вижу порты и т. д., которые там используются.

Другое дело, что приложение, похоже, либо выполняет обратный поиск IP-адреса, либо проверяет имя хоста, потому что, когда я подключаюсь через общедоступный IP-адрес и навожу указатель мыши на значок сервера, оно отображает доменное имя центра обработки данных для сервера (ns-2412dfu.eu.blabla), и когда я подключаюсь через VPN, он показывает фактическое имя хоста виртуальной машины.

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

Как мне понять, что здесь не так?