Openvpn низкая скорость копирования файлов
Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC'и. Абсурд!
Немного истории
На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек. Однако в Windows что-то поломали, и указание размера буферов у сокета приводит к странным проблемам с MTU на всех адаптерах в системе. В конечном итоге, в релиз OpenVPN 2.0-beta8 попадает следующий код:
Немного технической информации
Если вы пользовались OpenVPN, вы знаете, что он может работать как через UDP, так и через TCP. Если на TCP-сокете установить какое-то маленькое значение буфера, в нашем случае 64 КБ, то алгоритм подстройки TCP-окна просто не сможет выйти за это значение.
Что же это значит? Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с. Вам необходим буфер размером как минимум 640 КБ, чтобы загрузить ваш 50 Мбитный канал.
OpenVPN через UDP будет работать несколько быстрее из-за собственной реализации пересылки пакетов, но тоже далеко не идеально.
Что делать?
В этом случае, размер буфера будет задаваться настройками ОС. Для Linux и TCP это значение будет меняться согласно значениям из net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, а для UDP — фиксированное значение net.core.rmem_default и net.core.wmem_default, деленное на два.
Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
Настройка брандмауэра и маршрутизации
Основной задачей нашего сервера является обеспечение выхода в интернет и будет разумно обеспечить минимальный набор правил безопасности, во многом они будут повторять те правила, которые мы использовали для наших роутеров на базе Linux.
Создадим файл правил:
и внесем в него следующие строки, обратите внимание на имя сетевого интерфейса вашего VPS, в нашем случае это ens3:
Не забудем сделать файл исполняемым:
Данный файл требуется запускать после создания туннельного интерфейса tun0, поэтому откроем конфигурационный файл сервера OpenVPN /etc/openvpn/server.conf и в его конце добавим опцию:
Перезагрузим сервер и убедимся, что OpenVPN сервер автоматически запустился и создал туннельный интерфейс, это можно сделать командой:
Также проверим применение правил брандмауэра:
Укажите: Тип источника - CIDR, Исходный CIDR - 0.0.0.0/0, IP-протокол - UDP, Диапазон исходных портов - Все, Диапазон конечных портов - 1194.
Немного истории
На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек. Однако в Windows что-то поломали, и указание размера буферов у сокета приводит к странным проблемам с MTU на всех адаптерах в системе. В конечном итоге, в релиз OpenVPN 2.0-beta8 попадает следующий код:
Но у меня Windows!
Если у вас и OpenVPN-сервер работает на Windows-машине, и все клиенты подключаются только из-под Windows, то поздравляю — вам ничего менять не нужно, у вас и так все должно работать быстро.
В наших прошлых материалах мы рассматривали применение OpenVPN исключительно для организации каналов связи между подразделениями организации. Но современный мир приносит новые вызовы, на которые следует реагировать. Один из них - общественные сети с низкой безопасностью, для работы в которых желательно иметь защищенный канал, препятствующий доступу третьих лиц к вашему трафику. Традиционно эта задача решается использованием VPN-сервисов и в данной статье мы расскажем, как организовать собственный сервис на базе OpenVPN.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Кроме общественных сетей в последние годы стала приобретать повышенную актуальность проблема ограничения доступа к некоторым ресурсам исходя из географического расположения клиента. Это могут быть как ограничения регионального характера, например, популярный поставщик видеоконтента Netflix, так и блокировки со стороны органов власти, как яркий пример которых "ковровые блокировки" РКН в его борьбе с Телеграм, когда под ограничения попало большое количество совершенно легальных ресурсов.
Исходя из вышесказанного можно сделать вывод, что наличие VPN-сервиса для доступа в интернет в современных условиях - это не роскошь, а насущная необходимость, особенно если ваша деятельность завязана на работу в сети. Да, существуют многочисленные VPN-провайдеры, но их услуги являются платными и снова встает вопрос доверия, особенно если вы используете канал для обмена конфиденциальной или финансовой информацией.
Что нужно для создания собственного VPN-сервиса? Прежде всего потребуется VPS (виртуальный выделенный сервер) расположенный в регионе, из которого возможен неограниченный доступ к требуемым ресурсам. В большинстве случаев можно выбирать Европу или Штаты, но во втором случае задержки будут выше. На наш взгляд, выбирать Штаты имеет смысл, если вам требуется доступ к американским ресурсам, тому же Netflix или покупкам у американских продавцов на Amazon и Ebay.
Для поиска недорогих VPS можно воспользоваться специальными сайтами, такими как Low End Box или бесплатными предложениями от облачных провайдеров. Так у Amazon и Microsoft можно бесплатно получить виртуальную машину на год, а Oracle предлагает две VPS бесплатно и навсегда.
В нашем примере мы будем использовать бесплатный VPS от Oracle с Ubuntu 18.04, но данная инструкция подойдет для любых deb-based систем и с некоторыми поправками для любого другого Linux-дистрибутива.
Почему тормозит OpenVPN? Размер буферов приема и отправки
Производительность OpenVPN является для многих администраторов больной темой. Очень часто скорость внутри туннеля в разы отличается от скорости канала в меньшую сторону. К сожалению многие сетевые ресурсы дают по этому поводу неверные или вообще вредные советы, либо заявляют, что это "нормально", мол шифрование, работа в userspace, накладные расходы и т.д., и т.п. Мало кто пытается разобраться в реальных механизмах, влияющих на производительность OpenVPN, другая же часть просто дает готовые рекомендации, не поясняя откуда они получены и почему надо делать именно так.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Для примера возьмем один реальный случай. К нам обратился один знакомый системный администратор и пожаловался на низкую скорость через OpenVPN в двух новых торговых точках организации, в то время как в остальных местах проблем с производительностью канала не было.
Стали разбираться вместе и обнаружили, что при реальной скорости канала около 15 Мбит/с OpenVPN не разгоняется свыше 3-4 Мбит/с, да и это, по словам нашего коллеги, еще "хорошая" скорость.
Перед тем, как обратиться за помощью наш знакомый перепробовал массу рекомендаций из сети, но ни одна из них не принесла успеха. При этом выяснилось, что доступ к двум новым точкам осуществляется по радиоканалу и пинг, в зависимости от погодных условий, находится в пределах 100-200 мс, в то время как к остальным филиалам он гораздо ниже, около 50 мс.
А теперь самое время вспомнить о таком параметре, как размер буферов приема и отправки. Если не вдаваться в подробности работы сетевых протоколов, то размер буфера определяет максимальный объем данных, которые могут быть переданы за единицу времени. Наиболее чувствительный к размеру буфера протокол TCP, так как размер окна TCP, т.е. количества одновременно отправляемых пакетов не может превышать размер буфера. Протокол UDP работает иначе, но и его производительность также ограничена размерами буферов.
Проведем простую аналогию. Нам нужно перевезти некий груз из пункта A в пункты Б и В, в пункт Б ведет хорошая автомагистраль со средней скоростью 90 км/ч, а в пункт B грунтовка, разогнаться на которой можно до 45 км/ч. Понятно, что, используя один и тот-же транспорт за одно и тоже время в пункт Б удастся доставить в два раза больше груза, чем в пункт В.
В сетях все происходит аналогично. Исторически сложилось так, что размер буфера OpenVPN составляет 64 КБ, в Linux системах это значение устанавливается принудительно, в Windows вроде бы как отдается на откуп ОС, но по факту чаще всего мы имеем все те же 64 КБ. В этом несложно убедиться заглянув в лог:
При пинге в 200 мс все гораздо более печально, мы упремся в потолок 320 КБ/с или 2,5 Мбит/с. Таким образом, путем несложных математических вычислений мы ответили на главный вопрос: "Почему тормозит OpenVPN". Как видим, ни шифрование, ни "накладные расходы" тут не причем, проблема в физических ограничениях канала.
Что же делать? Ответ прост - увеличивать размер буферов. Сделать это просто, откройте конфигурационный файл сервера и добавьте туда строки:
Это установит объем буферов в размере 512 КБ и позволит достичь скоростей при 50 мс - 80 Мбит/с, а при 200 мс - 20 Мбит/с.
В большинстве руководств советуют добавить такие же строки и в конфигурационный файл клиента, но как выяснилось на практике, со стороны клиента данные опции не работают, поэтому следует передать размеры буферов со стороны сервера, поэтому в конфигурацию сервера добавим еще две строки:
Чтобы убедиться, что настройки работают заглянем в лог на клиенте, там мы должны обнаружить примерно следующее:
Также в ряде источников выражается мнение, что данная проблема (размеров буфера) актуальна только для Linux систем, а в Windows все должно работать быстро, однако уже у другого клиента мы обнаружили что в одном из филиалов, при проводном подключении, Windows Server 2008 R2 устанавливал размеры буферов в 8 КБ:
А это даже при хорошем пинге в 50 мс не более 1,25 МБит/с, при скорости канала в десятки раз превышающем это значение.
В нашем же случае увеличение буфера до 512 КБ позволило достичь скоростей 11-12 Мбит/с, что вполне соответствует реальной скорости канала.
Поэтому мы советуем не полагаться на значения по умолчанию, а взять управление в свои руки, и реально оценив условия доступа рассчитать и установить необходимые значения буферов приема и отправки, что позволит полностью утилизировать канал и более не задаваться вопросом: "Почему OpenVPN тормозит?".
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Собственно суть в вопроса в заголовке. Скорость падает примерно в половину.
Кстати, когда устанавливал OpenVPN Access server на эту же машинку, потерь в скорости не было.
Машинка мощная, тянуть VPN должна легко. Подскажите куда копать? Пробовал играться с mtu, tun/tap, udp/tcp, lzo - помогает не существенно.
Оценить 2 комментария
Во что упирается - в проц или в сеть?
И, кстати, по-любому лучше proto udp (кроме каких-то сильно крайних случаев).
Скачивание через wget 1Гбайтного файла 76.9MB/s in 1.6s.
По udp скорость ещё ниже чем через tcp.
Александр Александрович Вы много трафика намотали? Все может упираться в урезание полосы и скорости хостером, да и производительность дисковой подсистемы обычно также является узким местом VPS в ситуациях с передачей больших объемов данных.
Похожий вопрос был на тостере, помогло это:
Примерно одинакового результата я достиг двумя путями:
1. Создать заново все ключи и сертификаты виндовым easy-rsa (в процессе возникает много глюков, которые надо побороть). До этого я создавал ключи линуксовым easy-rsa (a «openvpn не уважает виндоувс» :) ).
2. Прокинуть тоннель между гейтом и хостовой машиной, а оттуда через мост на гостевую. Раньше у меня это не получалось, а всего-то надо было мосту дать ip вручную.
После чего шустренько заработал RDP и SFTP из Винды через VPN, но остались тормоза у SMB. Впрочем, это наверное уже другая тема, связанная с MTU.
Еще по настройке OpenVPN советую почитать на хабре: Руководство по установке и настройке OpenVPN
Посмотри сначала такие варианты:
1. Ограничения провайдера или большая загруженность общего канала.
2. Процессор сервера слабоват на данный уровень шифрования.
Спасибо я не знал) учту
Утилита от спиидтест на сервере
вот скорость сервера (скачка/закачка на прямую) Testing download speed. Download: 100.95 Mbit/s Testing upload speed. Upload: 337.95 Mbit/s
а провайдер без VPN дает на компе 12мб/сек с VPN 2,5 мб/сек
Пинг до сервера Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 46мсек, Максимальное = 63 мсек, Среднее = 56 мсек
включение/выключение шифрования ничего не меняет у меня
Уменьшил MTU до 1400, не помогло есть ли смысл еще уменьшать? и на сколько
1)не думаю 2)Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 2400.084 Mhz. убирал шифрование вобще, разницы не было
1. Почему у сервера два раза keepalive, причем разные ?
2. sndbuf, rcvbuf - почему такие маленькие?
3. fragment - из каких соображений?
4. Что такое fast-io не знаю. Посмотрел в мане, вроде все еще экспериментальная, насколько реально помогает незнаю.
Если есть сомнения в mtu и точки соединения постоянные, можно посмотреть выхлоп tracepath (в обе стороны). Еще есть параметр mtu-test, только надо подождать после старта несколько минут.
Для начала, я бы убрал fragment, sndbuf, rcvbuf ну и fast-io так уж на всякий случай.
Еще попробуйте заменить udp на tcp.
Это нормальная скорость для OpenVPN. Только пишите скорость правильно, а то у вас мегабиты с мегабайтами путаются. 2.5МБайт/с для usermode VPN, да ещё через tun/tap - это отличный результат по-моему. Или ищите kernel-mode реализацию (а её нет) или меняйте VPN протокол, да хоть L2TP/PPTP.
Это нормальная скорость для OpenVPN.
Это НЕ нормальная скорость. Разве что камень нагружен.
Полгода назад напоролся на подобную ситуацию. Тариф 30Mbps, всё честно - iperf, speedtest выдаёт по тарифу. Оформлен на физлицо. По OpenVPN стабильно 600kbps. Пробовал крутить конфиги клиента сервера (tcp/udp, порты, шифрование/paintext, буферы) - не помогает. Железяка слабенькая(OpenWRT), попробовал на ноуте с тем же конфигом - 600kbps. Попробовал заломиться на другой VPN (другой провайдер) сервер с заведомо рабочим конфигом - 600kbps. Через какое-то время прошёл слух, что провайдер тестирует DPI. OpenVPN палится, код протокола передаётся в открытую.
Вполне допускаю, что на стороне сервера трудится VPS с коэффициентом мультиплексирования «с потолка», потому проц выше и не выдает.
Это не обязательно DPI, вполне реально ограничение скорости на один поток каким-нибудь хитровжаренным коммутатором. Есть такое наблюдение, когда используются разные комбинации src_ip+src+port+dst_ip+dst_port (многопоточный режим с разными соединениями на разных портах сокетов), то скорость выдаёт максимальную. Автор может попробовать multitcp прикрутить, вдруг поможет. Но там, правда, он ориентирован на распределение нагрузки через разные физические/виртуальные порты и айпишники.
nickleiten ★★★ ( 10.02.16 06:37:43 )
Последнее исправление: nickleiten 10.02.16 06:38:22 (всего исправлений: 1)
вполне реально ограничение скорости на один поток каким-нибудь хитровжаренным коммутатором
Как коммутатор может отличить поток OpenVPN от потока iperf? Истинный коммутатор вообще не лезет дальше Ethernet. Конкретно в описанном мной случае был неуправляемый гигабит (с моей стороны).
П.с. Ваше предположение прекрасно дополняет тот факт, что незадолго до всплытия проблемы был заменён коммутатор(старый пал смертью храбрых в грозу). Я всякие чудеса повидал, но меня терзают смутные сомнения.
погуглил в нете пишут что Yota может резать VPN трафик видимо нужно менять провайдера
Попробуй 443 порт + tcp
уходи на SoftEtherVPN и будет тебе счастие.
это к фразе о нормальной скорости для OpenVPN.
а по теме утилитами от speedtest-a я бы не тестил, iperf в руки и гонять трафик tcp, udp и искать узкое место, в практике правда не на OpenVPN site-to-site в многопоточном режиме выдает 1GB/s
В том-то и проблема, что есть два подхода DPI - статистический и конкретно deep-inspection с проверкой меток протоколов. Сейчас любой управляемый L2+/L3 чип коммутатора умеет проверять поля src/dst ip и src/dst port в любых комбинациях и на основе этих полей выстраивать ACL shaper. Это статистический метод, то есть необязательно даже лезть в глубины пакета, а подходить к обработке на уровне соединений (характеристика любого IP-соединения, будь то TCP/UDP или даже просто голый IP с вашим собственным протоколом, включает эти четыре поля, для точного определения, что это одно и то же соединение, плюс учёт времени, и мы получаем банальный stateless tracking).
То есть в нашем случае коммутатор можно настроить так, что каждая уникальная комбинация айпишников и портов есть одно соединение и это одно соединение ограничивать по скорости. Соответственно, когда запускаешь несколько потоков у которых хоть один параметр отличается(src/dst ip и/или src/dst port), коммутатор его воспринимает как другое соединение и даёт ему соответственно отдельную скорость. В сумме мы получаем при многопоточной загрузке выше скорость, но один поток упирается в скорость на коммутаторе. Это уже всё зависит от провайдера и их политик.
Ага, в котором рассмотрен bare-server с нагрузкой на CPU до 100%. Поэтому я и говорил, что 2.5МБайт/с - это очень хорошо для OpenVPN. IOPS и context swithing никто не отменял.
И еще раз повторюсь это НЕ нормальная скорость. И не надо вводить людей в заблуждение. Вот прямо сейчас попробовал с двух разных серверов скачать файлик 4Гб через scp, в кач-ве клиента ноут i5 2,53.
1. Без впн 10.1MB/s с впн 9.7MB/s
2. Без впн 2.4MB/s с впн 2.1MB/s
Я уже выразил своё сомнение насчёт bare server у ТС и высказался насчёт возможных ограничений скорости на одно соединение у провайдера с той или иной стороны. Моя практика показывает, что в стандартной конфигурации 2.5Мбайт для OpenVPN на VPS - очень неплохой результат. Где и в чём проблема - не моя задача разбираться, весь спектр проблемных мест я указал. Я нигде не исключал возможности разогнать OpenVPN до 100мбит, а то и до гигабита, но для этого нужно конкретно заниматься разбором конфигурации сети/серверов и вылизывать/обходить косяки - это тоже не моя задача в пределах этого форума.
1. Слова VPS в ваших постах о скорости не обнаружено.
2. Зато обнаружено однозначное заявление что для OpenVPN 2.5Мб прямо-таки замечательно, что наглое 4.2.
PS И скорости которые я привел - это в конфигурации без всякого «заниматься разбором конфигурации сети/серверов и вылизывать/обходить косяки»
1. Слова VPS в ваших постах о скорости не обнаружено.
2. Зато обнаружено однозначное заявление что для OpenVPN 2.5Мб прямо-таки замечательно, что наглое 4.2.
Это нормальная скорость для OpenVPN. Только пишите скорость правильно, а то у вас мегабиты с мегабайтами путаются. 2.5МБайт/с для usermode VPN, да ещё через tun/tap - это отличный результат по-моему. Или ищите kernel-mode реализацию (а её нет) или меняйте VPN протокол, да хоть L2TP/PPTP.
Настройка клиентов OpenVPN
Настройка клиента начинается на сервере с получения ключей и сертификатов клиента, для этого перейдем в директорию центра сертификации и загрузим переменные:
Затем создадим ключевую пару клиента командой:
где client -имя клиента, мы также рекомендуем давать им осмысленные имена.
Теперь скопируем файлы, которые необходимо передать на компьютер клиента в домашнюю директорию и изменим их владельца (по умолчанию владелец - root), чтобы вы смогли их скопировать с помощью любого FTP или SFTP клиента. В нашем случае имя пользователя ubuntu:
Помните, что закрытый ключ клиента client.key является секретным и следует избегать его передачи по открытым каналам связи.
Также не будет лишним сразу скопировать шаблон клиентской конфигурации:
После чего скопируйте все эти файлы на клиент и установите на нем OpenVPN, в Windows системах советуем изменить путь установки OpenVPN на более короткий и без пробелов, скажем, C:\OpenVPN.
Затем откроем файл client.ovpn, который в Windows системах должен быть расположен в C:\OpenVPN\config, а в Linux в /etc/openvpn, и внесем в него следующие изменения:
Данные опции задают клиентский режим работы, тип туннеля и используемый протокол UDP.
Затем укажем адрес сервера:
Следующая опция предписывает клиенту постоянно разрешать имя OpenVPN-сервера, имеет смысл если мы указываем сервер по FQDN-имени, а не IP-адресу.
Для Linux систем обязательно укажите:
В Windows данные опции следует обязательно закомментировать.
Проконтролируем наличие следующих опций:
Укажем пути к ключам и сертификатам, для Linux систем подразумеваем их нахождение в /etc/openvpn/keys:
Для Windows систем предположим их нахождение в C:\OpenVPN\keys:
Также обязательно закомментируем опцию:
Включим защиту от атак типа "человек посередине":
И укажем используемый шифр, он должен совпадать с указанным на сервере:
Остальные опции можно оставить без изменений. Сохраним файл и запустим OpenVPN-клиент.
Обращаем внимание на национальную принадлежность адреса, в данном случае мы выходим в интернет из Штатов.
Самое время провести замер скорости доступа, мы будем использовать для этого популярный сервис SpeedTest. Первый замер без VPN:
Второй через OpenVPN-канал:
Сразу обращаем внимание на выросший пинг - это последствия размещения сервера в Штатах, а также скорость скачивания не выше 10 Мбит/с - ограничение бесплатного тарифа Oracle, хотя в большинстве случаев этого вполне достаточно для комфортного серфинга.
Напоследок затронем еще один момент. Мы настроили сервер таким образом, что он автоматически конфигурирует клиента на доступ в интернет через OpenVPN-подключение, но бывают случаи, когда это не нужно. Допустим вы хотите пустить через VPN только некоторые ресурсы, а остальной доступ должен осуществляться через локального провайдера. В таком случае добавьте в конфигурационный файл клиента опцию:
После чего клиент будет игнорировать передаваемые с сервера опции маршрутизации и DHCP-опции, такие как DNS-сервера и т.п.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Настройка сервера OpenVPN
Прежде всего установим OpenVPN и Easy-RSA для управления ключами:
Скопируем файлы easy-rsa в конфигурационную директорию OpenVPN и создадим символическую ссылку на файл настроек OpenSSL:
Затем откроем файл /etc/openvpn/easy-rsa/vars и изменим в нем следующие строки, указав собственные данные для сертификатов, например, так:
Сохраним файл и перейдем к созданию собственного центра сертификации (CA). Для этого перейдем в директорию нашего CA и загрузим переменные:
Очистим любые имеющиеся данные и инициализируем центр сертификации:
В процессе создания ключей вам будут задаваться вопросы, ответы по умолчанию на которые берутся из файла vars и помещены в квадратных скобках, поэтому можно просто подтверждать их нажатием Enter.
После чего в директории /etc/openvpn/easy-rsa/keys появится сертификат CA, содержащий публичный ключ, ca.crt, который должен присутствовать на каждом VPN-клиенте, и закрытый ключ центра сертификации ca.key, этот файл является секретным и не должен покидать пределы сервера.
Затем создадим файл параметров Диффи-Хеллмана, который нужен для формирования уникального сеансового ключа и обеспечения режима совершенной прямой секретности:
Данная операция, в зависимости от производительности вашего VPS, может занять достаточно много времени.
И, наконец, создадим ключевую пару для сервера:
где server - имя вашего сервера, мы рекомендуем давать осмысленные названия, чтобы потом не пришлось гадать, что именно это за ключевая пара и для чего она нужна.
На этом формирование необходимых ключей и сертификатов закончено, перейдем к настройке OpenVPN, прежде всего создадим директорию для хранения ключей. Можно, конечно, использовать ключи прямо из директории easy-rsa, но лучше отделить CA от остальных служб.
Теперь скопируем туда необходимые серверу ключи и сертификаты:
Распакуем и скопируем в директорию /etc/openvpn шаблон серверной конфигурации:
Откроем файл /etc/openvpn/server.conf и внесем в него необходимые изменения, в большинстве случаев вам придется раскомментировать нужны строки или убедиться в их наличии. Опции указаны в порядке их следования в файле:
Данные опции указывают порт, протокол и тип туннеля, менять их не следует, однако в ряде случаев может потребоваться использовать протокол tcp, но в силу более высоких накладных расходов этой ситуации желательно избегать.
Затем зададим топологию сети:
Укажем пути к ключам и сертификатам, допускаются относительные пути, в этом случае корнем будет считаться директория /etc/openvpn:
Зададим диапазон OpenVPN-сети:
И укажем файл для хранения адресов клиентов, которые будут автоматически выдаваться сервером:
Автоматически сконфигурируем клиентов на доступ в интернет через OpenVPN-подключение:
И передадим им собственные DNS-сервера:
Укажем параметры проверки активности:
Сервер будет проверять клиента каждые 10 секунд и при отсутствии ответа через 120 секунд клиент будет считаться неактивным.
Обязательно закомментируйте строку:
Для сценария доступа в интернет дополнительная TLS-аутентификация будет излишней.
В последних версиях OpenVPN включен механизм автоматического согласования протоколов шифрования между клиентом и сервером, по умолчанию будет выбран шифр AES-256-GCM, но так как вычислительные возможности VPS обычно ограничены и большого смысла шифровать канал доступа в интернет сложными шифрами нет, то отключим соглассование и укажем достаточно простой AES-шифр:
Также в новых версиях доступен новый механизм компрессии, для его включения укажем:
Данная опция будет автоматически отправлена на клиент, что облегчает его конфигурирование.
Если у вас есть старые версии клиентов (ниже 2.4), то можно использовать простое lzo-сжатие, для этого закомментируйте вышеприведенные строки и добавьте:
Эту опцию также потребуется добавить в конфигурационные файлы клиентов.
В целях безопасности понизим права запущенного сервера:
После чего проконтролируем наличие опций, отвечающих за правильные права к некоторым ресурсам после их понижения:
Укажем путь к файлам логов:
И укажем его подробность:
Во время отладки можно поднять уровень логов до 5-6.
Читайте также: