Главная особенность нашего сервиса в том, что через VPN маршрутизируется трафик только к заблокированным сетям, остальные сайты работают напрямую. Это не влияет на скорость интернета и не подменяет IP-адрес для остальных сайтов.
В статье описываются тонкости настройки OpenVPN для большого числа клиентов, на дешевых VPS.
- Как выбрать подходящий хостинг. Отличительные черты плохого хостинга. История о том, как мы долго искали и нашли хостинг в России.
- Почему IPv6 — хорошо. Правильная настройка IPv6-адресов для VPN-клиентов.
- Изменение конфигурации OpenVPN на лету, без перезапуска сервера и отключения клиентов.
- Балансировка нагрузки между серверами и процессами OpenVPN
- Тонкая настройка Linux для большого числа подключений
- Особенности кривых операционных систем и роутеров пользователей
Наш опыт будет полезен для тех, кто собирается развернуть VPN для личных нужд, и тех, кто хочет создать сервис с большим числом клиентов.
Хостинг
Поначалу мы использовали несколько серверов в Европе у провайдеров Scaleway, Linode, DigitalOcean. Это были самые дешевые VPS, за $3-5. Сразу же пользователи начали жаловаться, что из-за европейских IP-адресов Яндекс.Музыка и музыка VK.com недоступна. Мы начали искать подходящий хостинг в СНГ.
Оказалось, что отечественных хостеров, сравнимых по уровню услуг с европейскими, не существует. Почти всегда это низкое качество услуг при высокой цене, сложная процедура заказа, устаревшие технологии. За время поиска мы успели сформировать список отличительных черт плохого хостинга.
Отличительные черты убогого хостинга
- Использование термина VDS вместо VPS. Хоть в самой аббревиатуре нет ничего страшного, это своего рода черная метка, которая практически гарантирует низкий уровень сервиса и интерфейс панели управления из 90-х годов.
- Панель BillManager, ISPmanager и т.д. — эталон переусложненного интерфейса с кучей кнопок, непонятных меню. Процесс заказа сервера в таких панелях выполняется в несколько этапов. Панель управления самим сервером обычно находится на отдельном от панели заказа поддомене, с отдельным логином-паролем, переход в которую осуществляется не самым очевидным способом. Процесс заказа или изменения услуги превращается в настоящие мучение, часто требующее обращение в техподдержку. Если процедура заказа сервера требует больше нескольких кликов и занимает больше двух минут — это плохой хостинг.
Интерфейс панели управления BillManager — отличительная черта устаревшего хостинга
- Непонимание принципов IPv6. Многие хостеры выделяют один IPv6-адрес и требуют плату за каждый дополнительный. Сеть /64 будет стоить квинтиллионы долларов.
- Виртуализация OpenVZ.Большинство коммерческих VPS-провайдеров OpenVZ используют интерфейс venet, и панели, которые не позволяют назначать подсеть IPv6-адресов на отдельный контейнер, а только по одному отдельному адресу (/128) на интерфейс. Такие адреса нельзя нормально раздавать клиентам VPN.
Попробовав несколько хостингов, мы почти отчаялись. Казалось, что в России просто не существует нормального хостинг-провайдера для наших нужд. Я разослал письмо всем хостерам, которых смог найти на сайтах-агрегаторах хостинга, в котором описал наши требования, и попросил бесплатно предоставить нам площадку в обмен на рекламу на нашем сайте.
Наши требования к VPS-серверам
- Виртуализация XEN или KVM. OpenVZ в большинстве случаев не позволяет нормально управлять IPv6-адресами, имеет ограничения на настройку переменных ядра (sysctl). Для некоторых нужд OpenVZ вполне пригоден, но не для большого и высоконагруженного VPN-сервера.
- Мощный серверный процессор. Некоторые провайдеры, вроде Scaleway, предлагают бюджетные VPS-серверы на маломощных процессорах ARM или Intel Atom. Бывают даже серверы на процессорах VIA. На таких системах OpenVPN работает медленно, но не из-за шифрования, как можно было бы предположить. Модуль tun, который используется OpenVPN для создания сетевого интерфейса, не оптимизирован под высокие нагрузки: он принимает или отдает только один пакет за системный вызов, из-за чего происходит большое количество переключений контекста между режимом ядра и пользователя. Чем медленнее частота памяти и дешевле процессор, тем медленнее происходит переключение. Кроме того, в коде OpenVPN используются системные вызовы recv и send, оперирующие единичными сетевыми пакетами, из-за чего отправка зашифрованных пакетов тоже происходит не самым оптимальным образом. Поэтому для нормальной работы OpenVPN важно иметь быстрый процессор и память.
- Безлимитный трафик и хорошие каналы. Пользователи потребляют много медиа-контента в социальных сетях, трафик расходуется очень быстро. Тарифы с низкой квотой трафика (1ТБ) расходуются за сутки.
- Отдельная маршрутизируемая сеть IPv6 необходима для прямого выделения реальных адресов клиентам. Большинство хостеров даже не понимают, что это значит, и просто назначают на сетевом интерфейсе гипервизора требуемую подсеть, а не создают запись в таблице маршрутизации через существующую (или через link-local-адрес). Это не позволяет без костылей назначить выданный диапазон на сетевой интерфейс VPN и выдавать IPv6-адреса напрямую клиентам: гипервизор хостера отправит NDP-запрос (аналог ARP для IPv6) виртуальной машине, виртуалка не найдет у себя этот адрес, не ответит на запрос, и ничего не заработает. Существуют NDP-прокси, которые позволяют обойти эту проблему, но это неудобно, и из-за этого может создаваться дополнительная нагрузка на гипервизор и маршрутизаторы хостера.
На наш запрос откликнулось около десятка компаний, но почти все из них имели признаки убогого хостинга и не подходили. В результате мы-таки нашли ЕДИНСТВЕННОГО хостинг-провайдера, удовлетворяющего всем нашим нуждам.
Это звучит странно, но я готов аргументированно доказать в комментариях, что 99% отечественных хостеров — фуфло, недотягивающее до уровня Европы. Особенно буду рад пообщаться с представителями крупных компаний, вроде МастерХост, REG.ru, 1GB.ru, Timeweb.
Как мы подружились с Veesp.com
Настоящим открытием для нас стал хостер Veesp.com с датацентром в Санкт-Петербурге. Это единственный хостер, который знал как правильно готовить IPv6. На каждый VPS сервер выделяется сеть /64 и по запросу /56.
У них есть две линейки тарифов VPS. Мы используем тариф «Storage 1», с безлимитным трафиком. Сервера на этом тарифе имеют процессор Intel Xeon X5650. Также есть линейка тарифов «Compute», с SSD диском, мощным процессором Intel Xeon E5v4 и памятью DDR4.
Линейка тарифов Compute VPS провайдера Veesp.com
Панель управления сравнима по удобству с DigitalOcean. Есть даже оплата через Bitcoin!
На текущий момент мы полностью переехали на площадку Veesp.com и используем шесть серверов Storage 1 для OpenVPN. Музыка в VK и Яндексе снова работает, пользователи довольны.
IPv6
Я очень люблю IPv6. Он позволяет избавиться от кучи ненужных сущностей, вроде NAT и проброса портов. Для VPN он удобен тем, что каждый клиент ходит в интернет со своим реальным IP-адресом. К сожалению, многие хостинг-провайдеры и системные администраторы противятся и недолюбливают этот протокол, из-за этого его неправильно настраивают и используют.
Самая распространенная ошибка — выдавать один IPv6-адрес на сервер.
Сайт slash64.net посвященный этому заблуждению.
Почему нужно выделять минимум /64 на каждый конечный узел
- Для простоты. Согласно RFC 6177, сеть /64 является рекомендуемым блоком для всех конечных узлов, будь то домашний интернет или хостинг. Это 2??, или восемнадцать квинтиллионов IP-адресов. Такой подход избавит от путаницы и угадывания, как именно настроена сеть на каждом отдельном узле.
- Меньшее потребление памяти на маршрутизаторах. Сетевому администратору достаточно маршрутизировать на ваш одну большую подсеть, а не несколько мелких.
- Не ломает протокол автоконфигурации SLAAC. Если вы, вдруг, захотите сделать полноценную локальную сеть (L2) поверх интернета, в ней будет корректно работать IPv6.
- По логике Email-провайдеров, крупных сайтов вроде Google и Facebook, один клиент — одна /64 сеть. Поэтому, если хостер выдает разным клиентам адреса из одного диапазона /64, вас могут заблокировать за действия, которые совершили соседи по диапазону.
- IPv6-адреса не должны продаваться поштучно. Это глупость, потому что минимальный рекомендованный блок /64, который должен выдаваться бесплатно, будет стоить квинтиллионы денег, даже если цена за один IP-адрес будет один рубль.
Чтобы выдавать клиентам VPN IPv6-адреса напрямую без костылей, нужно иметь отдельную маршрутизируемую сеть через IPv6-адрес на сервере, то есть подсеть, из которой планируется раздавать адреса клиентам, не должна быть назначена на интерфейс сервера, но должна маршрутизироваться через какой-либо адрес на сетевом интерфейсе сервера.
Существует два распространенных варианта раздачи маршрутизируемах сетей.
Первый вариант: одна /64 на сетевом интерфейсе, и /56, маршрутизируемая через первую /64. Вы можете побить /56 так, как вам хочется, либо же назначить всю /56 на интерфейс VPN.
Второй вариант: одна или несколько /64 (или больше), маршрутизирутизируемая через link-local-адрес.
У большинства хостеров выделенную сеть нужно заказывать отдельно. Veesp.com выдает блок /56 на каждый сервер бесплатно. К сожалению, даже продвинутые хостеры, вроде DigitalOcean, не предоставляют такой услуги. Здесь есть список хостеров, предоставляющих данную услугу version6.ru/vps, от @rm.
NAT и Firewall
На серверах забороны больше двух сотен правил iptables, по несколько на каждый диапазон из списка запрещенных в Украине сетей.
Сложный набор правил неудобно обслуживать стандартными средствами
iptables-save и iptables-restore, потому что в случае изменения одного правила, необходимо будет редактировать сотни однотипных строк.Упрощаем написание правил файрволла с помощью ferm
Ferm — утилита для управления сложными правилами iptables со своим синтаксическим сахаром. Она позволяет создать удобочитаемую конфигурацию iptables, использовать переменные, массивы и циклы, но не ограничивает вас, в отличие от других надстроек над iptables: вы можете делать абсолютно все, использовать все возможности и модули netfilter.
Простой пример: мы хотим заблокировать входящие соединения из нескольких тысяч сетей на трех сетевых интерфейсах eth0, eth1, eth2. В обычном случае нужно было бы написать тысячи одинаковых правил для каждого интерфейса.
Вот как эта задача решается через ferm:
@def $WAN_0 = eth0;
@def $WAN_1 = eth1;
@def $WAN_2 = eth2;
@def $BLOCKED_NETWORKS = (
123.123.123.123
234.234.234.234
....
);
chain INPUT {
saddr $BLOCKED_NETWORKS of ($WAN_0 $WAN_1 $WAN_2) DROP;
}
В результате будет создано правило для каждого адреса из $BLOCKED_NETWORKS на каждый сетевой интерфейс. Такая запись легко читается и занимает в три раза меньше строк. Ее проще редактировать.
В нашем случае iptables выполняет три функции: NAT для IPv4-соединений, ограничение доступа в другие сети и балансировка нагрузки между процессами OpenVPN. Разберем каждую задачу подробно.
NAT для IPv4-соединений
Клиентам выдается «серый» IP-адрес из диапазона 192.168.*.*, поэтому маршрутизировать его напрямую в интернет нельзя. Для того, чтобы выпустить клиентов в IPv4-интернет, нужно использовать преобразование сетевых адресов (NAT).
Тем же самым занимается ваш домашний WiFi-роутер. На каждое исходящие соединение клиента создается трансляция в памяти сервера, которая хранит информацию о том, кому какое подключение принадлежит. Несмотря на то, что эта операция требует мало ресурсов сервера, при огромном количестве подключений (десятки тысяч), это может стать ресурсоемкой задачей для слабого сервера.
Этой проблемы нет в IPv6, так как каждому VPN-клиенту выдается реальный IP-адрес, который напрямую маршрутизируется в интернет. Серверу остается только перебрасывать пакеты с одного интерфейса на другой, без создания трансляций и хранения информации о каждом подключении.
Ограничение доступа в другие сети
Любой пользователь может добавить опцию redirect-gateway в конфиг OpenVPN и использовать наши сервера как маршрут по умолчанию. Нужно закрыть доступ ко всем сетям, кроме заблокированных в Украине.
Балансировка нагрузки между процессами OpenVPN
Архитектура OpenVPN однопоточная, поэтому один процесс демона OpenVPN использует только одно ядро процессора. Для лучшей утилизации всех ядер процессора, число процессов должно равняться количеству ядер на сервере. Балансировка между процессами выполняется с помощью модуля statistic, который случайном образом перенаправляет входящие подключения на разные внутренние порты.
Балансировка между серверами
Мы используем самый простой способ балансировки — с помощью множественных А-записей DNS. Все клиенты подключаются к серверу через доменное имя vpn.zaborona.help. Этот домен имеет шесть А-записей, которые направлены на все сервера. В итоге, в момент подключения, клиент выбирает случайный сервер из доступных. Так общее число подключений равномерно распределяется между всеми серверами. Конфигурация OpenVPN на всех серверах идентична, за исключением диапазонов IPv6-адресов, выдаваемых клиентам.
Панель управления DNS-записями. Балансировка с помощью множественых А-записей. Малое значение TTL позволяет быстро удалять адреса из общего списка.
Можно быстро посмотреть, на какие IP-адреса резолвится домен из разных точек планеты, с помощью сервиса host-tracker.com, выбрав любой из тестов, например http или ping.
Результат для домена vpn.zaborona.help: www.host-tracker.com/InstantCheck/ResultComplete/ec0e5a90-ed56-e711-b124-0003ff7328cc
Рекурсивные DNS-резолверы
Многие украинские провайдеры блокируют DNS-запросы к запрещенным доменам, перехватывая запросы в том числе и к сторонним DNS-серверам, вроде 8.8.8.8. Поэтому важно, чтобы клиенты посылали DNS-запросы через VPN тоннель, где их не сможет модифицировать провайдер.
Это не так просто сделать, потому что в новых версиях Windows запросы могут уходить ко всем DNS-серверам в системе, и будет использоваться тот, который ответит быстрее. DNS-сервер провайдера находится физически ближе к клиенту, поэтому, с большой вероятностью, система быстрее получит подмененный ответ провайдера, а не корректный ответ DNS внутри VPN, и сайт останется заблокирован.
Для решения этой проблемы ValdikSS написал патч для OpenVPN, блокирующий утечки DNS в Windows. Он использует Windows Filtering Platform — специальный слой файрволла Windows, позволяющий блокировать запросы к сторонним DNS, пока запущен OpenVPN.
Разворачивание сервера
В комментариях к предыдущей статье меня упрекали в том, что некоторые этапы, которые мне казались очевидными, не описаны. Здесь я опишу полный набор команд для разворачивания сервера забороны.
Конфиги максимально унифицированы и могут быть без изменений развернуты на сервере. Это удобно при использоватии инструментов автоматического деплоя, вроде Ansible.
Единственное уникальные данные для каждого сервера — подсеть IPv6, подписанная в конфигурационном файле OpenVPN.
На серверах используется Ubuntu 16.04 LTS с ядром 4.4.0.
Установка пакетов
В репозитории дистрибутива содержится устаревшая версия OpenVPN 2.3, поэтому добавляем официальные репозитории проекта с OpenVPN 2.4. Все остальные пакеты ставим из стандартной поставки.
wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg|apt-key add -
echo "deb http://build.openvpn.net/debian/openvpn/release/2.4 xenial main" > /etc/apt/sources.list.d/openvpn-aptrepo.list
apt update
apt upgrade
apt install openvpn dnsmasq ferm
Конфигурация OpenVPN
Так как все сервера настроены идентично, просто копируем конфиги вместе с файлами ключей и сертификатам в папку /etc/openvpn. Никакой генерации ключей/сертификатов не выполняется. Число процессов OpenVPN настраивает по числу ядер на сервере, в нашем случае 2. Каждый отдельный процесс имеет свой конфиг: zaborona1.conf и zaborona2.conf.
Чтобы избежать путаницы, я буду называть процессы OpenVPN демонами, но сути это несколько отдельных серверов, запущенных внутри одного VPS.
Список файлов в
/etc/openvpn/etc/openvpn/zaborona1.conf # конфиг первого демона
/etc/openvpn/zaborona2.conf # конфиг второго демона
/etc/openvpn/ccd/DEFAULT # файл с изменяемым на лету настройками для первого демона
/etc/openvpn/ccd2/DEFAULT # файл с изменяемым на лету настройками для второго демона
/etc/openvpn/logs # папка с логами
/etc/openvpn/ca.crt # корневой сертификат
/etc/openvpn/zaborona.help.crt # сертификат сервера
/etc/openvpn/zaborona.help.key # ключ сервера
/etc/openvpn/dh2048.pem # файл с Diffie-Hellman группами (необходим для шифрования)
Содержимое файлов:
mode server
# Несмотря на то, что протокол UDP быстрее, мы используем TCP для экономии трафика и аккумулятора мобильных уcтройств, так как в режиме UDP клиент вынужден чаще посылать keep-alive пакеты, чтобы поддерживать NAT-трансляцию на роутере или CGNAT.
proto tcp
# Тип инкапсуляции L3, то есть ip уровень. Нам не нужен L2 уровень.
dev-type tun
# Имя tun-интерфейса на сервере
dev zaborona1
# Раздавать клиенту адреса из общей /24, а не резать на подсети /30.
topology subnet
# Диапазон "серых" ipv4-адресов, выдаваемых клиентам.
server 192.168.224.0 255.255.252.0
# Диапазон реальных ipv6-адресов, выдаваемых клиентам. Уникален для каждого сервера.
server-ipv6 2a00:1838:32:200::/112
txqueuelen 250
keepalive 300 900
persist-tun
persist-key
cipher AES-128-CBC
ncp-ciphers AES-128-GCM
#user nobody
duplicate-cn
log logs/zaborona1.log
status logs/status1.log 30
# Путь к папке с конфигами пользователей. Эта опция позволяет назначить индивидуальные опции для каждого пользователя. Файл перечитывается заново при каждом подключении клиента, поэтому изменения можно выполнять без перезапуска сервера.
client-config-dir ccd
ca ca.crt
cert zaborona.help.crt
key zaborona.help.key
dh dh2048.pem
mode server
port 1195
proto tcp
dev-type tun
dev zaborona2
topology subnet
server 192.168.228.0 255.255.252.0
server-ipv6 2a00:1838:32:280::/112
txqueuelen 250
keepalive 300 900
persist-tun
persist-key
cipher AES-128-CBC
ncp-ciphers AES-128-GCM
#user nobody
duplicate-cn
log logs/zaborona2.log
status logs/status2.log 30
client-config-dir ccd2
ca ca.crt
cert zaborona.help.crt
key zaborona.help.key
dh dh2048.pem
push "dhcp-option DNS 192.168.224.1"
push "dhcp-option DNS 74.82.42.42" # HE.net DNS
push "route 74.82.42.42" # Route to HE.net DNS
push "route 77.88.8.8" # Route to Yandex DNS
push "dhcp-option DNS6 2001:4860:4860::8888" # Google IPv6 dns
push "route-ipv6 2001:4860:4860::8888"
push "dhcp-option DNS6 2001:4860:4860::8844" # Google IPv6 dns
push "route-ipv6 2001:4860:4860::8844"
#Persist TUN
push "persist-tun"
# Routes
# Yandex network
push "route 5.45.192.0 255.255.192.0"
push "route 5.255.192.0 255.255.192.0"
push "route 37.9.64.0 255.255.192.0"
push "route 37.140.128.0 255.255.192.0"
push "route 77.75.152.0 255.255.248.0"
push "route 77.88.0.0 255.255.192.0"
push "route 84.201.128.0 255.255.192.0"
push "route 87.250.224.0 255.255.224.0"
push "route 93.158.128.0 255.255.192.0"
push "route 95.108.128.0 255.255.128.0"
push "route 100.43.64.0 255.255.224.0"
push "route 109.235.160.0 255.255.248.0"
push "route 130.193.32.0 255.255.224.0"
push "route 141.8.128.0 255.255.192.0"
push "route 178.154.128.0 255.255.128.0"
push "route 185.32.185.0 255.255.255.0"
push "route 185.32.186.0 255.255.255.0"
push "route 185.71.76.0 255.255.252.0"
push "route 199.21.96.0 255.255.252.0"
push "route 199.36.240.0 255.255.252.0"
push "route 213.180.192.0 255.255.224.0"
push "route-ipv6 2001:678:384::/48"
push "route-ipv6 2620:10f:d000::/44"
push "route-ipv6 2a02:6b8::/32"
push "route-ipv6 2a02:5180::/32"
# Mail.ru network
push "route 5.61.16.0 255.255.248.0"
push "route 5.61.232.0 255.255.248.0"
push "route 79.137.157.0 255.255.255.0"
push "route 79.137.183.0 255.255.255.0"
push "route 94.100.176.0 255.255.240.0"
push "route 95.163.32.0 255.255.224.0"
push "route 95.163.248.0 255.255.248.0"
push "route 128.140.168.0 255.255.248.0"
push "route 178.22.88.0 255.255.248.0"
push "route 178.237.16.0 255.255.240.0"
push "route 185.5.136.0 255.255.252.0"
push "route 185.16.148.0 255.255.252.0"
push "route 185.16.244.0 255.255.252.0"
push "route 188.93.56.0 255.255.248.0"
push "route 194.186.63.0 255.255.255.0"
push "route 195.211.20.0 255.255.252.0"
push "route 195.211.128.0 255.255.252.0"
push "route 195.218.168.0 255.255.255.0"
push "route 208.87.92.0 255.255.252.0"
push "route 217.20.144.0 255.255.240.0"
push "route 217.69.128.0 255.255.240.0"
push "route 185.6.244.0 255.255.252.0"
push "route 185.30.176.0 255.255.252.0"
push "route 195.218.190.0 255.255.254.0"
push "route-ipv6 2a00:1148::/32"
push "route-ipv6 2a00:a300::/32"
push "route-ipv6 2a00:b4c0::/32"
push "route-ipv6 2a04:4b40::/29"
# VK.com network
push "route 87.240.128.0 255.255.192.0"
push "route 93.186.224.0 255.255.240.0"
push "route 95.142.192.0 255.255.240.0"
push "route 95.213.0.0 255.255.192.0"
push "route 185.29.130.0 255.255.255.0"
push "route 185.32.248.0 255.255.252.0"
# Kaspersky network
push "route 77.74.176.0 255.255.252.0"
push "route 77.74.181.0 255.255.255.0"
push "route 77.74.183.0 255.255.255.0"
push "route 93.159.228.0 255.255.252.0"
push "route 185.54.220.0 255.255.254.0"
push "route 185.85.12.0 255.255.255.0"
push "route 185.85.14.0 255.255.254.0"
push "route 77.74.176.0 255.255.248.0"
push "route 91.103.64.0 255.255.248.0"
push "route 93.159.224.0 255.255.248.0"
push "route-ipv6 2a03:2480::/33"
# DrWeb
push "route 178.248.232.183 255.255.255.255"
push "route 178.248.233.94 255.255.255.255"
push "route 195.88.252.0 255.255.254.0"push "dhcp-option DNS 192.168.228.1"
push "dhcp-option DNS 74.82.42.42" # HE.net DNS
push "route 74.82.42.42" # Route to HE.net DNS
push "route 77.88.8.8" # Route to Yandex DNS
push "dhcp-option DNS6 2001:4860:4860::8888" # Google ipv6 dns
push "route-ipv6 2001:4860:4860::8888"
push "dhcp-option DNS6 2001:4860:4860::8844" # Google ipv6 dns
push "route-ipv6 2001:4860:4860::8844"
#Persist TUN
push "persist-tun"
# Routes
# Yandex network
push "route 5.45.192.0 255.255.192.0"
push "route 5.255.192.0 255.255.192.0"
push "route 37.9.64.0 255.255.192.0"
push "route 37.140.128.0 255.255.192.0"
push "route 77.75.152.0 255.255.248.0"
push "route 77.88.0.0 255.255.192.0"
push "route 84.201.128.0 255.255.192.0"
push "route 87.250.224.0 255.255.224.0"
push "route 93.158.128.0 255.255.192.0"
push "route 95.108.128.0 255.255.128.0"
push "route 100.43.64.0 255.255.224.0"
push "route 109.235.160.0 255.255.248.0"
push "route 130.193.32.0 255.255.224.0"
push "route 141.8.128.0 255.255.192.0"
push "route 178.154.128.0 255.255.128.0"
push "route 185.32.185.0 255.255.255.0"
push "route 185.32.186.0 255.255.255.0"
push "route 185.71.76.0 255.255.252.0"
push "route 199.21.96.0 255.255.252.0"
push "route 199.36.240.0 255.255.252.0"
push "route 213.180.192.0 255.255.224.0"
push "route-ipv6 2001:678:384::/48"
push "route-ipv6 2620:10f:d000::/44"
push "route-ipv6 2a02:6b8::/32"
push "route-ipv6 2a02:5180::/32"
# Mail.ru network
push "route 5.61.16.0 255.255.248.0"
push "route 5.61.232.0 255.255.248.0"
push "route 79.137.157.0 255.255.255.0"
push "route 79.137.183.0 255.255.255.0"
push "route 94.100.176.0 255.255.240.0"
push "route 95.163.32.0 255.255.224.0"
push "route 95.163.248.0 255.255.248.0"
push "route 128.140.168.0 255.255.248.0"
push "route 178.22.88.0 255.255.248.0"
push "route 178.237.16.0 255.255.240.0"
push "route 185.5.136.0 255.255.252.0"
push "route 185.16.148.0 255.255.252.0"
push "route 185.16.244.0 255.255.252.0"
push "route 188.93.56.0 255.255.248.0"
push "route 194.186.63.0 255.255.255.0"
push "route 195.211.20.0 255.255.252.0"
push "route 195.211.128.0 255.255.252.0"
push "route 195.218.168.0 255.255.255.0"
push "route 208.87.92.0 255.255.252.0"
push "route 217.20.144.0 255.255.240.0"
push "route 217.69.128.0 255.255.240.0"
push "route 185.6.244.0 255.255.252.0"
push "route 185.30.176.0 255.255.252.0"
push "route 195.218.190.0 255.255.254.0"
push "route-ipv6 2a00:1148::/32"
push "route-ipv6 2a00:a300::/32"
push "route-ipv6 2a00:b4c0::/32"
push "route-ipv6 2a04:4b40::/29"
# VK.com network
push "route 87.240.128.0 255.255.192.0"
push "route 93.186.224.0 255.255.240.0"
push "route 95.142.192.0 255.255.240.0"
push "route 95.213.0.0 255.255.192.0"
push "route 185.29.130.0 255.255.255.0"
push "route 185.32.248.0 255.255.252.0"
# Kaspersky network
push "route 77.74.176.0 255.255.252.0"
push "route 77.74.181.0 255.255.255.0"
push "route 77.74.183.0 255.255.255.0"
push "route 93.159.228.0 255.255.252.0"
push "route 185.54.220.0 255.255.254.0"
push "route 185.85.12.0 255.255.255.0"
push "route 185.85.14.0 255.255.254.0"
push "route 77.74.176.0 255.255.248.0"
push "route 91.103.64.0 255.255.248.0"
push "route 93.159.224.0 255.255.248.0"
push "route-ipv6 2a03:2480::/33"
# DrWeb
push "route 178.248.232.183 255.255.255.255"
push "route 178.248.233.94 255.255.255.255"
push "route 195.88.252.0 255.255.254.0"
Конфиги разных демонов отличаются только номером порта для входящих соединений и диапазоном IP-адресов, выдаваемых клиентам.
Изменения настроек на лету с помощью client-config-dir
Первое время мы постоянно реадктировали список заблокированных сетей, из-за этого приходилось перезапускать демоны OpenVPN каждый раз при изменении конфигов. Из-за этого у клиентов разрывалось подключение к серверу.
Решением этой проблемы стала опция client-config-dir. Она используется для того, чтобы назначит индивидуальные настройки поименно каждому пользователю. Так как у нас все пользователи подключаются от имени одного клиента public, то файл один на всех <b>ccd/DEFAULT. Хитрость в том, что файл перечитывается заново при каждом подключении клиента и не требует перезапуска сервера для применения настроек.
В результате мы можем редактировать настройки сервера без отключения клиентов. и для преминения новых настроек пользователю достаточно переподключиться к серверу. Так как пользователи рано или поздно в любом случае перподключаются, новые настройки со временем применяются всем клиентам.
Ferm
Настройки фаерволла идентичны на всех серверах, поэтому копируем файл /etc/ferm/ferm.conf без изменений. По-умолчанию, после установки, пакет ferm сразу активирует стандартный набор правил в котором запрещены все соединения, кроме SSH на 22 порту. Так что если у вас SSH сервер находится на другом порту, будьте аккуратны, чтобы не заблокировать себя.
# Имена tun-интерфейсов из конфига OpenVPN. zaborona1, zaborona2 можно заменить на zaborona+.
@def $VPN = (
zaborona+
);
# Интерфейсы сервера, смотрящие в интернет
@def $WAN_4 = eth0;
@def $WAN_6 = eth0;
# Диапазоны "серых" адресов, выдаваемых клиентам
@def $VPN_ADDR_4 = (
192.168.224.0/22
192.168.228.0/22
);
@def $ALLOW_SSH = (
Список адресов, с которых разрешено подключение по SSH
);
@def $ALLOWED_NETWORKS_V4 = (
Список ipv4-сетей, заблокированных в Украине
);
@def $ALLOWED_NETWORKS_V6 = (
Список ipv6-сетей, заблокированных в Украине
);
table filter {
chain ZABORONA_V4 {
daddr $ALLOWED_NETWORKS_V4 ACCEPT;
}
chain FORWARD {
policy DROP;
mod conntrack ctstate INVALID DROP;
if $WAN_4 of $VPN mod conntrack ctstate (ESTABLISHED RELATED) ACCEPT;
if $VPN of $WAN_4 jump ZABORONA_V4;
}
chain INPUT {
saddr $ALLOW_SSH protocol tcp dport 22 ACCEPT;
protocol tcp dport 22 REJECT reject-with icmp-port-unreachable;
}
}
table nat {
chain POSTROUTING {
saddr $VPN_ADDR_4 of $WAN_4 MASQUERADE;
}
# Балансировка меджду демонами OpenVPN
chain PREROUTING {
interface $WAN_4 protocol tcp dport 1194 mod conntrack ctstate NEW mod statistic mode random probability 0.50000000000 REDIRECT to-ports 1195;
}
}
# IPv6:
domain ip6 {
table filter {
chain ZABORONA_V6 {
daddr $ALLOWED_NETWORKS_V6 ACCEPT;
}
chain FORWARD {
policy DROP;
mod conntrack ctstate INVALID DROP;
if $WAN_6 of $VPN mod conntrack ctstate (ESTABLISHED RELATED) ACCEPT;
if $VPN of $WAN_6 jump ZABORONA_V6;
}
}
}
Для сравнения, вот как выглядит тот же набор правил, полученный через iptables-save:
# Generated by iptables-save v1.6.0 on Fri Jun 23 19:44:10 2017
*filter
:INPUT ACCEPT [54622:15244109]
:FORWARD DROP [50:2520]
:OUTPUT ACCEPT [59291:85277655]
:ZABORONA_V4 - [0:0]
-A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -i eth0 -o zaborona+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i zaborona+ -o eth0 -j ZABORONA_V4
-A ZABORONA_V4 -d 87.240.128.0/18 -j ACCEPT
-A ZABORONA_V4 -d 93.186.224.0/20 -j ACCEPT
-A ZABORONA_V4 -d 95.142.192.0/20 -j ACCEPT
-A ZABORONA_V4 -d 95.213.0.0/18 -j ACCEPT
-A ZABORONA_V4 -d 185.29.130.0/24 -j ACCEPT
-A ZABORONA_V4 -d 185.32.248.0/22 -j ACCEPT
-A ZABORONA_V4 -d 5.45.192.0/18 -j ACCEPT
-A ZABORONA_V4 -d 5.255.192.0/18 -j ACCEPT
-A ZABORONA_V4 -d 37.9.64.0/18 -j ACCEPT
-A ZABORONA_V4 -d 37.140.128.0/18 -j ACCEPT
-A ZABORONA_V4 -d 77.75.152.0/21 -j ACCEPT
-A ZABORONA_V4 -d 77.88.0.0/18 -j ACCEPT
-A ZABORONA_V4 -d 84.201.128.0/18 -j ACCEPT
-A ZABORONA_V4 -d 87.250.224.0/19 -j ACCEPT
-A ZABORONA_V4 -d 93.158.128.0/18 -j ACCEPT
-A ZABORONA_V4 -d 95.108.128.0/17 -j ACCEPT
-A ZABORONA_V4 -d 100.43.64.0/19 -j ACCEPT
-A ZABORONA_V4 -d 109.235.160.0/21 -j ACCEPT
-A ZABORONA_V4 -d 130.193.32.0/19 -j ACCEPT
-A ZABORONA_V4 -d 141.8.128.0/18 -j ACCEPT
-A ZABORONA_V4 -d 178.154.128.0/17 -j ACCEPT
-A ZABORONA_V4 -d 185.32.185.0/24 -j ACCEPT
-A ZABORONA_V4 -d 185.32.186.0/24 -j ACCEPT
-A ZABORONA_V4 -d 185.71.76.0/22 -j ACCEPT
-A ZABORONA_V4 -d 199.21.96.0/22 -j ACCEPT
-A ZABORONA_V4 -d 199.36.240.0/22 -j ACCEPT
-A ZABORONA_V4 -d 213.180.192.0/19 -j ACCEPT
-A ZABORONA_V4 -d 5.61.16.0/21 -j ACCEPT
-A ZABORONA_V4 -d 5.61.232.0/21 -j ACCEPT
-A ZABORONA_V4 -d 79.137.157.0/24 -j ACCEPT
-A ZABORONA_V4 -d 79.137.183.0/24 -j ACCEPT
-A ZABORONA_V4 -d 94.100.176.0/20 -j ACCEPT
-A ZABORONA_V4 -d 95.163.32.0/19 -j ACCEPT
-A ZABORONA_V4 -d 95.163.248.0/21 -j ACCEPT
-A ZABORONA_V4 -d 128.140.168.0/21 -j ACCEPT
-A ZABORONA_V4 -d 178.22.88.0/21 -j ACCEPT
-A ZABORONA_V4 -d 178.237.16.0/20 -j ACCEPT
-A ZABORONA_V4 -d 185.5.136.0/22 -j ACCEPT
-A ZABORONA_V4 -d 185.16.148.0/22 -j ACCEPT
-A ZABORONA_V4 -d 185.16.244.0/22 -j ACCEPT
-A ZABORONA_V4 -d 188.93.56.0/21 -j ACCEPT
-A ZABORONA_V4 -d 194.186.63.0/24 -j ACCEPT
-A ZABORONA_V4 -d 195.211.20.0/22 -j ACCEPT
-A ZABORONA_V4 -d 195.218.168.0/24 -j ACCEPT
-A ZABORONA_V4 -d 217.20.144.0/20 -j ACCEPT
-A ZABORONA_V4 -d 217.69.128.0/20 -j ACCEPT
-A ZABORONA_V4 -d 195.211.128.0/22 -j ACCEPT
-A ZABORONA_V4 -d 208.87.92.0/22 -j ACCEPT
-A ZABORONA_V4 -d 77.74.176.0/22 -j ACCEPT
-A ZABORONA_V4 -d 77.74.181.0/24 -j ACCEPT
-A ZABORONA_V4 -d 77.74.183.0/24 -j ACCEPT
-A ZABORONA_V4 -d 93.159.228.0/22 -j ACCEPT
-A ZABORONA_V4 -d 185.54.220.0/23 -j ACCEPT
-A ZABORONA_V4 -d 185.85.12.0/24 -j ACCEPT
-A ZABORONA_V4 -d 185.85.14.0/23 -j ACCEPT
-A ZABORONA_V4 -d 77.74.176.0/21 -j ACCEPT
-A ZABORONA_V4 -d 91.103.64.0/21 -j ACCEPT
-A ZABORONA_V4 -d 93.159.224.0/21 -j ACCEPT
-A ZABORONA_V4 -d 8.8.8.8/32 -j ACCEPT
-A ZABORONA_V4 -d 8.8.4.4/32 -j ACCEPT
-A ZABORONA_V4 -d 74.82.42.42/32 -j ACCEPT
-A ZABORONA_V4 -d 77.75.152.0/21 -j ACCEPT
-A ZABORONA_V4 -d 185.71.72.0/21 -j ACCEPT
-A ZABORONA_V4 -d 185.6.244.0/22 -j ACCEPT
-A ZABORONA_V4 -d 185.30.176.0/22 -j ACCEPT
-A ZABORONA_V4 -d 195.218.190.0/23 -j ACCEPT
-A ZABORONA_V4 -d 195.88.252.0/23 -j ACCEPT
-A ZABORONA_V4 -d 178.248.232.183/32 -j ACCEPT
-A ZABORONA_V4 -d 178.248.233.94/32 -j ACCEPT
COMMIT
# Completed on Fri Jun 23 19:44:10 2017
# Generated by iptables-save v1.6.0 on Fri Jun 23 19:44:10 2017
*nat
:PREROUTING ACCEPT [917:61256]
:INPUT ACCEPT [430:26400]
:OUTPUT ACCEPT [122:8320]
:POSTROUTING ACCEPT [122:8320]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1194 -m conntrack --ctstate NEW -m statistic --mode random --probability 0.50000000000 -j REDIRECT --to-ports 1195
-A POSTROUTING -s 192.168.224.0/22 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.228.0/22 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Jun 23 19:44:10 2017
Балансировку между демонами выполняет это правило:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1194 -m conntrack --ctstate NEW -m statistic --mode random --probability 0.50000000000 -j REDIRECT --to-ports 1195
С 50% вероятностью подключения к порту 1194 перенаправляются на порт 1195. Так, подключения равномерно распределяются между двумя процессами OpenVPN. Если бы процессов было больше, нужно было бы добавить дополнительные правила на каждый процесс и изменить вероятность срабатывания каждого правила.
Кеширующий резолвер dnsmasq
По-умолчанию dnsmasq принимает запросы только с локального интерфейса 127.0.0.1, поэтому разрешаем запросы с адресов VPN клиентов и устанавливаем размер DNS-кеша.
/etc/dnsmasq.d/zaborona
listen-address=127.0.0.1,192.168.224.1,192.168.228.1
cache-size=1000
sysctl
Файл systctl.conf с настройками ядра. В нем включаем форвардинг IP-пакетов и другие опции для оптимизации системы под VPN сервер.
# Включаем форвардинг ipv4 и ipv6 пакетов
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.netfilter.nf_conntrack_max=65535
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 1800
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 60
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_rmem = 4096 262143 4194304
net.core.rmem_max = 4194304
net.core.rmem_default = 262143
net.ipv4.tcp_wmem = 4096 262143 4194304
net.core.wmem_max = 4194304
net.core.wmem_default = 262143
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 90
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_congestion_control=bbr
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.all.use_tempaddr = 2
Старт сервисов
После того, как все сервисы настроены, можно добавить их старт в автозагрузку.
Предварительно увеличиваем лимит на число открытых файловых дескрипторов для процессов OpenVPN, иначе при большом числе клиентов мы их превысим и получим ошибку Too many open files из-за большого числа открытых сокетов.
systemctl edit openvpn@.service
[Service]
LimitNOFILE=8192
# Перечитываем стартовые скрипты, чтобы изменения вступили в силу.
systemctl daemon-reload
# Добавляем в автозагрузку и сразу стартуем оба процесса OpenVPN.
systemctl enable --now openvpn@zaborona1
systemctl enable --now openvpn@zaborona2
# Перезапускаем сервисы dnsmasq и ferm. Они добавлены в автозагрузку по умолчанию после установки.
systemctl restart dnsmasq
systemctl restart ferm
Для проверки корректности настроек, можно перезагрузить сервер и убедиться что все сервисы запущены.
Сломанные ОС пользователей
У значительной доли пользователей оказались устаревшие, сломанные ОС. Очень часто в системе сломана поддержка IPv6, например во многих сборках Windows 7 «от Васяна с rutracker», где отключены автоматические обновления системы. Мы завели Wiki на Github, в которую пользователи самостоятельно могут добавлять инструкции. Там описаны решения некоторых распространенных проблем.
Вот наиболее типичные случаи кривого пользовательского окружения:
Windows XP
Несмотря на то, что поддержка этой OC закончилась ВОСЕМЬ лет назад, ее по-прежнему используют. На ней не работет много современных программ, веб-браузеры, а также последняя версия OpenVPN 2.4. Этой теме посвящена отдельная статья в нашей Wiki.
Windows 7
У многих пользователей отключены автоматические обновления Windows. Почему-то, в такой конфигурации на Windows 7 часто ломается IPv6. При подключении в логах OpenVPN появляется такая ошибка:
NETSH: C:\WINDOWS\system32\netsh.exe interface ipv6 set address interface=32 2a00:1838:30:7280::1149 store=active
ERROR: netsh command failed: returned error code 1
Причину этой аномалии не удалось выяснить. Зато у Microsoft есть специальная утилита на такой случай — IPv6 Re-enabler. Ссылка на скачивание внизу с подписью «Re-enable IPv6 on nontunnel interfaces and on IPv6 tunnel interfaces»
Android 4.4 и другие
Каждый вендор ломает VPN Framework в Android по-своему. Многие сборки Android имеют проблемы, которые не поддаются объяснению, например часто жалуются на то, что при подключенном VPN DNS запросы выполняются по несколько секунд. В Android 4.4 полностью сломан VPN.
Mikrotik
В RouterOS есть поддержка OpenVPN. К сожалению она чаще не работает, чем работает. Статья посвященная проблеме Mikrotik.
Мы отказались ломать наши сервера, чтобы сделать их совместимыми с багами Mikrotik, и предложили пользователям писать баг-репорты в компанию Miktorik. В результате было выпущено несколько исправлений в версии RouterOS 6.40rc24.
What's new in 6.40rc24 (2017-Jun-20 09:38):
*) ovpn - added support for topology subnet for IP mode;
*) ovpn - added support for "push-continuation";
*) ovpn - fixed duplicate default gateway presence when receiving extra routes;
Хотя по сообщениям пользователей, проблема так и не решена полностью. Советую всем заинтересованным лицам продолжить отправлять баг-репорты в Mikrotik до полного решения проблемы.
Комментарии (143)
robert_ayrapetyan
23.06.2017 20:01+1Аналогичная история с ДЦ в США. Можно найти приличный колокейшн и облака (Амазон, МС), все остальное — фуфло с завышенными ценниками (всякие «сервера у Джо» в каком-нибудь Канзасе, не то что с устаревшим интерфейсом, а просто номером телефона для связи). Подозреваю что на каком-то этапе AWS просто всех выкосил. Среднему бизнесу довольно тяжко (или может у меня просто задачи очень специфичные).
zhovner
23.06.2017 20:10+1Из всех зарубежных хостеров, мне очень нравится Linode. Они настоящие профессионалы, за несколько лет никаких проблем. Всегда компетентная поддержка и качественные услуги. К сожалению нет тарифов с безлимитным трафиком. Veesp.com тоже молодцы, цены ниже чем у Linode и DigitalOcean при сравнимом качестве.
robert_ayrapetyan
23.06.2017 20:53Linode и DigitalOcean — только виртуалки, т.е. про высокие нагрузки можно забыть. Ну и объема трафа там копейки — 10ТБ в месяц макс. За превышение — цена 20$\Тб, т.е. за скажем 30ТБ трафа в месяц (это 100 мбит\с 24\7) нода станет в $500.
У Veesp-а нижний ценник на дедик — $120, там сразу идет 16GB и мощный проц, т.е. брать их целесообразно только под виртуалки, опять же.zhovner
23.06.2017 21:20+1Linode и DigitalOcean — только виртуалки, т.е. про высокие нагрузки можно забыть.
У Linode есть виртуалки и за $1000 в месяц с 200GB RAM. Насчет трафика Вы правы. Но хочу заметить, что это качественные каналы и гарантированная полоса. Например, когда мы еще держали сервера в Европе, пользователи жаловались на сервер Scaleway у которого хоть и безлимитный трафик, но реальная ширина канала значительно ниже заявленой. Так что для продакшена я предпочту хостинг с ограниченной квотой трафика, но предсказуемым качеством сети.
У Veesp-а нижний ценник на дедик — $120
Я не знаю кому сегодня нужны bare metal сервера. Видимо тем, кому нравится переживать о ломающихся жестких дисках и писать в поддержку письма с просьбой поменять HDD на сервере. Я не спорю, что для некоторых задач выделенные сервера нужны, но на них обычно тоже ставят гипервизор и оперируют внутри виртуалками. Это проще и быстрее.robert_ayrapetyan
23.06.2017 23:26>Я не знаю кому сегодня нужны bare metal сервера
На самом деле много сегментов: игровые сервера, рекламные сети, в целом — везде где сетевая подсистема является узким местом. Из всех опробованных виртуальных сетевых интерфейсов (vmware, xen и пр.) ни один не дотягивал и до трети возможностей хорошей железки. Можно, конечно, взять три виртуальных сервера, вместо одной физической машины, но вот сейчас, например, у нас около 70 физических серверов (4 ядра\8Гиг оперативы, 30ТБ трафа на машину), по цене $75\мес. Аналог в DigitalOcean (4 ядра\8гиг\5Тб) стоит столько же. Умножаем на три, чтоб держать те же нагрузки. Получаем расход на хостинг 15К\мес (вместо текущих 5К на baremetal серверах). Т.е. отвечая на вопрос — bare metal сервера жизненно необходимы средним бизнесам, облака, к сожалению, подходят либо для очень мелких либо очень крупных бизнесов.
По поводу ломающихся дисков — не встречал конфигураций (кроме совсем запущенных случаев) с одним диском, а когда два диска в зеркале и мониторинг — то переживать не о чем.
Rathil
24.06.2017 02:37Смотрели на Носикс?
robert_ayrapetyan
24.06.2017 04:31Хм нет, не знаком. Судя по локации, они реселят S4U. На S4U мы жили первые три года, пока не осознали, насколько порезанные у них сети, причем как в VIP (ServerLoft) так и в бюджетном варианте.
Gasaraki
23.06.2017 20:31+1OVH в Канаде имеет ДЦ и продолжают расширяться. Цены там вполне приятные.
robert_ayrapetyan
23.06.2017 20:58OVH был бы идеальным провайдером дедиков — отличное Intel-овское железо (материнки и лучшие сетевые карточки из всех что встречал), сказочные цены, более-менее вменяемый суппорт. Но их идиотский фаервол просто говорит вам «Нет», если у вас нагрузки от 100мбит\с и много мелких пакетов. Были даже попытки кастомизации под нас, как под крупного клиента, но в итоге мы проиграли битву с их великим фаерволом и потеряли несколько важных клиентов.
Gasaraki
23.06.2017 23:57Скорее не фаервол, а антиддос. Мы в свое время из-за него туда ушли, но у нас просто сайт был (который ддосили неделями до этого и hetzner нам просто доступ к серваку вырубил из-за 6гбит ддоса).
Akuma
23.06.2017 20:28На самом деле при выборе хостера нужно отталкиваться от поставленных задач.
Вам нужен безлимтный трафик — а я никогда не превышал этот 1 Тб в месяц.
Виртуализацию выбирает 1 человек из 100 и то в лучшем случае. Остальные просто не знают между ними разницу, да оно им и не нужно.
Не рекламы ради, но мне например нравится Vscale. Все шустро, дешево. Меня устраивает. И, да, я понятия не имею чем там делается виртуализация, хотя при выборе тафира кажется было написано.
Это что касается фразы «99% хостеров фуфло». Они просто не под ваши задачи, т.к. таких как вы менее 1% от общей массы клиентов.
P.S. Я не защищаю перечисленных 1Gb, Mh, reg.ru и прочую нечисть. Они совсем другая история.zhovner
23.06.2017 20:35Отчасти согласен. В статье описаны именно наши требования под VPN сервера. Мне кажется странным, когда в целой стране отсутствует хостинг под эту задачу, тем более что она вполне стандартная. Особенно раздражают ситуации, когда нужно пройти десять экранов заказа сервера и идти в отдельную панель чтобы включить его после покупки.
В reg.ru, кстати, раздражает, что после покупки сервера в почтовом ящике оказывается десять писем вроде «Вы успешно заказали сервер, вы успешно оплатили, сервер успешно загрузился, все хорошо, сервер работает, поздравляем все хорошо»
zhovner
23.06.2017 20:37Vscale нам тоже советовали. Возможно он вполне хороший. Есть информация о том, как у них с IPv6?
salsaly4
23.06.2017 21:20Пока вообще никак.
Я бы еще на servers.com посмотрелzhovner
23.06.2017 21:24Можем спросить об этом amarao
amarao
24.06.2017 12:59+1IPv6 мы делаем по запросу, в основном в приватных регионах. Выкатывание в паблик осложняется уязвимостью в openstack, позволяющей одному тенанту подделать RA для другого тенанта.
https://bugs.launchpad.net/bugs/1685237
Ждём фикса.
rushter
23.06.2017 20:44+3ISPmanager действительно не очень удобная панель, вспоминаю как мучался с ней лет 7 назад, когда она была на пике популярности. Странно, что нормальных аналогов до сих пор никто не придумал.
iborzenkov
23.06.2017 23:12-1Нормальный аналог уже есть — ssh и конфиги а также ansible
Тут ситуация как с говнофорумами на php — те кто знают как сделать нормально им не нужноrushter
23.06.2017 23:16+2Я имел в виду не только ISP, но и сам биллинг. А рядовому пользователю, чтобы добавить какой-нибудь сайт на php, знать ssh думаю не обязательно.
lolipop
23.06.2017 20:52У veesp в описании storage-виртуалок речь идёт об ограничении в 100мбит. Неужели все эти 20 тысяч клиентов, даже поделенные на 6 серверов, умещаются в 100(600) Мбит? И локальный трафик внутри виртуалок тоже на 100Мбит-скорости?
zhovner
23.06.2017 21:38Неужели все эти 20 тысяч клиентов, даже поделенные на 6 серверов, умещаются в 100(600) Мбит?
Число одновременных подкючений в пиковые часы примерно 6 тысяч, то есть по тысяче на каждый сервер. Мы не пускаем через себя весь трафик, а только к заблокированным сетям, так что хватает. Не смотря на то, что днем каналы нагружены почти полностью, пользователи не жалуются на скорость. Вот как это выглядит на одном сервере:
Evengard
23.06.2017 20:54А почему вы искали хостинг именно в России? Не лучший вариант для обхода блокировок — в России свои собственные блокировки — эдак получается из огня да в полымя. Я бы скорее смотрел на такие страны, как Германия, Нидерланды. Правда, в Европе есть другая проблема… Найти безлимитный трафик с нормальной скоростью по-моему невозможно. Знает ли кто-нибудь подобный хостинг в европейских странах, при этом с безлимитным трафиком, всеми требованиями перечисленными здесь, и достаточно либеральным отношением к не всегда лицензионно чистым торрентам?
zhovner
23.06.2017 21:02+3Потому что для европейских IP-адресов заблокирована Яндекс.Музыка и значительная часть музыки в VK. Это написано в статье. Наш сервис позволяет обойти именно блокировки в Украине. Так что сервера в России для этого отлично подходят. Мы маршрутизируем через себя только заблокированные сети, весь остальной трафик идет напрямую через основной интернет пользователя. Так что блокировки в РФ нас никак не затрагивают.
AlexanderY
23.06.2017 21:29Scaleway оказался очень даже неплохим хостером с безлимитом и хорошей скоростью. Да, по железу там Atom'ы, но нам зашло, например. Ничего не могу сказать насчет IPv6, но ТС пишет, что использовали в том числе Scaleway, так что должно быть всё в порядке.
zhovner
23.06.2017 21:34Scaleway на тарифе «Starter Cloud» за €2.99 начинал тормозить уже при 100 одновременных подключениях. Полагаю что это из-за слабого процессора и медленной памяти. IPv6 они не умеют нормально, выдают 1 адрес на сервер. При заявленных 200Mbit/s скорость не поднималась выше 100Mbit/s. Так что мы быстро от них отказались.
AlexanderY
23.06.2017 21:40Вероятно, тормоза связаны с ARM-процессором. Про пропускную способность ничего сказать не могу. Мы пробовали только C2S тариф за €11.99, и скорость соответствует заявленной. В общем, я ничего не могу сказать про десятки хостеров, но после пары российских и одного Digital Ocean, Scaleway мне лично показался очень годным.
zhovner
23.06.2017 21:42Вероятно, тормоза связаны с ARM-процессором.
У нас был x86 Atom в Париже.AlexanderY
23.06.2017 21:48А, прошу прощения. Я почему-то думал, что за 2.99 там только ARM, но ошибся. Может как-то связано именно с тем, что у вас виртуалка. Может и нет. У нас «baremetal cloud server». В Амстердаме, кстати. В любом случае, спасибо за исследование и статью.
olku
23.06.2017 20:59+1Пятничный торт. Все больше режимов блокируют доступ к информации, заставляя компании цензурировать сетевой контент в том или ином виде. Ваш сервис решил проблему в Украине и обрел другой веер блокировок уже на территории РФ. Заставляет задуматься о недалеком будущем и глобальной сети VPN в разных юрисдикциях. Эдакий uncensored оверлей поверх Internet.
zhovner
23.06.2017 21:09+1Мы маршрутизируем через наши сервера только трафик к заблокированным сайтам. Блокировки в РФ нас не касаются https://habrahabr.ru/post/331178/#comment_10280266
olku
23.06.2017 21:25Хорошо! А то в новостях пишут, что парламент РФ уже запретил «средства для обхода заблокированных ресурсов»
holomen
26.06.2017 02:45парламент РФ уже запретил «средства для обхода заблокированных (на территории РФ) ресурсов»
Я про юрисдикции. Очевидно что на украинские блокировки плевать.
gudvinr
23.06.2017 21:23А можно выдавать клиентам OpenVPN адреса не из подсети, а из определённого списка адресов?
Пользуюсь как раз таким провайдером, который раздаёт пулы из 32 адресов на одну виртуалку. Может дело в OpenVZ, но это не особо важно, так как одновременно всё равно не более одного-двух устройств подключено.
ValdikSS
23.06.2017 21:54+1Можно, с костылями. Клиентам 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 разрешают ее.
zein
23.06.2017 21:39-3хм, а блокировками на родине вы так же обеспокоены? zapret.help что-то не вижу
zhovner
23.06.2017 21:41+4Моя родина — Украина. Живу я при этом в Израиле. Для обхода блокировок в РФ есть аналогичный сервис https://antizapret.prostovpn.org/
alek0585
23.06.2017 22:01Хостинг jino не рассматривали?
zhovner
23.06.2017 22:12+1Что это значит? На тарифе за 99? нет-IP адреса? Не понимаю
alek0585
23.06.2017 22:27Так рассматривали или нет? Или у вас бюджет 100 рублей и рассмотреть не получилось?
zhovner
23.06.2017 23:33Вы сотрудник jino.ru? Я не понял несколько моментов. Что такое общий IP? Мне дадут какой-то порт на этом общем IP или что это значит?
При создании виртуального сервера ему бесплатно назначается IP-адрес, разделяемый с другими пользователями. На тарифах «Бета» и «Гамма» дополнительно можно приобрести до 3-х выделенных IP на каждую виртуальную машину. Стоимость каждого дополнительного адреса — всего 89 ? в месяц. А если в выделенном IP нет необходимости, вы экономите, не покупая его.
Нет информации о скорости сети на VPS и глупое требование к соотношению трафика:
На «Джино» нет ограничений по общему объему передаваемого трафика, но есть ограничение по его соотношению: объем входящего трафика не должен превышать 1/4 от объема исходящего. Стоимость превышения входящего трафика составляет 38 руб. за 1 Гб (полный или неполный).
То есть я могу выровнять вручную чтобы не платить лишнего?alek0585
23.06.2017 23:41-3Нет, конечно, никакой я не сотрудник. Мне интересно, смотрели или нет, так как сам им пользуюсь, но по мелочам. Общий IP — чесслово хз. Наверное один IP ведет на несколько VPS.
Нет информации о скорости сети на VPS
Наверное, сколько получится, я не замерял, но сайт быстро грузится.
То есть я могу выровнять вручную чтобы не платить лишнего?
Получается что так, хотя я бы ждал тут подвох 100%.
astono0
23.06.2017 22:13Использую Ваш сервис уже пару недель, очень нравится
Недавно и девушке поставили вместо того, что стоял у нее.
Только через Ваши сервера почему-то все сайты грузятся с огромной задержкой.Приходится его отключать после того, как попользовался вк, что весьма неудобно.
У меня таких проблем нету. Сам по себе у нее телефон новый, шустрый. Мой уже старенький, но с рутом.
Не знаете, в чем может быть проблема?zhovner
23.06.2017 22:16Вы не указали какая операционная система на устройстве. Полагаю, что это Android. Я как раз в статье описал эту проблему. Похоже на лаг в DNS резолве, то есть на преобразование доменного имени в IP-адрес уходит много времени, до нескольких секунд. И только тогда сайт начинает загружаться. Мне удаленно не удалось выяснить причину этой задержки. Возможно кто-то опытный, у кого есть устройство с таком проблемой, сможет выяснить в чем причина и описать решение в нашей wiki.
Uirandir
23.06.2017 22:38+1А какова монетизация проекта? Вижу, что вы предлагаете сразу скачать ovpn-файл, без регистраций и прочего. На чем проект зарабатывает? Кто оплачивает работу админов? Кто оплачивает пусть и 30 долларов за сервера?
Когда вижу подобные проекты сразу встает вопрос о том как же монетизируется. Не верю, что с кнопки доната вы хотя бы на час работы админа набрали за время работы проекта.alek0585
23.06.2017 22:41Час админа — можно и самому поработать.
С кнопки доната вполне можно наскрести на сервер. Если некоторые и жмотятся, то я уверен, что есть и те, кто донатит…Uirandir
23.06.2017 22:49-2Ну там, положим, часов 12-16(так, навскидку) работы было, плюс мониторинг надо настроить и прочее, плюс бэкапы, плюс резервирование, плюс хотя бы раз в месяц все надо контролировать глазами. Набегает часов эдак 30-40 изначально(у меня низкая ставка, я беру $40 за час работы, но все равно это 1200-1600 долларов USA будет), плюс ежемесячное обслуживание, плюс проверка валидности бэкапов. Не верю я в энтузиаста, который ради доступа к быдлоклассникам и прочему российскому мусору станет так тратиться.
Потому и интересуюсь монетизацией.
Как-то же это должно хотя бы в ноль выходить, а лучше прибыль человеку приносить.
zhovner
23.06.2017 22:50+7Кто оплачивает пусть и 30 долларов за сервера?
Сервера первое время оплачивал я, сейчас нам бесплатно дают сервера Veesp.com за что им больше спасибо.
Кто оплачивает работу админов?
Администрирование сервиса не занимает много времени, достаточно все настроить один раз. Мне много помогает советами ValdikSS когда я чего-то не понимаю. Он большой специалист по OpenVPN.
Когда вижу подобные проекты сразу встает вопрос о том как же монетизируется. Не верю, что с кнопки доната вы хотя бы на час работы админа набрали за время работы проекта.
Меня слабо мотивируют деньги, намного веселее угореть по хардкору сражаясь против цензуры в масштабах целого государства. Row Row Fight the Power! Еще меня завораживает осознание того, что десятки тысяч человек пользуются моей поделкой и она приносит им пользу. Этот кайф для меня гораздо ценнее денег.
Кстати насчет доната вы ошибаетесь. Нам задонатили больше 20 тысяч рублей. Это многократно превышает мои затраты. Так что люди способны организовываться вокруг справедливых и благородных идей.Uirandir
23.06.2017 22:54-20> сейчас нам бесплатно дают сервера Veesp.com за что им больше спасибо.
То есть что бы обойти блокировку пропагандистких ресурсов страны-агрессора вы берете деньги у страны агрессора?
Тогда вопросов больше нет. Мне все ясно с проектом и его монетизацией. Извините, что потревожил.zhovner
23.06.2017 23:20+11То есть что бы обойти блокировку пропагандистких ресурсов страны-агрессора вы берете деньги у страны агрессора?
Мне не интересен политический срач. Я воспринимаю модель государства так же как крупную международную компанию, которая торгует с другими компаниями (государствами). У нее есть много отраслей деятельности и есть руководство. Эффективность компании я могу оценивать только по результатам ее работы и по условиям труда (уровню жизни) для ее сотрудников. Я не отождествляю себя с директором этой компании. Если компания работает плохо, я пойду работать в другое место. Я не понимаю что значит патриотизм, мне безразличны другие люди кроме моих друзей и родни.
Можно упростить это до такого примера. Представьте вы живете районе, который обслуживает управляющая компания. Она занимается вывозом мусора, обслуживанием отопления, чинит протечки крыши, заинмается уборкой подъездов и так далее. В соседнем квартале есть такой же район и им управляет другая компания. Оказывается что за те же деньги, которые вы платите за комунальные услуги, в соседнем районе управляющая компания еще и сажает цветы в клумбах, делает ремонт в подъездах. При этом крыша там не протекает, отопление не отключают, в повдвалах нет бомжей и никто не ссыт в подъездах. Когда вы задаете вопрос руководству своей управляющей компании, почему же у нас хуже чем у них, вам говорят, что в том районе вообще геи живут, они все плохие и тупые, а в нашем квартале особый народ живет! У нас есть духовность а у них нет, поэтому не обращайте внимание не протекающую крышу, ведь у нас особый путь.Uirandir
23.06.2017 23:24-9Я — минархист и мой подход к государству такой же.
Но в данном случае речь идет о том, что были заблокированы пропагандитские ресурсы на которых пишут о том, что украинцев нужно убивать за то что они украинцы и что война ведущаяся путинской бандой справедливая. А потому если человек берет деньги у путинской хунты на обход таких блокировок, то с его проектом все ясно и больше я у него ничего спрашивать не буду. Этот человек работает за мой счет(я — гражданин и резидент РФ) и когда-нибудь мы заберем у него то, что ему незаконно выдали люди, которые возомнили себя хозяевами РФ.
dartraiden
23.06.2017 23:45+3Я один не понимаю, о какой хунте идёт речь?
Деньги жертвуют сами жители Украины, которые пользуются сервисом. Облачные мощности жертвует хостер, он тоже вряд ли является хунтой.
От государства zhovner не получил ни копейки.alek0585
24.06.2017 00:05Он ж на окладе у ФСБ, сам только вот признался. Uirandir его раскрыл.
zhovner
24.06.2017 00:11Едет пативэн, веселья полон фургон. Зря запускал VPN, ты уже под колпаком...
(картинка кликабельна)ValdikSS
24.06.2017 00:08Вконтакте является социальной сетью, тексты, картинки, документы и музыку в нее загружают пользователи. Пропагандистские тексты, как и любые другие, пишут люди, а не администрация сайта.
User Generated Content, слышали о таком?
Massacre
24.06.2017 01:30А я, как гражданин и резидент Украины считаю, что за интернет-цензуру надо карать в аналогах Гаагского трибунала, а обходить её — дело благородное. Так что всё правильно делает. И антизапрет тоже правильно делает.
avost
24.06.2017 12:01+1заблокированы пропагандитские ресурсы на которых пишут о том, что украинцев нужно убивать
На яндекс.музыке вам поют, что украинцев надо убивать? На почту мейлру вам пишут, что украинцев надо убивать?
А зачем вы слушаете именно эти песни? И зачем переписываетесь в почте именно с этими людьми? Даже если вы читаете всю эту муть на фконтактике, то тот же вопрос — зачем??? Может надо не я.музыку блокировать, а в консерватории что-то поменять? Не, такой вариант не приходит в голову?
и когда-нибудь мы заберем у него то
Отобрать и поделить? Здравствуйте, Полиграф Полиграфович Шариков? Или ваша фамилия — Швондер?
robert_ayrapetyan
23.06.2017 23:36-1Скорее, есть одна очень крупная (глобальная) корпорация, и она раздроблена на много более мелких компаний (государств), и когда топ-менеджеры этих небольших (по значимости и потенциалу) филиалов начинают вые..., им жестко показывают их реальное место в иерархии.
alek0585
23.06.2017 22:57-5Признавайтесь, сколько недель вы тратите ежедневно на этот проект? Сколько бекапов зарезервировали уже, как часто проверяете глазами, а не другими органами?
zhovner
23.06.2017 23:42Все бекапы у нас это десяток текстовых файлов. Они доступны на Github https://github.com/zhovner/zaborona_help
Развертывание нового сервера, при использовании интрументов вроде ansible, занимает несколько секунд.
Больше всего времени я трачу на поддержку пользователей и ответы на письма/комментарии. Но я делаю это только в свободное время и когда у меня есть настроение.
mavriq
23.06.2017 23:55из-за этого приходилось перезапускать демоны OpenVPN…
и для преминения новых настроек пользователю достаточно переподключиться к серверупредлагаю посмотреть в сторону параметра
management 127.3.2.1 7654
это позволит
telnet-ом подключаться к соответствующемуIP:портуи командойkill cnлибоkill IP:portубивать подключение пользователя. в этом случае правильно настроенный клиент (должно хватитьpersist-tunв конфиге) сам автоматически переподключится
маленькая, а радость от применения настроек на лету, есть.
zhovner
23.06.2017 23:57В любом случае приходится отключать клиентов. По опыту замечено, что из тысячи клиентов, десяток не переподключается нормально и начинает писать что у них проблемы. Многие держут VPN на роутерах где OpenVPN едва работает.
Sho0ter
23.06.2017 23:55По поводу DNS-резолва: проблема не только на Android. На 3х ПК с Windows 10 резолв стабильно идет несколько секунд и это очень разражает, на Linux такого нет.
В целом за сервис огромное спасибо :)
mavriq
23.06.2017 23:56извините за нескромный вопрос — а вы не рассматривали мысль о том, что с IP вашего сервера будут всячески провоцировать и разжигать, а шишки могут посыпаться на вашу голову?
zhovner
24.06.2017 00:02Такой риск конечно есть. Не хочется садиться на бутылку вместе с Дмитрием Богатовым. Но надеюсь что обойдется. Тем более, что VK недавно убрал IPv6 записи со всех своих доменов (по слухам из-за того, что не смог побороть спам из IPv6 сетей) и идентифицировать конкретного пользователя не получится, потому что все ходят с одного ipv4 адреса.
mavriq
24.06.2017 00:32кстати, с другой стороны — у вас приватный ключ в открытом доступе и один для всех клиентов.
компетентным админам в штатском любой страны (да просто любопытным хацкерам с прямыми руками) не составит труда «подсмотреть трафик»
Если вы не позиционируете свой сервис как анонимайзер (а насколько я вижу, так и есть) вы можете всю ответственность спихнуть в их адрес, мол «вы весь трафик пишете? вот вы и разбирайтесь, где ключи взять вы знаете»
Так что шанс стать гостем казенного дома в РФ, кмк, не велик (зачем подымать шум там, где можно тихо слушать)
Есть, правда, шанс, что на каком-нибудь ентер-ТВ из вас нарисуют злостного агента Кремляzhovner
24.06.2017 00:39+2Приватный ключ сервера у нас не в открытом доступе, без него расшифровать трафик нельзя. В публичном доступе у нас только приватный ключ клиента, который используется для аутентификации пользователя. В конфигурационном файле зашит корневой сертификат (ca), по которому клиент может проверить подлинность сервера, и если его будут MiTM-ить, то не подключится.
Кроме того, все сайты работают по HTTPS, так что даже если бы шифрование VPN было отключено, не было бы никакой разницы на канальном уровне.zhovner
24.06.2017 00:55+1Вот более развернутый ответ на этот же вопрос https://www.reddit.com/r/VPN/comments/2jzatj/frootvpn/clhibvw/
alek0585
24.06.2017 00:35Ну вы уже спланировали что будете делать в случае опасности?
И еще такой вопрос… Нет ли какого-нибудь древнего закона который запрещает всяким лодочникам использовать герб страны на сайте? Наверняка есть какое-то достопочтимое предписание. Как у нас с развешиванием флагов на своих ворота.zhovner
24.06.2017 00:54Ну вы уже спланировали что будете делать в случае опасности?
Я уже обезопасился, не переживайте.
Знаю только закон про гербовые печати и оскорбление флага.
w_boba
24.06.2017 00:21+1Вот вы использовали Ferm для генерации сотен идентичных правил для iptables на 3 интерфейса.
Была какая-то специфическая причина не использовать модуль ipset и обойтись всего тремя правилами (по одному на интерфейс)?
У меня например через cron/bash скрипт автоматически обновляется черный список на серверах. Очень удобно и всего одно правило. Там даже не сохраняется конфигурация iptables, просто заполняется ipset при перезагрузке.ValdikSS
24.06.2017 01:03+1Для большого списка адресов оправданно использовать ipset, я с вами полностью согласен, но у zhovner их 69, а не сотни. Заметного ускорения от использования ipset в этом случае нет, а проблемы появляются: нужно будет писать отдельные скрипты, чтобы таблицы ipset создавались до применения правил файрволла, иначе модуль ipset для iptables будет выдавать ошибку и не применять правила при загрузке, писать скрипты для работы с ipset и обновления.
Считаю, что конкретно в этом случае выигрывает удобство, а не максимальная корректность с технической точки зрения.
artsavel
24.06.2017 00:26Немного непонял, как клиент определяет к какому демону подключаться? На стандартный порт или дополнительный
zhovner
24.06.2017 00:32Это скорее делает операционная система возвращая программе один из IP-адресов полученных в DNS ответе. Такая балансировка сделана у многих сервисов, например домен google.com имеет очень много А-записей. Попробуйте несколько раз выполнить ping google.com и скорее всего увидите каждый раз разный IP адрес.
zhovner
24.06.2017 01:05Прошу прощения, неправильно понял ваш вопрос. Iptables редиректит подключения к 1194 порту на другие.
bacalastein
24.06.2017 00:56если вы используете балансировку нагрузки через DNS, то как вы боритесь с отказами? в случае фейла одного из серверов, DNS по-прежнему будет резолвить на него запросы, если только нет health check'а, как в AWS Route 53 или других аналогов.
zhovner
24.06.2017 00:58К сожалению никак. Только вручную удалять сервер из DNS. Для этого ставим минимальный TTL 2 минуты.
Проблема еще в том, что при разрыве подключения клиент OpenVPN по умолчанию не резолвит адрес к которому был изначально подключен. Поэтому в случае отказа приходится просить пользователей либо перезапустить OpenVPN и очистить DNS кеш, либо вообще перезагружаться.vmspike
24.06.2017 11:09Ещё можно посмотреть в сторону
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 ...silverjoe
24.06.2017 14:16Советую для решения этого посмотреть gdnsd — очень простой и вкусный
https://github.com/gdnsd/gdnsd/wiki/GdnsdConfig
Wagner
26.06.2017 22:42По проблеме обрыва.
Он не то чтобы не резолвит. Вы пушите клиенту persist-tun и это означает, что клиент при обрыве не должен рестартить туннель и не должен перечитывать файл конфига. Если убрать эту опцию для клиента то он будет успешно отваливаться вслед за сервером. А если сказать клиенту ping-restart то он ещё и подниматься сам будет. Бонусом можно ещё resolv-retry чтобы точно очухался.ValdikSS
26.06.2017 23:16keepaliveявляется макросом над командамиpingиping-restart:
Он используется на zaborona.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
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 оказывались заблокированными. У меня проблема не проявляется нигде, и люди, у которых она проявлялась, не написали мне на почту и не создали баги в багтрекере. Так что решено было эту опцию пушить с сервера.Wagner
26.06.2017 23:55keepalive я не заметил.
На виндовом OpenVPN 2.4 (или в виндовом TAP адаптере который идёт «в комплекте» или в виндовом сервисе самого OpenVPN либо вообще в комбинации всего этого) похоже что-то сильно намудрили вообще с кешем.
Конкретно я видел проблемы с ARP кешем когда уже после поднятия туннеля траф не маршрутизируется с ошибкой no route to host или что-то в этом духе. ARP кэш TAP адаптера при этом невозможно было удалить (invalid) до перезагрузки либо с помощью ручного disable-enable TAP интерфейса. Это проявлялось когда IP выдаётся новый на каждое новое подключение.
На 2.3 такого не замечал.
sumanai
24.06.2017 01:30+1Несмотря на то, что поддержка этой OC закончилась ВОСЕМЬ лет назад, ее по-прежнему используют.
Замечу, что восемь лет назад закончилась только основная поддержка, расширенная закончилась только в 2014 году, а поддержка версии PosReady продолжается до сих пор. Да и без нарушения лицензии не так давно прилетели патчи от WannaCry и других эксплоитов АНБ, так что XP живее всех живых.
lorc
24.06.2017 01:34Насколько я помню, фатальный недостаток поддержки OpenVPN в RouterOS так и не починили, и он до сих пор работает только через TCP.
nazarpc
24.06.2017 02:14Как на счёт этого бага: https://github.com/OpenVPN/tap-windows6/issues/9
Есть машинки с Windows 8.1/10 и актуальными обновлениями — на одних работает, на других нет.zhovner
24.06.2017 02:50Не сталкивался с этой ошибкой. Чаще всего либо TAP адаптер занят, либо отсутствует.
vmspike
24.06.2017 10:33Чтобы не хранить маршруты и другие общие настройки в двух (или более) разных файлах, вероятно удобнее будет использовать опцию в клиентских конфигах (ну или в DEFAULT):
config /some/path/to/shared-ccd-config
Так одинаковые настройки для всех серверов и клиентов будут в одном файле.
SerhiyRomanov
24.06.2017 12:09Пользуясь случаем хочу сказать спасибо за этот сервис!
Есть ли в планах поддержка протоколов PPTP/L2TP или IPSec (нужны для подключения к Zaborona.Help через роутеры Tp-Link серии WR-xxx без изменения прошивки на OpenWRT)?zhovner
24.06.2017 15:32+1Есть такие мысли, но с ipsec/ikev2 у меня не получилось реализовать ту же задачу. Например встроенный клиент ikev2 в Windows не принимает больше 25 маршрутов. У других протоколов тоже хватает проблем.
Jimm54
24.06.2017 23:26Большое спасибо за такой шикарный сервис!
Можно немного подробнее о проблемах других протоколов? Например PPTP и раздача маршрутов с помощью isc-dhcp-server. Знаю что dnsmasq не умеет отдавать очень много статических маршрутов, кажется более 28. PPTP есть везде, тем и интересен.
Ещё раз спасибо.
ViperRU
24.06.2017 23:20+1Что бы процессы openvpn не скакали между разными процессорами, стоит каждый «прибить» к процессору. В моём случае это увеличивало производительность процентов на 20.
Что бы клиенту не перегружать сервис openvpn, если текущий сервер стал не доступен, можно вместо шести A-записей в FQDN в опции remote, использовать шесть опций remote с FQDN с одной A-записью и опцией --remote-random (или три опции remote с FQDN с двумя А записями или три).
Точно так же добавлением доп. опций remote можно разруливать у клиента случайный выбор конкретного демона (порта), не нагружая ведением статистики iptables, хотя, возможно, эта нагрузка мизерна.zhovner
25.06.2017 00:37Что бы процессы openvpn не скакали между разными процессорами, стоит каждый «прибить» к процессору. В моём случае это увеличивало производительность процентов на 20.
Спасибо, попробую. Не знал об этом.
Что бы клиенту не перегружать сервис openvpn, если текущий сервер стал не доступен, можно вместо шести A-записей в FQDN в опции remote, использовать шесть опций remote с FQDN с одной A-записью и опцией --remote-random (или три опции remote с FQDN с двумя А записями или три).
Мы заранее не знали какое будет точно количество серверов в итоге, поэтому не стали так делать. Как в таком случае исключать домен из списка? Как поведет себя клиент если один из доменов в списке будет без A-записи? Старые клиенты тоже поддерживают это?ViperRU
25.06.2017 12:00+1Возможно, стоит убрать и шифрование, зачем нагружать свои сервера, судя по тому, для чего служит ваш проект, шифровать трафик не зачем, шифровать трафик клиента будет сам клиент и тот ресурс к которому вы предоставляете доступ (TLS). Если конечный ресурс считает, что трафик шифровать не зачем, то зачем вам его шифровать?
Ещё, я бы использовал UDP протокол для OpenVPN, а все фишки TCP (целостность, упорядочивание, подтверждение и т.д.) возложил бы на клиента и конечный ресурс.
Мы заранее не знали какое будет точно количество серверов в итоге… Как в таком случае исключать домен из списка?
Как вариант сделать две записи remote в каждой по 3 FQDN, а на стороне сервера включать/исключать сервера, плюс две записи с другим портом с теми же FQDN. Кроме того. никто не мешает делать повторяющиеся IP, в разных FQDN, главное распределить так, что бы равная вероятность подключения была.
Как поведет себя клиент если один из доменов в списке будет без A-записи?
Именно такой кейс не тестировал, но думаю, не удалось подключиться, переходит к следующей случайной опции remote.
Старые клиенты тоже поддерживают это?
На сколько помню, как я начал использовать openvpn для своих целей с 2004 года, с тех пор эта опция и работает.zhovner
25.06.2017 16:39+1Возможно, стоит убрать и шифрование, зачем нагружать свои сервера, судя по тому, для чего служит ваш проект, шифровать трафик не зачем, шифровать трафик клиента будет сам клиент и тот ресурс к которому вы предоставляете доступ (TLS). Если конечный ресурс считает, что трафик шифровать не зачем, то зачем вам его шифровать?
Это хороший вопрос, я тоже думал об этом. Но тут есть несколько факторов: многие провайдеры сейчас блокируют по DNS, при этом перехватывая запросы к любым DNS серверам. Вполне возможно что потом они, как и провайдеры в России, начнут использовать системы DPI и будут ловить подключения к запрещенным сайтам по SSL SNI, матчить HTTP заголовки и так далее. Если так случится, придется все перенастраивать и заставлять клиентов скачивать новый конфиг. Я бы использовал вместо шифрования какой-нибудь режим обфусцирования типа XOR, но такого в OpenVPN, как я понял нет.
я бы использовал UDP протокол для OpenVPN, а все фишки TCP (целостность, упорядочивание, подтверждение и т.д.) возложил бы на клиента и конечный ресурс.
Использование TCP сознательный выбор для экономии трафика и батарейки на мобильных устройствах. Так как стандартный таймаут NAT трансляций для UDP подключений намного ниже чем для TCP, поэтому в случае с UDP клиент чаще шлет keep alive.
ViperRU
25.06.2017 23:52+1многие провайдеры сейчас блокируют по DNS, при этом перехватывая запросы к любым DNS серверам...
Так DNS-запрос не будет выглядеть как DNS-запрос, и SSL как SSL, так как:
1. Порты совсем другие;
2. Инкапсуляция, то есть в начале будут заголовки самого протокола OpenVPN.
Понятно, что можно научить искать не шифрованный трафик OpenVPN, разбирать его заголовки и добираться до содержимого DNS, SNI, но это не штатными средствами перенаправить все запросы на 53 порт на какой-то свой сервер. ИМХО, прежде чем дойдёт до разбора содержимого не шифрованного VPN канала, скорее запретят весь трафик OpenVPN в DPI по его характерным признакам.
поэтому в случае с UDP клиент чаще шлет keep alive
У вас в настройках keepalive 300 900 если оставить так же для UDP, будет с такой же переодичностью в пять минут слать keepalive, но вам виднее.ValdikSS
26.06.2017 22:54Есть такие DPI, которые могут отслеживать запросы даже внутри HTTP- и Socks5-прокси, на любом порту. Я их называю Full DPI.
У вас в настройках keepalive 300 900 если оставить так же для UDP, будет с такой же переодичностью в пять минут слать keepalive, но вам виднее.
Слабые домашние роутеры могут забывать о UDP-соединении уже через 40 секунд. На какой-то из мобильных сетей РФ UDP-соединения забывались уже через 25 секунд.
Данные о TCP-соединениях хранятся минимум 5 минут, обычно около 15.ViperRU
26.06.2017 23:49Есть такие DPI, которые могут отслеживать запросы даже внутри HTTP- и Socks5-прокси
Не сомневаюсь, но встречал блокировку всего протокола OpenVPN, а вот анализ не шифрованного OpenVPN и блокировку на основе полученного результата, пока не встречал.
ViperRU
26.06.2017 00:18+1В дополнение к предыдущему, если от шифрования отказаться нельзя, то хотя бы стоит отключить защиту от так называемых replay attack, когда для каждого пакета подсчитывается HMAC. Процентов 10 производительности и тут выиграешь.
ValdikSS
26.06.2017 22:56Самую большую нагрузку на процессор создает не шифрование, а переключение контекста и чтение по одному пакету за раз. Шифрование на 3-4 месте по нагрузке на процессор в профилировщике.
ViperRU
27.06.2017 00:08Не скажи… Вот прям сейчас протестировал у себя:
1. Без шифрованияния: 115 мбайт/сек, загрузка одного ядра ~10%.
2. С шифрованием BF-CBC, для SOHO-роутеров, и auth none: 107 мбайт/сек, загрузка одного ядра 85%.
Да, процессы между ядрами не перемещаются.
Подозреваю, что при шифровании каждого пакета больше переключений контекста, а если ещё HMAC считать…ValdikSS
27.06.2017 00:11На моем старом роутере на MIPS-процессоре с частотой 560 МГц, без шифрования где-то 24 мегабита в секунду, а с шифрованием — 19-21.
Если уменьшить переключения контекста, увеличив MTU до 18000, то без шифрования были стабильные 100 мегабит (ограничение порта), а с шифрованием — около 70.ViperRU
27.06.2017 00:16На MIPS влияние отключения шифрования не изучал, только самый быстрый шифр выявлял, собственно BF-CBC самым быстрым и оказался.
Для быстрого переключения контекста, нужны мегагерцы, ну и кэш в процессоре важен, видимо поэтому MIPS быстро не переключается с такими частотами.
ViperRU
27.06.2017 00:12Сорри, iperf пишет сколько мбайт передал, но скорость пишет в мбитах, поэтому 115 мбит/сек и 107 мбит/сек соответственно. Насторожили меня мегабайты/сек поэтому пошёл перепроверять.
hostsuki
25.06.2017 16:30Использование термина VDS вместо VPS.
за 5 лет что я в хостинге так и не понял разницы.
в итоге проще для понимания — написать VDS, не знаю почему. именно что «метка» — клиентам проще сразу понимать о чем речь.
Интерфейс панели управления BillManager
Другие биллинги — еще хуже.
Просто на рынке — нету нормального биллинга. Billmanager лучшее из того, что можно купить рядовому хостеру. И да, он довольно убог :) Но другие не лучше.
Так что по вашему — только самописные хостинги крутые с десятком специалистов и программистов нормальные. А любой типичный хостинг который использует чужие разработки значит убог. Но это не так.
Непонимание принципов IPv6.
Просто сама панель Vmmanager — не умеет с ней работать. А если и умеет — специалистов которые могут разобраться как она может — нет :)
Виртуализация OpenVZ
ну это понятие отмирает уже.
тот же VDS VMmanager делается на KVM
хотя после 1 года использования, я тоже понял, что на этой панели — бизнес не построишь. вроде работает, но все как-то через задницу.
Dmitry_4
26.06.2017 07:45Поясните, как в современном мире еще живут анахронизмы навроде платы за воздух (трафик)??? Он что, изнашивает сервера?
zhovner
26.06.2017 07:58Ширина канала не бесконечная. Ограничения трафика нужно воспринимать как плату за ширину канала доступную вам в единицу времени. Например квота в 30ТБ значит, что вы можете занимать канал месяц на скорости 100Mbit/s или несколько дней на скорости 1Gbit/s или несколько часов на скорости 10Gbit/s.
Arty_K
26.06.2017 11:43+1Извините, а почему для пункта описания пункта "Панель BillManager, ISPmanager и т.д." вы выбрали скриншоты 4-го биллинга? Он был выпущен более 10(!) лет назад, уже года три не развивается и года полтора как снят с продажи. Для наглядности?
Пятёрка выгдядит куда свежее, через пару месяцев будет шестёрка, и в ЛК на ISPsystem ее можно посмотреть-пожмакать http://prntscr.com/fo8cw7
Evengard
26.06.2017 13:58Не смотрели в сторону SoftEther VPN? Кроме того, что есть гуй управления, с его помощью можно поднимать сервер SSTP или L2TP, а SSTP настраивается встроенными средствами Windows, L2TP — встроенными средствами Android и iOS, а так же он умеет общаться и по OpenVPN протоколу — а значит к нему можно подключиться в том числе при помощи OpenVPN.
9uvwyuwo6pqt
30.06.2017 11:34Комментарий по теме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.xmoder
26.06.2017 15:00Сделал свой сервере по вашим настройкам 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)
В чем может быть загвоздка?
Jogger
26.06.2017 15:52> Он позволяет избавиться от кучи ненужных сущностей, вроде NAT и проброса портов.
Уже от одной этой фразы мне хочется не иметь ничего общего c IPv6. Я более-менее спокойно сижу в интернете только потому, что знаю, что нахожусь за NAT роутера, и никакая зараза типа WannaCry мне не грозит. А вы тут мне говорите что выставить все порты наружу — это типа достоинство. Можнт и оно и так, но точно не для параноиков вроде меня.zhovner
26.06.2017 16:32Я более-менее спокойно сижу в интернете только потому, что знаю, что нахожусь за NAT роутера
Это абсолютно ложное ощущение безопасности, потому что вам могут просунуть соседи по локальной сети, либо снаружи через UPnP, NAT-PMP или используя уязвимости soho-роутера. Думать что NAT имеет какое-то отношение к безопасности — заблуждение.
Кроме того, у нас заблокированы все входящие соединения для IPv6 адресов.Jogger
26.06.2017 16:54UPnP выключен, компьютеры в домашней сети я более-менее могу контролировать, уязвимости роутера конечно никто не отменял, но это всё же скорее целевая атака должна быть, а моя цель — отбиться от массовых атак.
>у нас заблокированы все входящие соединения для IPv6 адресов.
>>Он позволяет избавиться от… проброса портов.
Ну да, если полностью отказаться от входящих — это действительно радикально помогает избавится от проброса портов.
nikitasius
В избранное :)