Как повысить надежность OpenVPN по каналу с высокой задержкой?

11

Мы запускаем OpenVPN VPN по спутниковой линии BGAN, где время пинга составляет около 3 секунд. Мы используем его в конфигурации tun и работаем в Linux (CentOS). Это прежде всего электронная почта, которая будет отправлена по ссылке, но как только почта содержит большие вложения, VPN, кажется, останавливается.

«Я могу свистеть через туннель, но любая реальная работа заставляет его запереть. Является ли это проблемой MTU?» Вопрос в FAQ OpenVPN, кажется, описывает мою проблему точно, но использование mssfixи fragmentвсе еще, кажется, не делает много, чтобы улучшить ситуацию.

Мой основной тест - скопировать файл размером 2 МБ по VPN с помощью scp . Он скопирует около 192 Кбайт, а затем сообщит о остановленном состоянии. Если я подожду пару секунд, он снова начнет копироваться, а затем снова остановится через пару килобайт.

Это зависание происходит независимо от того, установил я fragmentили нет mssfixпараметры или в моей конфигурации OpenVPN (хотя настройка fragment 1000, казалось, уменьшала задержку, но не устраняла ее). OpenVPN mtu-testсообщил 1542 как размер MTU.

Я искал в Интернете для получения дополнительной консультации о том , как и когда использовать mssfixи fragment, но я только найти страницы говорят то же самое , как часто задаваемые вопросы, и не вдаваясь в подробности о том , как и когда использовать , какие параметры.

Мои вопросы тогда:

Когда я использую 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 Кбит / с для ряда итераций (I думаю, что 1,2 Мбит / с может быть из-за некоторой буферизации OpenVPN или так далее)

Является ли iperf лучшим способом измерения пропускной способности?

Любая помощь в этой ситуации будет принята с благодарностью.

openvpn

— iWerner
источник

В данный момент openvpn использует TCP или UDP?

— pjc50

В настоящее время он использует UDP

— iWerner

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

— iWerner

5

1542 как MTU? Никогда не слышал об этом для глобальной сети. Обычно MTU - это максимальная полезная нагрузка, размер пакета ip минус заголовок для IP (20 байтов) и ICMP (8 байтов). Это означает, что MTU = 1500 для традиционной локальной сети Ethernet. Кроме того, большинство VPN вводят издержки на инкапсуляцию пакетов. Типичный VPN MTU - 1400.

В современных сетях трудно определить, каким будет MTU в любой момент, поскольку входные и выходные пути могут различаться, и они также могут изменяться из-за автоматической перенаправления пути. Для такой сети может быть более эффективным установить низкий уровень MTU на ваших хостах, которые находятся по обе стороны от канала VPN, например 576.

MSS (максимальный размер сегмента) - это MTU минус заголовки IP + TCP (40 байт). Обычно это согласовывается сетевым стеком и обычно не имеет тех же проблем согласования, что и MTU, если только MTU не является неправильным. (Согласование MTU обычно нарушается заблокированными ICMP или маршрутизаторами черной дыры).

Первое, что я хотел бы сделать, это сделать захват сетевых пакетов на отправляющей стороне и отсортировать отображение по размеру кадра (вам может понадобиться добавить этот столбец в Wireshark). Вы должны убедиться, что вы не отправляете какие-либо кадры, размер которых превышает допустимый размер. Современные сетевые карты часто отправляют кадры большего размера, если включены такие опции, как Large Send Offload или Jumbo Frames. Я видел более 30000 байт, когда эти опции включены.

— Грег Аскью
источник

+1 для захвата пакета, прежде чем что-либо менять. даже если вы не найдете никакого огромного кадра, вы можете увидеть где-то фрагментированные «нормальные» пакеты.

— Хавьер

1

По умолчанию OpenVPN устанавливает MTU устройства tun равным 1500 (что совпадает с MTU на устройствах Ethernet на наших машинах). Я все еще не уверен, является ли фрагментация пакетов VPN хорошей или плохой вещью. Ответы в этой теме, кажется, подразумевают, что это плохо, в то время как другие ссылки, которые я нашел в Интернете, подразумевают, что это хорошо.

— iWerner

2

@iwerner: вы пытались определить размер mtu с помощью ping? Если ICMP не отключен в некоторых местах, вы можете использовать следующее в Windows: ping -f -l 1372 <IP-адрес назначения>. Продолжайте уменьшать число, пока это не удастся. В Linux ping -s 1372 -M делает <IP-адрес назначения>. К сведению, в FAQ по OpenVPN рекомендуется использовать mssfix 1200, но это не устраняет основную причину. Использование VPN-решений для фрагментации всегда может привести к снижению производительности. Если у вас большая настройка VPN, вы не сможете использовать фрагментацию на центральном конце концентратора, только на удаленном офисном конце.

— Грег Аскью

2

Просто из любопытства, вы пытались снизить MTU сетевого интерфейса? Возможно, спутниковая связь плохо испортит фрагментацию. В качестве нелогичного замечания вы можете попробовать openvpn через TCP для изменения. Я знаю, что это должно снизить производительность, но если у вас нет контроля над фрагментацией, это может вам помочь.

— lorenzog
источник

Я собирался предложить обратное :) - в этом случае с высокой задержкой возникают проблемы с TCP-in-TCP, и UDP этого не допустит.

— pjc50

Я предполагал, что он использует UDP-порт по умолчанию для openvpn, и поэтому предложил обратное .. да, обычно я согласен с вами. Но, эй, мы все знаем, что sysadmin - это метод проб и ошибок, и обычно «

— пробуй делать то, что нужно,

Благодарю. В настоящее время мы используем UDP, и попытка TCP мне никогда не приходила в голову. (Если бы у меня было больше представителей, я бы проголосовал за вас)

— iWerner

@iWerner: спасибо :) также попробуйте постепенно уменьшить MTU на iface и посмотрите, когда он остановится (если это произойдет).

— Лоренцог

2

Когда вы используете TCP, увеличьте размер окна TCP; это поможет с «количеством пакетов в эфире».

Прошло много времени с тех пор, как мне пришлось поиграть с этим, но вот одна ссылка, которую Google нашел для меня.

После того, как я перечитал ваш вопрос, я вижу, что вы используете BGAN - я бы хорошо посмотрел на это (или просто Google: "BGAN spoofing").

Что касается измерения пропускной способности, я обнаружил, что iperf довольно приличный, если вы используете разумные размеры пакетов.

— Эдди
источник

Это интересно - в нем упоминается, что ускоритель TCP доступен для Redhat, в то время как сотрудники Inmarsat, с которыми мы говорили, сказали, что он был доступен только для Windows и OS X (и это действительно то, что говорит веб-сайт Inmarsat / BGAN)

— iWerner

Они могут не иметь этого сейчас; Я вижу, что дата документа - 07. Если вы достаточно настойчивы и говорите с достаточным количеством людей; Вы можете найти кого-то со старой копией. Обычно, когда вы звоните по телефону, вы получаете поддержку первого уровня. Я попробую некоторые из моих контактов, но без гарантий.

— Эдди

Я побежал от нашего спутникового провайдера; Трудно найти кого-то, кто знает, о чем они говорят. Я буду продолжать пытаться, тем временем вот что можно попробовать: sourceforge.net/projects/pepsal Из описания проекта он делает в значительной степени то, что делает программное обеспечение Inmarsat: PEPsal представляет собой интегрированный, многослойный, прозрачный TCP Прокси-сервер повышения производительности, который разделяет соединение на две части, используя улучшения TCP для Linux при отправке данных и значительно улучшая производительность в каналах с различными характеристиками

— Eddy

2

Я думаю, ты можешь лаять не на то дерево. Каждый раз, когда у меня возникали проблемы с MTU, трафик прекращался раньше, чем 192 КБ. Я думаю, что это больше относится к некоторым окнам «в пакетах», либо к окну TCP, либо к некоторым буферам в самой спутниковой восходящей линии связи.

Определенно сделать некоторые длинный Packet захватов (как «внутри» и «снаружи» в VPN) и посмотреть , если вы получаете все ACK«S

— Хавьер
источник