Дмитрий Филимонов

Думаю, что где-то косяк с MTU. Хорошо и наглядно проблема описана тут - habrahabr.ru/post/136871 - стоит подебажить в этом направлении.

Единственная причина, которая обосновывает нескольких демонов и которая мне известна: OpenVPN однопоточный, а поэтому в многоядерной системе планировщик будет кидать процесс с ядра на ядро, но все ресурсы таким образом вы не утилизируете. Если запустить несколько OpenVPN процессов, то теоретически вы должны эффективнее использовать процессор. Это актуально в том случае, если у вас большой канал, например гигабитный или выше, и тормозит шифрование/обработка пакетов.

Что касается именно скорости соединения, то больше, чем ваш канал, вы не получите, запустите хоть десяток каких угодно VPN. Провайдер зашейпит ваш трафик, т.е. все пакеты свыше некоторого лимита будут отброшены (простейший случай).

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

Мог бы предложить потюнить OpenVPN, однако, кажется, вы и так это сделали. Прирост скорости также может дать отключение компрессии, фикса mss и т.п.

Если к API нужно ходить с фронтенда, то можно на вашем nginx запроксировать запросы на сторонний ресурс. В ряде случаев понадобится настройка чего-нибудь (nginx/php) на удаленной стороне (если, например, нужно передавать хидеры специализированные, например http-x-real-ip). Ситуация вполне штатная, обычная. Если нужно ходить с бэкенда, то так и напрямую ходите (curl или что там у вас). Ситуация тоже обычная.

Но я так понимаю, что главный вопрос в том, не плохо ли тут использовать vpn? Здесь нужно знать, какой у вас vpn. Самый печальный vpn - это pptp, т.к. небезопасен и будет дольше реконнектиться в случае потери соединения (да и в сравнении, например, с openvpn он даже в конфигурировании неудобен). Уверен, что у вас не pptp, это просто к слову (никто в здравом уме не будет поднимать pptp между сервер-сервер). Грубо говоря, все остальное (openvpn, ipsec и т.п.) можно использовать: проверено временем, стабильно. Касательно оверхеда: в 99% некритично. Например, если это openvpn l3 по udp, то оверхед на каждый пакет по размеру будет ~70 байт (где-то 20 ip, 8 udp, порядка 40-50 на tls)... примерно. И хотя если посчитать этот размер относительно маленьких пакетов, может выйти больше самого пакета (смотря как считать еще), это ни о чем не говорит: при достаточном канале (а у вас, раз речь идет про сервера, должно быть все хорошо) это некритично. В плане времени сколько-то уйдет на шифрование, но опять же для api это некритично (и надо учитывать, что соединение-то постоянное, то есть временной оверхед, например, на tcp/http и тем более https выше, а оно повсеместно, никто не парится). Для собственного успокоения можете замерить ширину канала (nc), потыкать в api (hping).

Кстати, если везде линуха, не нужна защита, нет по пути страшных фаерволов, видимость на уровне l3 есть, то лучший вариант, как по мне, - это линуксовый ipip, либо gre: минимальный оверхед, крайне легко настраивается (описано в lartc), не нужно дополнительное ПО. Не знаю, насколько это популярно, но я бы использовал такой "vpn", если возможно/нужно.

Еще важно убедиться, что vpn поднимается при ребуте сервера, что работает реконнект в случае чего. Собственно, это относится ко всем сервисам вообще.

В качестве вывода: никаких проблем, используйте.

Если есть тоннель, то это значит, либо L2, либо L3 канал уже есть, в обоих случаях имеется IP-адрес с двух сторон. Поэтому вы уже ходите в обе стороны. Дальнейшая настройка зависит от того, что хотите делать. В типичном случае: настроить фаерволл, чтобы он разрешал доступ до нужного ПО/порта, поднять это самое ПО. Поэтому не просто можно, а из коробки можно.