Вопрос или проблема
Я надеюсь, что кто-то сможет мне помочь, потому что ситуация очень сложная/неразбериха.
Я объясню ситуацию.
У меня есть 2 локации: SiteA и SiteB.
Они соединены через VXLAN по IPSEC между собой с 2 брандмауэрами OPNSense.
Сеть, которой они делятся, имеет адрес 192.168.180.0/24
Я установил MTU на 1400 на 6 серверах Proxmox в 2 локациях (3 в SiteA и 3 в SiteB) и MTU на 1400 на интерфейсах OPNSense (как на интерфейсе VXLAN, так и на локальном интерфейсе в 192.168.180.0/24).
На OPNSense я также создал некоторые правила нормализации брандмауэра на интерфейсах VXLAN и LAN, чтобы уменьшить mss до 1250.
Я провел различные тесты с iperf и с передачей через scp, создав 2 контейнера LXC, один в SiteA с адресом 192.168.180.150 и один в SiteB с адресом 192.168.180.151.
С iperf производительность составляет 400 МБ/с. Если я выполняю scp между 2 контейнерами, скорость хорошая.
Проблема в следующем: я нахожусь дома с ноутбуком (у меня оптоволоконное соединение 2.5 Гбит/с)
Я использую OpenVPN для подключения к OPNSense в SiteA и создал некоторые правила, чтобы убедиться, что я также могу добраться до серверов в SiteB.
Пинг хороший в обеих локациях.
SiteA
$ ping 192.168.180.150
PING 192.168.180.150 (192.168.180.150) 56(84) байт данных.
64 байта от 192.168.180.150: icmp_seq=1 ttl=63 время=13.6 мс
64 байта от 192.168.180.150: icmp_seq=2 ttl=63 время=14.0 мс
SiteB
$ ping 192.168.180.151 (SiteB)
PING 192.168.180.151 (192.168.180.151) 56(84) байт данных.
64 байта от 192.168.180.151: icmp_seq=1 ttl=62 время=17.7 мс
64 байта от 192.168.180.151: icmp_seq=2 ttl=62 время=17.7 мс
64 байта от 192.168.180.151: icmp_seq=3 ttl=62 время=18.9 мс
Если я выполняю iperf с моего ПК на 192.168.180.150 в SiteA, я получаю хороший результат, 20 Мбит/с.
Даже если я выполняю scp 100 МБ файла на 192.168.100.150, производительность приемлемая: 3 МБ/с.
Проблемы начинаются, когда я подключаюсь к 192.168.180.151 в SiteB:
iperf очень медленный:
iperf -c 192.168.180.151
[ 1] 0.0000-20.8590 сек 336 Кбайт 132 Кбит/с
Но худшее – это scp, которое зависает на несколько секунд перед началом:
$ scp 100mb.img [email protected]:/root/
100mb.img 0% 0 0.0KB/с - зависает -
После нескольких секунд (даже минуты) ожидания, в какой-то момент передача начинается с довольно хорошей скорости.
Сначала скорость составляет 100 КБ/с, но затем достигает 2.0 МБ/с.
$ scp 100mb.img [email protected]:/root/ 100mb.img 79% 75MB 2.1MB/с 00:09 ETA
Как я могу решить это странное поведение? Почему в начале так медленно, а затем в какой-то момент улучшается?
Я запустил tcpdump на моем ПК, чтобы увидеть трафик:
tcpdump -nn -i tun0 host 192.168.180.151
Вот последние пакеты, которые я вижу во время “зависания”:
14:37:53.360278 IP 10.70.155.6.36894 > 192.168.180.151.22: Flags [P.], seq 104:156, ack 57, win 331, options [nop,nop,TS val 3667267481 ecr 4040040446], length 52
14:37:53.380470 IP 192.168.180.151.22 > 10.70.155.6.36894: Flags [P.], seq 57:85, ack 156, win 160, options [nop,nop,TS val 4040060442 ecr 3667267481], length 28
14:37:53.380537 IP 10.70.155.6.36894 > 192.168.180.151.22: Flags [.], ack 85, win 331, options [nop,nop,TS val 3667267502 ecr 4040060442], length 0
И когда начинается передача, это первые пакеты:
14:38:13.363765 IP 10.70.155.6.36894 > 192.168.180.151.22: Flags [P.], seq 156:208, ack 85, win 331, options [nop,nop,TS val 3667287485 ecr 4040080446], length 52
14:38:13.384506 IP 192.168.180.151.22 > 10.70.155.6.36894: Flags [P.], seq 85:113, ack 208, win 160, options [nop,nop,TS val 4040080446 ecr 3667287485], length 28
14:38:13.384587 IP 10.70.155.6.36894 > 192.168.180.151.22: Flags [.], ack 113, win 331, options [nop,nop,TS val 3667287506 ecr 4040080446], length 0
14:38:14.437494 IP 10.70.155.6.57580 > 192.168.180.151.22: Flags [.], seq 66559:67733, ack 4885, win 83, options [nop,nop,TS val 3667288559 ecr 4040023913], length 1174
Я вполне уверен, что это проблема фрагментации, но я уже пробовал много вещей, изменяя mtu/mss, но не могу решить.
Моя проблема не связана с моим ПК и scp.
“Настоящая” проблема заключается в том, что у меня много клиентов Windows, которые работают удаленно и должны подключаться к приложениям через VPN.
Я пробовал копирование общей папки и winscp, и у обеих наблюдается это странное поведение.
Копирование с общего диска Windows на Windows11 ПК проходит нормально, но если я пытаюсь скопировать файл с клиента в общую папку, оно зависает, и через некоторое время появляется ошибка.
Любая помощь будет весьма признательна
Большое спасибо
Ответ или решение
Проблема, которую вы описали, связана с сетью, и в ней действительно есть много сложных элементов. Давайте рассмотрим вашу ситуацию по порядку, выделяя ключевые аспекты и возможные причины возникновения задержек в передаче данных между вашим ноутбуком и серверами в SiteB.
### 1. Описание сети и конфигурация
Вы имеете две локации — SiteA и SiteB, соединенные с помощью VXLAN через IPsec, используя два межсетевых экранов OPNSense. Сеть, которую вы используете, имеет диапазон 192.168.180.0/24. Конфигурация MTU (Maximum Transmission Unit) установлена на уровне 1400, что в некоторых случаях может быть недостаточно для работы протоколов, требующих более высоких значений MTU, таких как некоторые приложения, использующие SSH и SCP.
### 2. Производительность соединений и их показатели
Ваша проблема, как вы отметили, проявляется при использовании OpenVPN для подключения к SiteA и при попытке доступа к серверам в SiteB. Например:
– В ping-результатах вы видите низкие значения задержки, что говорит о том, что сеть в целом функционирует.
– С помощью iperf вы получаете медленную скорость при подключении к серверам в SiteB, что наводит на мысль о проблемах с маршрутизацией или перегрузкой на канале.
### 3. Проблемы с фрагментацией и MSS
Ваши подозрения по поводу проблемы с фрагментацией вполне могут быть обоснованными. Когда MTU на пути данных между клиентом и сервером меньше, чем необходимый размер пакетов, пакеты могут фрагментироваться, что может приводить к задержкам, особенно на начальных этапах передачи данных.
Рекомендуется проверить настройки MSS (Maximum Segment Size) на маршрутизаторах и межсетевых экранах (firewalls):
– Убедитесь, что настройки MSS на OPNSense соответствуют вашим требованиям и не занижают размер сегментов. Установка MSS в 1250, как вы указали, может быть недостаточной для некоторых соединений.
### 4. Приведите в порядок настройки MTU и MSS
Разумно начать с выполнения следующих действий:
– Установите MTU на всех сетевых интерфейсах до значения, которое позволит приложениям и протоколам нормально функционировать (возможно, попробуйте значения 1450 или 1500).
– Проверьте, соответствует ли MSS, установленный на OPNSense, максимальному размеру пакетов, передаваемых по VPN.
– Настройте каждый компонент сети, включая Windows-клиентов, чтобы убедиться, что они могут корректно обрабатывать фрагментацию.
### 5. Мониторинг и анализ трафика
С помощью tcpdump вы уже начали исследовать сетевой трафик, что является отличным подходом. Для дальнейшего анализа обратите внимание на:
– Исходящие и входящие TCP-пакеты на различных этапах передачи данных.
– Проверьте, возникали ли TCP-переполнения или повторные передачи, которые могут указывать на потерю пакетов и дальнейшую фрагментацию.
### 6. Выполнение тестов и дальнейшие шаги
После изменений в конфигурации MTU и MSS проведите повторные тесты с iperf и SCP. Убедитесь, что задержки на старте передачи исчезли, и скорость передачи данных стабилизировалась.
### Заключение
Проблема с задержками в передаче данных через VPN, особенно при длительных соединениях, может быть вызвана несколькими факторами, такими как настройки MTU/MSS, фрагментация пакетов и перегрузка сетевого трафика. Проведение тщательного анализа трафика и внесение необходимых изменений помогут вам оптимизировать сеть.
Если после выполнения всех шагов проблема не исчезнет, возможно, потребуется более глубокий анализ конфигурации интерфейсов и маршрутизации на OPNSense, а также изучение возможных ограничений со стороны провайдеров.