Мы запускаем OpenVPN VPN через спутниковую связь BGAN, где время отклика составляет около 3 секунд. Мы используем его в тун конфигурации, и мы работаем в Linux (CentOS). В основном это электронная почта, которая будет отправлена по ссылке, но как только письмо будет содержать большие вложения, VPN, похоже, остановится.
В «Я могу пропинговать туннель, но любая реальная работа вызывает его блокировку. Это проблема MTU?» вопрос в FAQ OpenVPN, кажется, точно описывает мою проблему, но используя mssfix и fragment по-прежнему, похоже, мало что может сделать для улучшения ситуации.
Мой основной тест - скопировать файл размером 2 МБ через VPN с scp. Он скопирует около 192 Кбайт, а затем сообщит о - остановился - штат. Если я подожду пару секунд, он снова начнет копирование, а затем снова остановится через пару килобайт.
Это происходит независимо от того, установил я или нет fragment или mssfix параметры в моей конфигурации OpenVPN (хотя настройка fragment 1000 вроде бы уменьшил срыв, но не устранил). OpenVPN mtu-test сообщил 1542 как размер MTU.
Я искал в Интернете дополнительные советы о том, как и когда использовать mssfix и fragment, но я нахожу только страницы, на которых написано то же, что и в FAQ, и не даю подробностей о том, как и когда использовать какие параметры.
Тогда мои вопросы:
mssfix и fragment?mssfix и fragment в сочетании?mssfix и fragment это решение, каковы tun-mtu, link-mtu и mtu-disc параметры для?Кроме того, я использовал инструмент iperf для измерения пропускной способности. Без VPN он постоянно измеряет порядка 210 Кбит / с.
Когда используешь iperf через VPN ($ iperf -c remoteserver -t60 -i5), он начнется со скорости 10 Кбит / с, затем будет постепенно увеличиваться до тех пор, пока не будет сообщать 1,2 Мбит / с, а затем будет казаться, что он остановился, где он сообщает 0 кбит / с для нескольких итераций (я думаю, быть из-за некоторой буферизации OpenVPN или так далее)
Является iperf лучший способ измерить пропускную способность?
Мы будем благодарны за любую помощь в этой ситуации.
1542 как MTU? Никогда не слышал об этом для канала WAN. Обычно MTU - это максимальная полезная нагрузка, размер пакета IP за вычетом заголовка для IP (20 байтов) и ICMP (8 байтов). Это означает, что MTU = 1500 для традиционной локальной сети Ethernet. Более того, большинство VPN вносят накладные расходы на инкапсуляцию пакетов. Типичное значение MTU VPN составляет 1400.
В современных сетях трудно сделать вывод о том, каким будет MTU в любой момент, поскольку входящие и исходящие пути могут быть разными, а также могут измениться из-за автоматического перенаправления пути. Для такой сети может быть более эффективным установить низкий MTU на хостах, которые находятся по обе стороны от канала VPN, например 576.
MSS (максимальный размер сегмента) равен MTU за вычетом заголовков IP + TCP (40 байтов). Обычно это согласовывается сетевым стеком и обычно не имеет тех же проблем согласования, что и MTU, если MTU не является неправильным. (Согласование MTU обычно нарушается заблокированными маршрутизаторами ICMP или черными дырами).
Первое, что я бы сделал, - это захват сетевых пакетов на отправляющей стороне и сортировка отображения по размеру кадра (вам может потребоваться добавить этот столбец в Wireshark). Вы должны убедиться, что вы не отправляете фреймы слишком большого размера, чем вы ожидаете. Для современных сетевых карт нет ничего необычного в отправке кадров большого размера, если включены такие параметры, как Large Send Offload или Jumbo Frames. Я видел 30 000+ байтовых кадров, когда эти параметры включены.
Просто из любопытства вы пробовали снизить MTU сетевого интерфейса? Возможно, спутниковая связь сильно портит фрагментацию. В качестве противоречащего интуиции примечания, вы можете попробовать openvpn через TCP для разнообразия. Я знаю, что это должно снизить производительность, но если у вас нет контроля над фрагментацией по линии, это может вам помочь.
Когда вы используете TCP, увеличивайте размер окна TCP; это поможет с «количеством пакетов в воздухе».
Давненько мне не приходилось играть с этим материалом, но вот один ссылка на сайт Google нашел для меня.
После того, как я перечитал ваш вопрос, я увидел, что вы используете BGAN - я бы внимательно посмотрел на этот (или просто введите в Google запрос: "Спуфинг BGAN").
Что касается измерения пропускной способности, я обнаружил, что iperf довольно неплох, если вы используете разумные размеры пакетов.
Я думаю, ты лаешь не на то дерево. Каждый раз, когда у меня возникали неправильные проблемы с MTU, трафик останавливался раньше, чем 192 КБ. Я думаю, что это больше связано с каким-то окном "в полетных пакетах", либо с окном TCP, либо с некоторыми буферами в самом спутниковом восходящем канале.
Обязательно сделайте несколько длинных захватов пакетов (как «внутри», так и «за пределами» VPN) и посмотрите, получаете ли вы все ACKс