Pull to refresh

Comments 139

Аналогичная история с ДЦ в США. Можно найти приличный колокейшн и облака (Амазон, МС), все остальное — фуфло с завышенными ценниками (всякие «сервера у Джо» в каком-нибудь Канзасе, не то что с устаревшим интерфейсом, а просто номером телефона для связи). Подозреваю что на каком-то этапе AWS просто всех выкосил. Среднему бизнесу довольно тяжко (или может у меня просто задачи очень специфичные).
А кому легко? Нормально делай — нормаульно будет!
Из всех зарубежных хостеров, мне очень нравится Linode. Они настоящие профессионалы, за несколько лет никаких проблем. Всегда компетентная поддержка и качественные услуги. К сожалению нет тарифов с безлимитным трафиком. Veesp.com тоже молодцы, цены ниже чем у Linode и DigitalOcean при сравнимом качестве.
Linode и DigitalOcean — только виртуалки, т.е. про высокие нагрузки можно забыть. Ну и объема трафа там копейки — 10ТБ в месяц макс. За превышение — цена 20$\Тб, т.е. за скажем 30ТБ трафа в месяц (это 100 мбит\с 24\7) нода станет в $500.

У Veesp-а нижний ценник на дедик — $120, там сразу идет 16GB и мощный проц, т.е. брать их целесообразно только под виртуалки, опять же.
Linode и DigitalOcean — только виртуалки, т.е. про высокие нагрузки можно забыть.

У Linode есть виртуалки и за $1000 в месяц с 200GB RAM. Насчет трафика Вы правы. Но хочу заметить, что это качественные каналы и гарантированная полоса. Например, когда мы еще держали сервера в Европе, пользователи жаловались на сервер Scaleway у которого хоть и безлимитный трафик, но реальная ширина канала значительно ниже заявленой. Так что для продакшена я предпочту хостинг с ограниченной квотой трафика, но предсказуемым качеством сети.

У Veesp-а нижний ценник на дедик — $120

Я не знаю кому сегодня нужны bare metal сервера. Видимо тем, кому нравится переживать о ломающихся жестких дисках и писать в поддержку письма с просьбой поменять HDD на сервере. Я не спорю, что для некоторых задач выделенные сервера нужны, но на них обычно тоже ставят гипервизор и оперируют внутри виртуалками. Это проще и быстрее.
>Я не знаю кому сегодня нужны bare metal сервера
На самом деле много сегментов: игровые сервера, рекламные сети, в целом — везде где сетевая подсистема является узким местом. Из всех опробованных виртуальных сетевых интерфейсов (vmware, xen и пр.) ни один не дотягивал и до трети возможностей хорошей железки. Можно, конечно, взять три виртуальных сервера, вместо одной физической машины, но вот сейчас, например, у нас около 70 физических серверов (4 ядра\8Гиг оперативы, 30ТБ трафа на машину), по цене $75\мес. Аналог в DigitalOcean (4 ядра\8гиг\5Тб) стоит столько же. Умножаем на три, чтоб держать те же нагрузки. Получаем расход на хостинг 15К\мес (вместо текущих 5К на baremetal серверах). Т.е. отвечая на вопрос — bare metal сервера жизненно необходимы средним бизнесам, облака, к сожалению, подходят либо для очень мелких либо очень крупных бизнесов.
По поводу ломающихся дисков — не встречал конфигураций (кроме совсем запущенных случаев) с одним диском, а когда два диска в зеркале и мониторинг — то переживать не о чем.
Смотрели на Носикс?
Хм нет, не знаком. Судя по локации, они реселят S4U. На S4U мы жили первые три года, пока не осознали, насколько порезанные у них сети, причем как в VIP (ServerLoft) так и в бюджетном варианте.
Извините, я не знаю, что такое S4U. Можете просветить?
OVH в Канаде имеет ДЦ и продолжают расширяться. Цены там вполне приятные.
OVH был бы идеальным провайдером дедиков — отличное Intel-овское железо (материнки и лучшие сетевые карточки из всех что встречал), сказочные цены, более-менее вменяемый суппорт. Но их идиотский фаервол просто говорит вам «Нет», если у вас нагрузки от 100мбит\с и много мелких пакетов. Были даже попытки кастомизации под нас, как под крупного клиента, но в итоге мы проиграли битву с их великим фаерволом и потеряли несколько важных клиентов.
Скорее не фаервол, а антиддос. Мы в свое время из-за него туда ушли, но у нас просто сайт был (который ддосили неделями до этого и hetzner нам просто доступ к серваку вырубил из-за 6гбит ддоса).
Посмотрите https://www.1and1.com/, у нас там дедик, пол года полет отличный ))
На самом деле при выборе хостера нужно отталкиваться от поставленных задач.

Вам нужен безлимтный трафик — а я никогда не превышал этот 1 Тб в месяц.
Виртуализацию выбирает 1 человек из 100 и то в лучшем случае. Остальные просто не знают между ними разницу, да оно им и не нужно.

Не рекламы ради, но мне например нравится Vscale. Все шустро, дешево. Меня устраивает. И, да, я понятия не имею чем там делается виртуализация, хотя при выборе тафира кажется было написано.

Это что касается фразы «99% хостеров фуфло». Они просто не под ваши задачи, т.к. таких как вы менее 1% от общей массы клиентов.

P.S. Я не защищаю перечисленных 1Gb, Mh, reg.ru и прочую нечисть. Они совсем другая история.
Отчасти согласен. В статье описаны именно наши требования под VPN сервера. Мне кажется странным, когда в целой стране отсутствует хостинг под эту задачу, тем более что она вполне стандартная. Особенно раздражают ситуации, когда нужно пройти десять экранов заказа сервера и идти в отдельную панель чтобы включить его после покупки.

В reg.ru, кстати, раздражает, что после покупки сервера в почтовом ящике оказывается десять писем вроде «Вы успешно заказали сервер, вы успешно оплатили, сервер успешно загрузился, все хорошо, сервер работает, поздравляем все хорошо»

Vscale нам тоже советовали. Возможно он вполне хороший. Есть информация о том, как у них с IPv6?
Пока вообще никак.

Я бы еще на servers.com посмотрел
IPv6 мы делаем по запросу, в основном в приватных регионах. Выкатывание в паблик осложняется уязвимостью в openstack, позволяющей одному тенанту подделать RA для другого тенанта.

https://bugs.launchpad.net/bugs/1685237

Ждём фикса.
ISPmanager действительно не очень удобная панель, вспоминаю как мучался с ней лет 7 назад, когда она была на пике популярности. Странно, что нормальных аналогов до сих пор никто не придумал.

Нормальный аналог уже есть — ssh и конфиги а также ansible
Тут ситуация как с говнофорумами на php — те кто знают как сделать нормально им не нужно

Я имел в виду не только ISP, но и сам биллинг. А рядовому пользователю, чтобы добавить какой-нибудь сайт на php, знать ssh думаю не обязательно.
У veesp в описании storage-виртуалок речь идёт об ограничении в 100мбит. Неужели все эти 20 тысяч клиентов, даже поделенные на 6 серверов, умещаются в 100(600) Мбит? И локальный трафик внутри виртуалок тоже на 100Мбит-скорости?
Неужели все эти 20 тысяч клиентов, даже поделенные на 6 серверов, умещаются в 100(600) Мбит?

Число одновременных подкючений в пиковые часы примерно 6 тысяч, то есть по тысяче на каждый сервер. Мы не пускаем через себя весь трафик, а только к заблокированным сетям, так что хватает. Не смотря на то, что днем каналы нагружены почти полностью, пользователи не жалуются на скорость. Вот как это выглядит на одном сервере:
image
А почему вы искали хостинг именно в России? Не лучший вариант для обхода блокировок — в России свои собственные блокировки — эдак получается из огня да в полымя. Я бы скорее смотрел на такие страны, как Германия, Нидерланды. Правда, в Европе есть другая проблема… Найти безлимитный трафик с нормальной скоростью по-моему невозможно. Знает ли кто-нибудь подобный хостинг в европейских странах, при этом с безлимитным трафиком, всеми требованиями перечисленными здесь, и достаточно либеральным отношением к не всегда лицензионно чистым торрентам?
Потому что для европейских IP-адресов заблокирована Яндекс.Музыка и значительная часть музыки в VK. Это написано в статье. Наш сервис позволяет обойти именно блокировки в Украине. Так что сервера в России для этого отлично подходят. Мы маршрутизируем через себя только заблокированные сети, весь остальной трафик идет напрямую через основной интернет пользователя. Так что блокировки в РФ нас никак не затрагивают.
Scaleway оказался очень даже неплохим хостером с безлимитом и хорошей скоростью. Да, по железу там Atom'ы, но нам зашло, например. Ничего не могу сказать насчет IPv6, но ТС пишет, что использовали в том числе Scaleway, так что должно быть всё в порядке.
Scaleway на тарифе «Starter Cloud» за €2.99 начинал тормозить уже при 100 одновременных подключениях. Полагаю что это из-за слабого процессора и медленной памяти. IPv6 они не умеют нормально, выдают 1 адрес на сервер. При заявленных 200Mbit/s скорость не поднималась выше 100Mbit/s. Так что мы быстро от них отказались.
Вероятно, тормоза связаны с ARM-процессором. Про пропускную способность ничего сказать не могу. Мы пробовали только C2S тариф за €11.99, и скорость соответствует заявленной. В общем, я ничего не могу сказать про десятки хостеров, но после пары российских и одного Digital Ocean, Scaleway мне лично показался очень годным.
Вероятно, тормоза связаны с ARM-процессором.

У нас был x86 Atom в Париже.
А, прошу прощения. Я почему-то думал, что за 2.99 там только ARM, но ошибся. Может как-то связано именно с тем, что у вас виртуалка. Может и нет. У нас «baremetal cloud server». В Амстердаме, кстати. В любом случае, спасибо за исследование и статью.
Пятничный торт. Все больше режимов блокируют доступ к информации, заставляя компании цензурировать сетевой контент в том или ином виде. Ваш сервис решил проблему в Украине и обрел другой веер блокировок уже на территории РФ. Заставляет задуматься о недалеком будущем и глобальной сети VPN в разных юрисдикциях. Эдакий uncensored оверлей поверх Internet.
Хорошо! А то в новостях пишут, что парламент РФ уже запретил «средства для обхода заблокированных ресурсов»
парламент РФ уже запретил «средства для обхода заблокированных (на территории РФ) ресурсов»

Я про юрисдикции. Очевидно что на украинские блокировки плевать.

А можно выдавать клиентам OpenVPN адреса не из подсети, а из определённого списка адресов?


Пользуюсь как раз таким провайдером, который раздаёт пулы из 32 адресов на одну виртуалку. Может дело в OpenVZ, но это не особо важно, так как одновременно всё равно не более одного-двух устройств подключено.

Можно, с костылями. Клиентам OpenVPN выдавайте адреса из диапазона ULA, и сделайте NAT one-to-one:

# ip6tables -t nat -I PREROUTING -s ВНЕШНИЙ_АДРЕС/128 -j DNAT --to ULA_АДРЕС_КЛИЕНТА/128
# ip6tables -t nat -I POSTROUTING -s ULA_АДРЕС_КЛИЕНТА/128 -j SNAT --to ВНЕШНИЙ_АДРЕС/128

Попутно нужно включить маршрутизацию IPv6 через sysctl и убедиться, что правила в таблице FORWARD разрешают ее.

хм, а блокировками на родине вы так же обеспокоены? zapret.help что-то не вижу

Моя родина — Украина. Живу я при этом в Израиле. Для обхода блокировок в РФ есть аналогичный сервис https://antizapret.prostovpn.org/
UFO just landed and posted this here
Так рассматривали или нет? Или у вас бюджет 100 рублей и рассмотреть не получилось?
Вы сотрудник jino.ru? Я не понял несколько моментов. Что такое общий IP? Мне дадут какой-то порт на этом общем IP или что это значит?

При создании виртуального сервера ему бесплатно назначается IP-адрес, разделяемый с другими пользователями. На тарифах «Бета» и «Гамма» дополнительно можно приобрести до 3-х выделенных IP на каждую виртуальную машину. Стоимость каждого дополнительного адреса — всего 89 ₽ в месяц. А если в выделенном IP нет необходимости, вы экономите, не покупая его.


Нет информации о скорости сети на VPS и глупое требование к соотношению трафика:

На «Джино» нет ограничений по общему объему передаваемого трафика, но есть ограничение по его соотношению: объем входящего трафика не должен превышать 1/4 от объема исходящего. Стоимость превышения входящего трафика составляет 38 руб. за 1 Гб (полный или неполный).


То есть я могу выровнять вручную чтобы не платить лишнего?
Нет, конечно, никакой я не сотрудник. Мне интересно, смотрели или нет, так как сам им пользуюсь, но по мелочам. Общий IP — чесслово хз. Наверное один IP ведет на несколько VPS.

Нет информации о скорости сети на VPS

Наверное, сколько получится, я не замерял, но сайт быстро грузится.

То есть я могу выровнять вручную чтобы не платить лишнего?

Получается что так, хотя я бы ждал тут подвох 100%.
Худших услуг я уже довольно давно не видел.

Да, чёт отстой какой-то. Хотя хуже можно найти.

объем входящего трафика не должен превышать 1/4 от объема исходящего
Hetzner'ом запахло…

Ну хоть контрольная панель бесплатно, крайне щедрое предложение

Чем отличается виртуальный сервер с панелью «Джино» от сервера без нее?

Виртуальный сервер с панелью «Джино» отличается простотой администрирования. Вам доступен файловый менеджер, возможность управления базами данных, FTP-сервер и т. д., то есть полноценно настроенный сервер, который уже готов к работе. На сервере без нашей панели подобного функциональности нет, все управление производится через SSH-доступ, и он не имеет первоначальной настройки.
Ну Вы поняли… :))))
Использую Ваш сервис уже пару недель, очень нравится

Недавно и девушке поставили вместо того, что стоял у нее.
Только через Ваши сервера почему-то все сайты грузятся с огромной задержкой.Приходится его отключать после того, как попользовался вк, что весьма неудобно.

У меня таких проблем нету. Сам по себе у нее телефон новый, шустрый. Мой уже старенький, но с рутом.

Не знаете, в чем может быть проблема?
Вы не указали какая операционная система на устройстве. Полагаю, что это Android. Я как раз в статье описал эту проблему. Похоже на лаг в DNS резолве, то есть на преобразование доменного имени в IP-адрес уходит много времени, до нескольких секунд. И только тогда сайт начинает загружаться. Мне удаленно не удалось выяснить причину этой задержки. Возможно кто-то опытный, у кого есть устройство с таком проблемой, сможет выяснить в чем причина и описать решение в нашей wiki.
А какова монетизация проекта? Вижу, что вы предлагаете сразу скачать ovpn-файл, без регистраций и прочего. На чем проект зарабатывает? Кто оплачивает работу админов? Кто оплачивает пусть и 30 долларов за сервера?
Когда вижу подобные проекты сразу встает вопрос о том как же монетизируется. Не верю, что с кнопки доната вы хотя бы на час работы админа набрали за время работы проекта.
Час админа — можно и самому поработать.
С кнопки доната вполне можно наскрести на сервер. Если некоторые и жмотятся, то я уверен, что есть и те, кто донатит…
Ну там, положим, часов 12-16(так, навскидку) работы было, плюс мониторинг надо настроить и прочее, плюс бэкапы, плюс резервирование, плюс хотя бы раз в месяц все надо контролировать глазами. Набегает часов эдак 30-40 изначально(у меня низкая ставка, я беру $40 за час работы, но все равно это 1200-1600 долларов USA будет), плюс ежемесячное обслуживание, плюс проверка валидности бэкапов. Не верю я в энтузиаста, который ради доступа к быдлоклассникам и прочему российскому мусору станет так тратиться.
Потому и интересуюсь монетизацией.
Как-то же это должно хотя бы в ноль выходить, а лучше прибыль человеку приносить.
Неделю на этот проект? Муахахахаха
Кто оплачивает пусть и 30 долларов за сервера?

Сервера первое время оплачивал я, сейчас нам бесплатно дают сервера Veesp.com за что им больше спасибо.

Кто оплачивает работу админов?

Администрирование сервиса не занимает много времени, достаточно все настроить один раз. Мне много помогает советами ValdikSS когда я чего-то не понимаю. Он большой специалист по OpenVPN.

Когда вижу подобные проекты сразу встает вопрос о том как же монетизируется. Не верю, что с кнопки доната вы хотя бы на час работы админа набрали за время работы проекта.

Меня слабо мотивируют деньги, намного веселее угореть по хардкору сражаясь против цензуры в масштабах целого государства. Row Row Fight the Power! Еще меня завораживает осознание того, что десятки тысяч человек пользуются моей поделкой и она приносит им пользу. Этот кайф для меня гораздо ценнее денег.

Кстати насчет доната вы ошибаетесь. Нам задонатили больше 20 тысяч рублей. Это многократно превышает мои затраты. Так что люди способны организовываться вокруг справедливых и благородных идей.
> сейчас нам бесплатно дают сервера Veesp.com за что им больше спасибо.

То есть что бы обойти блокировку пропагандистких ресурсов страны-агрессора вы берете деньги у страны агрессора?
Тогда вопросов больше нет. Мне все ясно с проектом и его монетизацией. Извините, что потревожил.
Вы таки хотите сказать, что человек на окладе у ФСБ? Надо полагать вы тоже заметили, что задонатили в рублях. Прокол, не иначе!
То есть что бы обойти блокировку пропагандистких ресурсов страны-агрессора вы берете деньги у страны агрессора?

Мне не интересен политический срач. Я воспринимаю модель государства так же как крупную международную компанию, которая торгует с другими компаниями (государствами). У нее есть много отраслей деятельности и есть руководство. Эффективность компании я могу оценивать только по результатам ее работы и по условиям труда (уровню жизни) для ее сотрудников. Я не отождествляю себя с директором этой компании. Если компания работает плохо, я пойду работать в другое место. Я не понимаю что значит патриотизм, мне безразличны другие люди кроме моих друзей и родни.

Можно упростить это до такого примера. Представьте вы живете районе, который обслуживает управляющая компания. Она занимается вывозом мусора, обслуживанием отопления, чинит протечки крыши, заинмается уборкой подъездов и так далее. В соседнем квартале есть такой же район и им управляет другая компания. Оказывается что за те же деньги, которые вы платите за комунальные услуги, в соседнем районе управляющая компания еще и сажает цветы в клумбах, делает ремонт в подъездах. При этом крыша там не протекает, отопление не отключают, в повдвалах нет бомжей и никто не ссыт в подъездах. Когда вы задаете вопрос руководству своей управляющей компании, почему же у нас хуже чем у них, вам говорят, что в том районе вообще геи живут, они все плохие и тупые, а в нашем квартале особый народ живет! У нас есть духовность а у них нет, поэтому не обращайте внимание не протекающую крышу, ведь у нас особый путь.
Скорее, есть одна очень крупная (глобальная) корпорация, и она раздроблена на много более мелких компаний (государств), и когда топ-менеджеры этих небольших (по значимости и потенциалу) филиалов начинают вые..., им жестко показывают их реальное место в иерархии.
Признавайтесь, сколько недель вы тратите ежедневно на этот проект? Сколько бекапов зарезервировали уже, как часто проверяете глазами, а не другими органами?
Все бекапы у нас это десяток текстовых файлов. Они доступны на Github https://github.com/zhovner/zaborona_help
Развертывание нового сервера, при использовании интрументов вроде ansible, занимает несколько секунд.

Больше всего времени я трачу на поддержку пользователей и ответы на письма/комментарии. Но я делаю это только в свободное время и когда у меня есть настроение.
из-за этого приходилось перезапускать демоны OpenVPN…
и для преминения новых настроек пользователю достаточно переподключиться к серверу

предлагаю посмотреть в сторону параметра


management 127.3.2.1 7654

это позволит telnet-ом подключаться к соответствующему IP:порту и командой kill cn либо kill IP:port убивать подключение пользователя. в этом случае правильно настроенный клиент (должно хватить persist-tun в конфиге) сам автоматически переподключится


маленькая, а радость от применения настроек на лету, есть.

В любом случае приходится отключать клиентов. По опыту замечено, что из тысячи клиентов, десяток не переподключается нормально и начинает писать что у них проблемы. Многие держут VPN на роутерах где OpenVPN едва работает.
По поводу DNS-резолва: проблема не только на Android. На 3х ПК с Windows 10 резолв стабильно идет несколько секунд и это очень разражает, на Linux такого нет.
В целом за сервис огромное спасибо :)

извините за нескромный вопрос — а вы не рассматривали мысль о том, что с IP вашего сервера будут всячески провоцировать и разжигать, а шишки могут посыпаться на вашу голову?

Такой риск конечно есть. Не хочется садиться на бутылку вместе с Дмитрием Богатовым. Но надеюсь что обойдется. Тем более, что VK недавно убрал IPv6 записи со всех своих доменов (по слухам из-за того, что не смог побороть спам из IPv6 сетей) и идентифицировать конкретного пользователя не получится, потому что все ходят с одного ipv4 адреса.
кстати, с другой стороны — у вас приватный ключ в открытом доступе и один для всех клиентов.
компетентным админам в штатском любой страны (да просто любопытным хацкерам с прямыми руками) не составит труда «подсмотреть трафик»
Если вы не позиционируете свой сервис как анонимайзер (а насколько я вижу, так и есть) вы можете всю ответственность спихнуть в их адрес, мол «вы весь трафик пишете? вот вы и разбирайтесь, где ключи взять вы знаете»

Так что шанс стать гостем казенного дома в РФ, кмк, не велик (зачем подымать шум там, где можно тихо слушать)
Есть, правда, шанс, что на каком-нибудь ентер-ТВ из вас нарисуют злостного агента Кремля
Приватный ключ сервера у нас не в открытом доступе, без него расшифровать трафик нельзя. В публичном доступе у нас только приватный ключ клиента, который используется для аутентификации пользователя. В конфигурационном файле зашит корневой сертификат (ca), по которому клиент может проверить подлинность сервера, и если его будут MiTM-ить, то не подключится.

Кроме того, все сайты работают по HTTPS, так что даже если бы шифрование VPN было отключено, не было бы никакой разницы на канальном уровне.
Ну вы уже спланировали что будете делать в случае опасности?
И еще такой вопрос… Нет ли какого-нибудь древнего закона который запрещает всяким лодочникам использовать герб страны на сайте? Наверняка есть какое-то достопочтимое предписание. Как у нас с развешиванием флагов на своих ворота.
Ну вы уже спланировали что будете делать в случае опасности?

Я уже обезопасился, не переживайте.
Знаю только закон про гербовые печати и оскорбление флага.
Закинул денег коллеге :)

Пользуясь случаем скажу что для работы ok.ru в мобильных приложениях на IOS и Android их нужно просто обновить.
Вот вы использовали Ferm для генерации сотен идентичных правил для iptables на 3 интерфейса.

Была какая-то специфическая причина не использовать модуль ipset и обойтись всего тремя правилами (по одному на интерфейс)?

У меня например через cron/bash скрипт автоматически обновляется черный список на серверах. Очень удобно и всего одно правило. Там даже не сохраняется конфигурация iptables, просто заполняется ipset при перезагрузке.
Вы правы, можно было бы использовать ipset. Дело в личных предпочтениях.
Для большого списка адресов оправданно использовать ipset, я с вами полностью согласен, но у zhovner их 69, а не сотни. Заметного ускорения от использования ipset в этом случае нет, а проблемы появляются: нужно будет писать отдельные скрипты, чтобы таблицы ipset создавались до применения правил файрволла, иначе модуль ipset для iptables будет выдавать ошибку и не применять правила при загрузке, писать скрипты для работы с ipset и обновления.

Считаю, что конкретно в этом случае выигрывает удобство, а не максимальная корректность с технической точки зрения.
Немного непонял, как клиент определяет к какому демону подключаться? На стандартный порт или дополнительный
Это скорее делает операционная система возвращая программе один из IP-адресов полученных в DNS ответе. Такая балансировка сделана у многих сервисов, например домен google.com имеет очень много А-записей. Попробуйте несколько раз выполнить ping google.com и скорее всего увидите каждый раз разный IP адрес.
Прошу прощения, неправильно понял ваш вопрос. Iptables редиректит подключения к 1194 порту на другие.
UFO just landed and posted this here
К сожалению никак. Только вручную удалять сервер из DNS. Для этого ставим минимальный TTL 2 минуты.
Проблема еще в том, что при разрыве подключения клиент OpenVPN по умолчанию не резолвит адрес к которому был изначально подключен. Поэтому в случае отказа приходится просить пользователей либо перезапустить OpenVPN и очистить DNS кеш, либо вообще перезагружаться.

Ещё можно посмотреть в сторону remote-random в клиентском конфиге.


Что-то типа этого
...
server-poll-timeout 15
remote-random

<connection>
remote 1.example.net 1194 udp
;mssfix 1400
</connection>

<connection>
remote 1.example.net 443 tcp
</connection>

<connection>
remote 2.example.net 443 tcp4
</connection>

ignore-unknown-option block-outside-dns
block-outside-dns

# Эти вот не пушить и не определять в конфиге, а то не будет другой сервер выбирать при фейле:
;auth-nocache
;persist-key
;persist-tun
;persist-remote-ip
;user xxx
;group xxx
...
По проблеме обрыва.
Он не то чтобы не резолвит. Вы пушите клиенту persist-tun и это означает, что клиент при обрыве не должен рестартить туннель и не должен перечитывать файл конфига. Если убрать эту опцию для клиента то он будет успешно отваливаться вслед за сервером. А если сказать клиенту ping-restart то он ещё и подниматься сам будет. Бонусом можно ещё resolv-retry чтобы точно очухался.
keepalive является макросом над командами ping и ping-restart:
For example, --keepalive 10 60 expands as follows:

    if mode server:
        ping 10                    # Argument: interval
        ping-restart 120           # Argument: timeout*2
        push "ping 10"             # Argument: interval
        push "ping-restart 60"     # Argument: timeout
    else
        ping 10                    # Argument: interval
        ping-restart 60            # Argument: timeout
Он используется на zaborona.

OpenVPN 2.3 использовал системный резолвер, поэтому уважал TTL записи, которую он получил через DNS. Если происходит обрыв, используется опция persist-tun и время TTL уже вышло, домен будет пытаться резолвиться через DNS-сервер внутри VPN, хотя VPN-соединение не установлено.

OpenVPN 2.4 получает IP-адрес с домена только один раз, при первом подключении, и кеширует его, не уважая TTL записи. При переподключении он не обращается к DNS, а сразу переподключается по IP-адресу.

Раньше на zaborona не использовался параметр persist-tun, но, по какой-то причине, у людей на Windows, в случае разрыва соединения с сервером, переставал работать DNS вообще, до перезагрузки. Подозреваю, происходило следующее: сервис OpenVPN, по какой-то причине, не убирал блокировку сторонних DNS (опция block-outside-dns), туннельный интерфейс отключался, и все обращения на порт 53 оказывались заблокированными. У меня проблема не проявляется нигде, и люди, у которых она проявлялась, не написали мне на почту и не создали баги в багтрекере. Так что решено было эту опцию пушить с сервера.
keepalive я не заметил.
На виндовом OpenVPN 2.4 (или в виндовом TAP адаптере который идёт «в комплекте» или в виндовом сервисе самого OpenVPN либо вообще в комбинации всего этого) похоже что-то сильно намудрили вообще с кешем.
Конкретно я видел проблемы с ARP кешем когда уже после поднятия туннеля траф не маршрутизируется с ошибкой no route to host или что-то в этом духе. ARP кэш TAP адаптера при этом невозможно было удалить (invalid) до перезагрузки либо с помощью ручного disable-enable TAP интерфейса. Это проявлялось когда IP выдаётся новый на каждое новое подключение.
На 2.3 такого не замечал.
UFO just landed and posted this here

Насколько я помню, фатальный недостаток поддержки OpenVPN в RouterOS так и не починили, и он до сих пор работает только через TCP.

Не сталкивался с этой ошибкой. Чаще всего либо TAP адаптер занят, либо отсутствует.

Чтобы не хранить маршруты и другие общие настройки в двух (или более) разных файлах, вероятно удобнее будет использовать опцию в клиентских конфигах (ну или в DEFAULT):


config /some/path/to/shared-ccd-config

Так одинаковые настройки для всех серверов и клиентов будут в одном файле.

Да, наверное вы правы.
Пользуясь случаем хочу сказать спасибо за этот сервис!
Есть ли в планах поддержка протоколов PPTP/L2TP или IPSec (нужны для подключения к Zaborona.Help через роутеры Tp-Link серии WR-xxx без изменения прошивки на OpenWRT)?
Есть такие мысли, но с ipsec/ikev2 у меня не получилось реализовать ту же задачу. Например встроенный клиент ikev2 в Windows не принимает больше 25 маршрутов. У других протоколов тоже хватает проблем.
Большое спасибо за такой шикарный сервис!

Можно немного подробнее о проблемах других протоколов? Например PPTP и раздача маршрутов с помощью isc-dhcp-server. Знаю что dnsmasq не умеет отдавать очень много статических маршрутов, кажется более 28. PPTP есть везде, тем и интересен.

Ещё раз спасибо.

Debian, OpenVPN 2.4. Все работает, кроме git :D

Не могу сделать pull/push в приватный репозиторий на bitbucket

Я не понимаю как это относится к теме статьи.
Я обожаю Ваш сервис. Честное слово.
Но я не могу понять, почему при включенном VPN zaborona.help я не могу подключиться к SSH серверу bitbucket. Соответственно, не могу работать с удаленным репозиторием.

Но за минусы конечно спасибо
Что бы процессы openvpn не скакали между разными процессорами, стоит каждый «прибить» к процессору. В моём случае это увеличивало производительность процентов на 20.
Что бы клиенту не перегружать сервис openvpn, если текущий сервер стал не доступен, можно вместо шести A-записей в FQDN в опции remote, использовать шесть опций remote с FQDN с одной A-записью и опцией --remote-random (или три опции remote с FQDN с двумя А записями или три).
Точно так же добавлением доп. опций remote можно разруливать у клиента случайный выбор конкретного демона (порта), не нагружая ведением статистики iptables, хотя, возможно, эта нагрузка мизерна.
Что бы процессы openvpn не скакали между разными процессорами, стоит каждый «прибить» к процессору. В моём случае это увеличивало производительность процентов на 20.

Спасибо, попробую. Не знал об этом.

Что бы клиенту не перегружать сервис openvpn, если текущий сервер стал не доступен, можно вместо шести A-записей в FQDN в опции remote, использовать шесть опций remote с FQDN с одной A-записью и опцией --remote-random (или три опции remote с FQDN с двумя А записями или три).

Мы заранее не знали какое будет точно количество серверов в итоге, поэтому не стали так делать. Как в таком случае исключать домен из списка? Как поведет себя клиент если один из доменов в списке будет без A-записи? Старые клиенты тоже поддерживают это?
Возможно, стоит убрать и шифрование, зачем нагружать свои сервера, судя по тому, для чего служит ваш проект, шифровать трафик не зачем, шифровать трафик клиента будет сам клиент и тот ресурс к которому вы предоставляете доступ (TLS). Если конечный ресурс считает, что трафик шифровать не зачем, то зачем вам его шифровать?
Ещё, я бы использовал UDP протокол для OpenVPN, а все фишки TCP (целостность, упорядочивание, подтверждение и т.д.) возложил бы на клиента и конечный ресурс.
Мы заранее не знали какое будет точно количество серверов в итоге… Как в таком случае исключать домен из списка?

Как вариант сделать две записи remote в каждой по 3 FQDN, а на стороне сервера включать/исключать сервера, плюс две записи с другим портом с теми же FQDN. Кроме того. никто не мешает делать повторяющиеся IP, в разных FQDN, главное распределить так, что бы равная вероятность подключения была.
Как поведет себя клиент если один из доменов в списке будет без A-записи?

Именно такой кейс не тестировал, но думаю, не удалось подключиться, переходит к следующей случайной опции remote.
Старые клиенты тоже поддерживают это?

На сколько помню, как я начал использовать openvpn для своих целей с 2004 года, с тех пор эта опция и работает.
Возможно, стоит убрать и шифрование, зачем нагружать свои сервера, судя по тому, для чего служит ваш проект, шифровать трафик не зачем, шифровать трафик клиента будет сам клиент и тот ресурс к которому вы предоставляете доступ (TLS). Если конечный ресурс считает, что трафик шифровать не зачем, то зачем вам его шифровать?

Это хороший вопрос, я тоже думал об этом. Но тут есть несколько факторов: многие провайдеры сейчас блокируют по DNS, при этом перехватывая запросы к любым DNS серверам. Вполне возможно что потом они, как и провайдеры в России, начнут использовать системы DPI и будут ловить подключения к запрещенным сайтам по SSL SNI, матчить HTTP заголовки и так далее. Если так случится, придется все перенастраивать и заставлять клиентов скачивать новый конфиг. Я бы использовал вместо шифрования какой-нибудь режим обфусцирования типа XOR, но такого в OpenVPN, как я понял нет.

я бы использовал UDP протокол для OpenVPN, а все фишки TCP (целостность, упорядочивание, подтверждение и т.д.) возложил бы на клиента и конечный ресурс.

Использование TCP сознательный выбор для экономии трафика и батарейки на мобильных устройствах. Так как стандартный таймаут NAT трансляций для UDP подключений намного ниже чем для TCP, поэтому в случае с UDP клиент чаще шлет keep alive.

многие провайдеры сейчас блокируют по DNS, при этом перехватывая запросы к любым DNS серверам...

Так DNS-запрос не будет выглядеть как DNS-запрос, и SSL как SSL, так как:
1. Порты совсем другие;
2. Инкапсуляция, то есть в начале будут заголовки самого протокола OpenVPN.
Понятно, что можно научить искать не шифрованный трафик OpenVPN, разбирать его заголовки и добираться до содержимого DNS, SNI, но это не штатными средствами перенаправить все запросы на 53 порт на какой-то свой сервер. ИМХО, прежде чем дойдёт до разбора содержимого не шифрованного VPN канала, скорее запретят весь трафик OpenVPN в DPI по его характерным признакам.
поэтому в случае с UDP клиент чаще шлет keep alive

У вас в настройках keepalive 300 900 если оставить так же для UDP, будет с такой же переодичностью в пять минут слать keepalive, но вам виднее.
Есть такие DPI, которые могут отслеживать запросы даже внутри HTTP- и Socks5-прокси, на любом порту. Я их называю Full DPI.

У вас в настройках keepalive 300 900 если оставить так же для UDP, будет с такой же переодичностью в пять минут слать keepalive, но вам виднее.
Слабые домашние роутеры могут забывать о UDP-соединении уже через 40 секунд. На какой-то из мобильных сетей РФ UDP-соединения забывались уже через 25 секунд.
Данные о TCP-соединениях хранятся минимум 5 минут, обычно около 15.
Есть такие DPI, которые могут отслеживать запросы даже внутри HTTP- и Socks5-прокси

Не сомневаюсь, но встречал блокировку всего протокола OpenVPN, а вот анализ не шифрованного OpenVPN и блокировку на основе полученного результата, пока не встречал.
В дополнение к предыдущему, если от шифрования отказаться нельзя, то хотя бы стоит отключить защиту от так называемых replay attack, когда для каждого пакета подсчитывается HMAC. Процентов 10 производительности и тут выиграешь.
Самую большую нагрузку на процессор создает не шифрование, а переключение контекста и чтение по одному пакету за раз. Шифрование на 3-4 месте по нагрузке на процессор в профилировщике.
Не скажи… Вот прям сейчас протестировал у себя:
1. Без шифрованияния: 115 мбайт/сек, загрузка одного ядра ~10%.
2. С шифрованием BF-CBC, для SOHO-роутеров, и auth none: 107 мбайт/сек, загрузка одного ядра 85%.
Да, процессы между ядрами не перемещаются.
Подозреваю, что при шифровании каждого пакета больше переключений контекста, а если ещё HMAC считать…
На моем старом роутере на MIPS-процессоре с частотой 560 МГц, без шифрования где-то 24 мегабита в секунду, а с шифрованием — 19-21.

Если уменьшить переключения контекста, увеличив MTU до 18000, то без шифрования были стабильные 100 мегабит (ограничение порта), а с шифрованием — около 70.
На MIPS влияние отключения шифрования не изучал, только самый быстрый шифр выявлял, собственно BF-CBC самым быстрым и оказался.
Для быстрого переключения контекста, нужны мегагерцы, ну и кэш в процессоре важен, видимо поэтому MIPS быстро не переключается с такими частотами.
Сорри, iperf пишет сколько мбайт передал, но скорость пишет в мбитах, поэтому 115 мбит/сек и 107 мбит/сек соответственно. Насторожили меня мегабайты/сек поэтому пошёл перепроверять.
UFO just landed and posted this here
UFO just landed and posted this here
Ширина канала не бесконечная. Ограничения трафика нужно воспринимать как плату за ширину канала доступную вам в единицу времени. Например квота в 30ТБ значит, что вы можете занимать канал месяц на скорости 100Mbit/s или несколько дней на скорости 1Gbit/s или несколько часов на скорости 10Gbit/s.

Извините, а почему для пункта описания пункта "Панель BillManager, ISPmanager и т.д." вы выбрали скриншоты 4-го биллинга? Он был выпущен более 10(!) лет назад, уже года три не развивается и года полтора как снят с продажи. Для наглядности?
Пятёрка выгдядит куда свежее, через пару месяцев будет шестёрка, и в ЛК на ISPsystem ее можно посмотреть-пожмакать http://prntscr.com/fo8cw7

Не смотрели в сторону SoftEther VPN? Кроме того, что есть гуй управления, с его помощью можно поднимать сервер SSTP или L2TP, а SSTP настраивается встроенными средствами Windows, L2TP — встроенными средствами Android и iOS, а так же он умеет общаться и по OpenVPN протоколу — а значит к нему можно подключиться в том числе при помощи OpenVPN.
Комментарий по теме
https://habrahabr.ru/post/208782/#comment_8738737
Здравствуйте. В программном обеспечении существует такое понятие как продукт. Не часто сталкиваешься с ПО, вышедшем в Японии. То, что я увидел в SoftEther VPN — это какой-то суррогат, особенности:
1. Вроде бы поддержка более 4х туннелей одновременно должна как-то предполагать, что продукт будет поддерживать возможность организации сети из коробки. Только не тут. Встроенный SecureNAT (странное название) — это всего лишь кривой программный тормозной NAT и такой же недоделанный DHCP сервер. Для клиентов PPTP, L2TP от MS SeсureNAT не назначает вам адрес автоматически. Серверу не удается вписать в конфиг клиента и даже шлюз по умолчанию. Хотя для клиентов openVPN при верном конфиге процедура проходит успешно.
2. Вы не сможете сделать так, чтобы сервер пушил статические адреса вашим клиентам. Представляете, тут этого нет! Если вам нужна статика, вам придется руками каждому клиенту вписать это в настройке адаптера. Наверное, те, кто имеет дело с Микротиками, где все это работает из коробки, дружно начали улыбаться.
3. Качество работы разных туннелей может отличаться на порядок. Это касается скорости работы при включенном SecureNAT на разных туннелях и клиентах. Количество зафейленных подключений намного выше, чем в комбинации с тем же микротиком. То есть поддержки разной клиентуры (MS PPTP, L2TP: Linux PPTP, L2TP) по сути нет, а основная картинка софта — тупой развод. Потеряете свое время и получите кардинально разный результат.
4. Позиционирование использования этого недософта в связке с отдельно запущенными DHCP серверами, DNS и пр — я тогда не понимаю его смысла, я бы настроил Линукс сервер и развернул бы там те туннели в виде серверов, что мне нужны.
5. Форум и программисты из страны восходящего солнца просто кишат советами — допилите сами, мы же выложили в openSource.
6. SecureNAT с локальным бриджем работает криво на разных клиентах. На лицо баги в том, какие именно настройки сервер прописывает клиенту при подключении. Поэтому проблем с доступностью, пингами и прочими будет навалом и будет зависеть от клиента. ICMP может не вернуться, а ресурс в сети то быть доступным, то нет.
7. Здесь же конечно можно написать — настрой на сервере NAT сам, пропиши маршруты. Без проблем, только при условии, что и остальное будет сделано также. Этой софтине не может быть места на сервере при таком положении дел. Такое чувство, что она была сделана под задачу — наплодить кучу vpn серверов, которые выводят трафик где-то там. И наверняка, где-то там его еще и слушают.
Какой смысл было писать о таком ПО тут на Хабре? Мы тут собрались развиваться или терять свое время? Вам я точно не посоветую терять свое время, разбираясь в этом. Конечно их программа-клиент решает ряд проблем. Но попробуйте заставить своих клиентов-людей ставить внешний клиент VPN.

Сделал свой сервере по вашим настройкам https://habrahabr.ru/post/329248/ и недостающее донастроил по https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04 но все равно не хочет:


`
Tunnelblick: OS X 10.12.5; Tunnelblick 3.7.2beta03 (build 4840); prior version 3.7.2beta02 (build 4830)
2017-06-26 12:52:24
Tunnelblick: Attempting connection with vpn; Set nameserver = 769; monitoring connection
2017-06-26 12:52:24 Tunnelblick: openvpnstart start vpn.tblk 1337 769 0 3 0 1065264 -ptADGNWradsgnw 2.3.17-openssl-1.0.2k
2017-06-26 12:52:24
Tunnelblick: openvpnstart log:
OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):


      /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.17-openssl-1.0.2k/openvpn
      --daemon
      --log
      /Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Svpn.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_0_1065264.1337.openvpn.log
      --cd
      /Library/Application Support/Tunnelblick/Shared/vpn.tblk/Contents/Resources
      --verb
      3
      --config
      /Library/Application Support/Tunnelblick/Shared/vpn.tblk/Contents/Resources/config.ovpn
      --verb
      3
      --cd
      /Library/Application Support/Tunnelblick/Shared/vpn.tblk/Contents/Resources
      --management
      127.0.0.1
      1337
      --management-query-passwords
      --management-hold
      --script-security
      2
      --up
      /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
      --down
      /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

2017-06-26 12:52:24 Unrecognized option or missing parameter(s) in /Library/Application Support/Tunnelblick/Shared/vpn.tblk/Contents/Resources/config.ovpn:9: ncp-ciphers (2.3.17)
2017-06-26 12:52:24 Unrecognized option or missing parameter(s) in /Library/Application Support/Tunnelblick/Shared/vpn.tblk/Contents/Resources/config.ovpn:10: block-outside-dns (2.3.17)
2017-06-26 12:52:24 OpenVPN 2.3.17 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jun 21 2017
2017-06-26 12:52:24 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
2017-06-26 12:52:24 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2017-06-26 12:52:24 Need hold release from management interface, waiting…
2017-06-26 12:52:24 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2017-06-26 12:52:24 MANAGEMENT: CMD 'pid'
2017-06-26 12:52:24 MANAGEMENT: CMD 'state on'
2017-06-26 12:52:24 Tunnelblick: Established communication with OpenVPN
2017-06-26 12:52:24 MANAGEMENT: CMD 'state'
2017-06-26 12:52:24 MANAGEMENT: CMD 'bytecount 1'
2017-06-26 12:52:24 MANAGEMENT: CMD 'hold release'
2017-06-26 12:52:24 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2017-06-26 12:52:24 Socket Buffers: R=[131072->131072] S=[131072->131072]
2017-06-26 12:52:24 Attempting to establish TCP connection with [AF_INET]67.207.73.65:1194 [nonblock]
2017-06-26 12:52:24 MANAGEMENT: >STATE:1498470744,TCP_CONNECT,,,
2017-06-26 12:52:24
Tunnelblick: openvpnstart starting OpenVPN
2017-06-26 12:52:33 TCP: connect to [AF_INET]67.207.73.65:1194 failed, will try again in 5 seconds: Operation timed out
2017-06-26 12:52:38 MANAGEMENT: >STATE:1498470758,TCP_CONNECT,,,
2017-06-26 12:52:47 TCP: connect to [AF_INET]67.207.73.65:1194 failed, will try again in 5 seconds: Operation timed out
2017-06-26 12:52:52 MANAGEMENT: >STATE:1498470772,TCP_CONNECT,,,
2017-06-26 12:53:01 TCP: connect to [AF_INET]67.207.73.65:1194 failed, will try again in 5 seconds: Operation timed out
2017-06-26 12:53:06 MANAGEMENT: >STATE:1498470786,TCP_CONNECT,,,
2017-06-26 12:53:14 TCP: connect to [AF_INET]67.207.73.65:1194 failed, will try again in 5 seconds: Operation timed out
2017-06-26 12:53:19 MANAGEMENT: >STATE:1498470799,TCP_CONNECT,,,
`


Хостинг на DigitalOcean. Вот настройки firewall:


root@mx2:~# ufw status
Status: active


To Action From




1194/udp ALLOW Anywhere
OpenSSH ALLOW Anywhere
1194/udp (v6) ALLOW Anywhere (v6)
OpenSSH (v6) ALLOW Anywhere (v6)


В чем может быть загвоздка?

А у вас OpenVPN вообще запущен на сервере? Покажите вывод команды netstat -ntlup

За запущен


root@mx2:~# netstat -ntlup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      3040/openvpn    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1367/sshd       
tcp        0      0 46.101.97.201:25        0.0.0.0:*               LISTEN      1818/exim4      
tcp        0      0 10.19.0.7:25            0.0.0.0:*               LISTEN      1818/exim4      
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1818/exim4      
tcp6       0      0 :::22                   :::*                    LISTEN      1367/sshd       

root@mx2:~# service openvpn status
● openvpn.service - OpenVPN service
   Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2017-06-26 09:48:05 UTC; 4h 50min ago
  Process: 3022 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 3022 (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
      CPU: 0
   CGroup: /system.slice/openvpn.service

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Я не могу подключиться на 46.101.97.201:1194. Возможно этот порт блокируется фаерволлом?
> Он позволяет избавиться от кучи ненужных сущностей, вроде NAT и проброса портов.
Уже от одной этой фразы мне хочется не иметь ничего общего c IPv6. Я более-менее спокойно сижу в интернете только потому, что знаю, что нахожусь за NAT роутера, и никакая зараза типа WannaCry мне не грозит. А вы тут мне говорите что выставить все порты наружу — это типа достоинство. Можнт и оно и так, но точно не для параноиков вроде меня.
Я более-менее спокойно сижу в интернете только потому, что знаю, что нахожусь за NAT роутера

Это абсолютно ложное ощущение безопасности, потому что вам могут просунуть соседи по локальной сети, либо снаружи через UPnP, NAT-PMP или используя уязвимости soho-роутера. Думать что NAT имеет какое-то отношение к безопасности — заблуждение.

Кроме того, у нас заблокированы все входящие соединения для IPv6 адресов.
UPnP выключен, компьютеры в домашней сети я более-менее могу контролировать, уязвимости роутера конечно никто не отменял, но это всё же скорее целевая атака должна быть, а моя цель — отбиться от массовых атак.
>у нас заблокированы все входящие соединения для IPv6 адресов.
>>Он позволяет избавиться от… проброса портов.
Ну да, если полностью отказаться от входящих — это действительно радикально помогает избавится от проброса портов.
Кстати wannacry как раз смог так массово распространяться по интернету из-за ipv4, потому что атакующие могут легко сканировать весь ipv4 интернет. В случае использования ipv6 и privacy extension, вероятность что вас кто-то сможет просканировать случайным перебором адресов очень мала.
Sign up to leave a comment.

Articles

Change theme settings