Соеденить две площадки…

… Казалось бы, что может пойти не так?

Недавно мне потребовалось соеденить две площадки с виртуалками. Обе у нас (ПОДЧЕРКИВАЮ!), обе у достаточно крупных провайдеров. В общем, надо сделать так, чтобы Н машин у одного провайдера видели М машин у другого. Трафик не большой, но достаточно критичный.

“ХА!” – сказал я и нарисовал классическую схему соединения.

Выделяем на каждой площадке машинку (или на одну из доступных вешаем внешний ip), обвешиваемся файрволами и закрываем трафик тем же IPSec. Инструкций много, вариантов много – в общем, прорвемся!

Быстренько собрал, накидал конфиги и получил веслом по морде. Протокол ESP где-то по пути заблокирован. Техподдержка обоих провайдеров клянется, что это не у них, но ipsec не верит и отказывается подниматься. Ладно, хотелось по-корпоративному, пойдем по-молодежному.

OpenVPN шустро поднялся, поначалу начал бодро гонять трафик, но через некоторое время начались проблемы. Он переподсоединялся, слал немного байт и снова уходил в нирвану. Смена протокола с UDP на TCP приносила лишь временное облегчение.

Кто виноват – мне, если честно говорить, абсолютно пофиг. Мне трафик нужно гонять. Поэтому расчехлил тяжелую хипстерскую артиллерию – shadowsocks + v2ray. Качаем с гита, просто распаковываем, плюем в конфиг сервера следующее (1.1.1.1 – это внешний адрес сервера, если что):

{
  "server": "1.1.1.1",
  "server_port": 888,
  "password": "verysecretpass",
  "method": "chacha20-ietf-poly1305",
  "timeout": 7200,
  "no_delay": true,
  "fast_open": true,
  "mode": "tcp_and_udp",
  "plugin": "/opt/shadowsocks/v2ray-plugin_linux_amd64",
  "plugin_opts": "server"
} 

А в конфиг клиента вот это:

{
  "server": "1.1.1.1",
  "server_port": 888,
  "local_address": "127.0.0.1",
  "local_port": 1080,
  "password": "verysecretpass",
  "method": "chacha20-ietf-poly1305",
  "timeout": 7200,
  "no_delay": true,
  "fast_open": true,
  "mode": "tcp_and_udp",
  "plugin": "/opt/shadowsocks/v2ray-plugin_linux_amd64",
  "plugin_opts": ""
}

Запускаем и получаем на клиенте socks5 сервер на 1080 порту. А теперь – финт конем. В конфиг OpenVPN на клиенте добавляем одну единственную строчку:

socks-proxy 127.0.0.1 1080

Ну и перезапускаем все, чтобы прочитало конфиги. Вуаля! У нас получилась следующая схема:

OpenVPN ходит через ShadowSocks, который ходит через хрен знает как настроенный интернет.

Но через некоторое время проявилась та же самая боль: немного погодя клиент терял соединение с сервером. Причем перезапустишь – все снова начинает бегать. Ставил опции ping, менял MSS и MTU – пофиг: рандомно теряем коннект.

Ок, перевел openvpn и shadowsock на TCP. Всё магически исправилось. Коннект стабильный, не рвется, пакетики бегают туда-сюда.

Отключил "mode": "tcp_and_udp", позакрывал фаирволлами и начал тестить.

Итак, прямой tcp линк безо всяких штук

[  1] 0.0000-10.2561 sec   112 MBytes  91.8 Mbits/sec

Да, клиент сидит на дешевом тарифном плане в 100 мегабит, поэтому практически упираемся в полку. Теперь через все эти навороты:

[  1] 0.0000-10.3474 sec  50.8 MBytes  41.1 Mbits/sec

И это без какого-либо тюнинга! Да, tcp-over-tcp-over-tcp еще тот изврат, но ведь работает же! А после тюнинга (банальные буфера и прочее – в любом мануале по openvpn) я получил следующее:

[  1] 0.0000-100.4276 sec   896 MBytes  74.8 Mbits/sec

Что в плюсах:

  1. Нам надо платить меньше. На одной стороне не нужен выделенный ip (а они нынче дорогие). Выпускают всех через SNAT и норм.
  2. Настраивается не просто, а очень просто.
  3. Снаружи на сервере порт OpenVPN можно спокойно закрыть фаирволлом. Соединение идет с локалхоста. Больше сесуретей богу сесурити!
  4. Память не жрет. Можно смело брать самую дешевую виртуалку под “роутеры”. Вся вот эта машинерия + FRR с OSPF сьели 200 мегов.
  5. Оно работает. Реально, за неделю уже не одиного разрыва.

Что в минусах:

  1. Потеряли в скорости. Немного, но есть. Проблема в том, что на стороне клиента я банально уперся в единственный ЦПУ виртуалки. Когда тесты идут, на той стороне в топе такое:

С другой стороны, там трафик в 20-30 мегабит уже редкость, так что в любом случае все в порядке. Но запас карман не тянет.

Ну и нафига я все это делал: мне нужно было среплицировать один MySQL в другой. Предложенная схема их удовлетворила, значит задача выполнена.

Influx и Telegraf

Поначалу я планировал этот пост про InfluxDB. Дескать, вот так поставим, вот так настроим… Однако реальность больно тыкнула вилкой в глаз: поставил, запустил, зашел на influx:8086, установил пароль, завел организацию… и всё. Нет, реально всё. Больше там ничего не потребовалось делать.

А вот с телеграфом пришлось повозиться. Дело в том, что я возжелал с одной машины отправлять разные метрики в разные бакеты. Ну всякие там “загрузка процессора и памяти” в один, а “температура в доме” – в другой. Ну вот захотелось мне так.

Все просто. Для начала прямо в telegraf.conf добавим тег influxdb_database

# Global tags can be specified here in key="value" format.
[global_tags]
  # dc = "us-east-1" # will tag all metrics with dc=us-east-1
  # rack = "1a"
  ## Environment variables can be used as tags, and throughout the config file
  # user = "$USER"
  influxdb_database = "default"

Да, я очень неоригинален в этом плане. Теперь ко всему, что собирает telegraf по умолчанию добавляется тэг influxdb_database со значением default.

Теперь добавляем сборку данных с mqtt. Заполняем файл /etc/telegraf/telegraf.d/mqtt.conf

[[inputs.mqtt_consumer]]
  servers = ["tcp://127.0.0.1:1883"]

  ## Topics that will be subscribed to.
  topics = [
    "/devices/+/controls/temperature",
    "/devices/+/controls/battery",
    "/devices/+/controls/humidity",
    "/devices/+/controls/pressure",
    "/devices/+/controls/co2",
    "/devices/+/controls/MCU Temperature",
    "/devices/+/controls/CPU Temperature",
    "/devices/dark_room_power/controls/voltage",
    "/devices/dark_room_power/controls/power",
    "/devices/sleeping_room_power2/controls/voltage",
    "/devices/sleeping_room_power2/controls/power",
  ]

    data_format = "value"
    data_type = "float"

[inputs.mqtt_consumer.tags]
    influxdb_database = "mqtt"

Тут тоже все просто: указываем адрес сервера, указываем, на какие топики подписаться, их формат и последней строчкой меняем значение тега на mqtt. И теперь самая магия:

[[outputs.influxdb_v2]]
urls = ["http://influxdb.hlevnoe.lan:8086"]
token = "xf3w6SKIPSKIP7z1hPQ=="
organization = "hlevnoe"
bucket = "hlevnoe"
[outputs.influxdb_v2.tagpass]
influxdb_database = ["default"]

И сравните с вторым

[[outputs.influxdb_v2]]
urls = ["http://influxdb.hlevnoe.lan:8086"]
token = "xf3w6nSKIPSKIPvam7z1hPQ=="
organization = "hlevnoe"
bucket = "mqtt"
[outputs.influxdb_v2.tagpass]
influxdb_database = ["mqtt"]

Наверняка для матерых инфлюксоводов это покажестя легкой шуткой, но я честно потратил пару часов на раскуривание функционала tagpass. Больше, правда, на выяснение, как и куда его правильно прописать. В общем, теперь все с influxdb_database = default попадает в бакет hlevnoe, а mqtt в mqtt.

Запустив все это и убедившись в отсутствии ошибок, можно вернуться в influx. Там есть простенький data explorer, позволяющий потыкаться и порисовать графики. Даже можно простейшие дашборды собрать!

Вот, к примеру, график потребления электричества у морозильника.

Или график температуры у меня за окном

В общем, это далеко не графана, но по-быстрому позырить что к чему – можно.

Готовим котёнка

Умная мысля приходит обычно слишком поздно. Вот и тут, я много лет страдал при переходе с одного компа на другой. В каждой операционке своя терминалка, со своими дрючками и глючками. Я ходил, настраивал и пытался их подогнать одну к другой.. Хорошо еще, что хоть чуть-чуть шорткаты устаканились, а то вообще боль была…

В общем, я решил сменить терминалку. Немного подумал и составил офигенно длинный лист требований:

  • Терминалка должна работать под Linux, MacOS и Windows (WSL)
  • Она должна работать одинаково. То есть один и тот же параметр в конфиге должен приводить к одним и тем же изменениям в поведении.
  • Терминалка должна уметь в truecolor.
  • Терминалка должна уметь в шрифтовые лигатуры.

Всё остальное, типа рендеринга на GPU или особо правильной поддержке многих систем, мне было совершенно не нужно. Главное, чтобы я взял ноутбук на другой операционке и получил абсолютно тот же… сейчас это модно называть экспириенсом. Внезапно самым сложным для терминалок оказался последний пункт.

Я не понимаю, чего сложного в подобной конвертации символов -> >> <> != ? Но, например, авторы gnome terminal не осилили подобного и отмазались, что не для всех языков это может работать. Ну сделали бы не для всех…

И, внезапно, всем моим хотелкам удовлетворила только одна терминалка – kitty. Если быть до конца честным, то нет, были и другие, но они не такие гламурные. Ставить котёнка можно 100500 способами, но я предпочел через пакетный менеджер.

После установки я некоторое время испытывал реальную боль. Дело в том, что автор этой терминалки – индус и очень своеобразно подошел к составлению документации. Кусочек тут, кусочек там, а потом можно и вот сюда глянуть… В общем, вот мой конфиг

font_family Fira Code
font_size 12
cursor_shape block
cursor_shape_unfocused hollow
shell_integration no-cursor
scrollback_lines 10000
sync_to_monitor yes
remember_window_size  yes
initial_window_width  800
initial_window_height 600
include theme.conf
tab_bar_style slant
update_check_interval 0
term xterm-256color
paste_actions quote-urls-at-prompt
background_opacity 1
confirm_os_window_close 0
map super+n new_os_window_with_cwd
map super+t new_tab_with_cwd
map super+w close_os_window
map super+c copy_to_clipboard
map super+v paste_from_clipboard

Последние строчки – это дань моей лени, чтобы новые окошки открывались как на макоси. Win+n и не надо пальцы ломать об Ctrl+Shift+n . Мелочь, а удобно. Ну и файлик theme.conf, честно спертый из интернета и имитирующий тему homebrew

# Theme ported from the Mac Terminal application.

background #000000
foreground #00ff00
cursor #23ff18
selection_background #083905
color0 #000000
color8 #666666
color1 #990000
color9 #e50000
color2 #00a600
color10 #00d900
color3 #999900
color11 #e5e500
color4 #0000b2
color12 #0000ff
color5 #b200b2
color13 #e500e5
color6 #00a6b2
color14 #00e5e5
color7 #bebebe
color15 #e5e5e5
selection_foreground #e5e5e5

И вот я уже почти неделю живу на двух операционках и с одним терминалом. Нормально …

Теперь операционко-специфичные штуки.

MacOS: надо в ENV переменные добавить KITTY_CONFIG_DIRECTORY=~/.config/kitty/ , иначе котенок хз где хранит конфиги. А так все в одинаковом месте. Чтобы сменить иконку, надо ее просто рядом с конфигом положить и обозвать kitty.app.png.

Linux: чтобы сменить иконку, надо сделать desktop файл, аналогичный нижеприведенному, и положить его в .local/share/applications/ . Главная боль – путь до иконки должен быть абсолютным.

[Desktop Entry]
Version=1.0
Type=Application
Name=kitty
GenericName=Terminal emulator
Comment=Fast, feature-rich, GPU based terminal
TryExec=kitty
StartupNotify=true
Exec=kitty
Icon=/home/kiltum/.config/kitty/kitty.app

Все 🙂

Всё своё ношу с собой. Локальное зеркало.

Пора, пора описывать то, что было сделано. А то как обычно, забудется и всё, пиши “прощай”.

Итак, давным-давно, когда ещё существовала страна под названием “Украина”, я начал делать свою… Ну даже не знаю, на лабораторию это не тянет, на свой датацентр тоже. В общем, несколько серверов, выполняющих нужные для меня задачи. Часть арендованные, часть свои… И всё было совсем хорошо, пока не началась СВО. Тут же вылезла куча говна и давай блочить доступ. Следом к ним присоеденились убегуны и давай портить до чего руки дотянутся. Дескать, они все такие чувствительные, что не могут позволить такое и вааще, они только за самое хорошее! Но тут не про них, а про то, как сделать себе хорошо и нагло игнорировать подобное сейчас и в будущем.

Итак, условия для этой задачи и последующих простые: я должен иметь возможность поставить или обновить нужное мне в любой момент времени. Есть интернет, нету – все равно. И первым шагом я сделаю зеркало для пакетов дистрибутива ubuntu.

Погуглив, я нашел несколько инструкций, как сделать свое зеркало. Немного потыкался в монстров типа Nexus и прочих JFrog и решил, что лучшее враг хорошего. Итак, для начала нам нужна машинка с более-менее приличным диском. Далее все просто и прямолинейно: ставим необходимое и подготавливаем структуру каталогов

apt install apache2 debmirror gnupg xz-utils rsync

mkdir -p /mirror
mkdir /mirror/debmirror
mkdir /mirror/debmirror/amd64
mkdir /mirror/debmirror/mirrorkeyring
mkdir /mirror/scripts

gpg --no-default-keyring --keyring /mirror/debmirror/mirrorkeyring/trustedkeys.gpg --import /usr/share/keyrings/ubuntu-archive-keyring.gpg

cd /var/www/html
ln -s /mirror/debmirror/amd64 ubuntu

cd /mirror/scripts

А вот теперь скрипт, который все друг у друга таскают. Я не исключение

# cat > debmirroramd64.sh 
#!/bin/bash

## Setting variables with explanations.

#
# Don't touch the user's keyring, have our own instead
#
export GNUPGHOME=/mirror/debmirror/mirrorkeyring

# Arch=         -a      # Architecture. For Ubuntu can be i386, powerpc or amd64.
# sparc, only starts in dapper, it is only the later models of sparc.
# For multiple  architecture, use ",". like "i386,amd64"

arch=amd64

# Minimum Ubuntu system requires main, restricted
# Section=      -s      # Section (One of the following - main/restricted/universe/multiverse).
# You can add extra file with $Section/debian-installer. ex: main/debian-installer,universe/debian-installer,multiverse/debian-installer,restricted/debian-installer
#
section=main,restricted,universe,multiverse

# Release=      -d      # Release of the system (, focal ), and the -updates and -security ( -backports can be added if desired)
# List of updated releases in: https://wiki.ubuntu.com/Releases
# List of sort codenames used: http://archive.ubuntu.com/ubuntu/dists/

release=noble,noble-security,noble-updates,noble-backports

# Server=       -h      # Server name, minus the protocol and the path at the end
# CHANGE "*" to equal the mirror you want to create your mirror from. au. in Australia  ca. in Canada.
# This can be found in your own /etc/apt/sources.list file, assuming you have Ubuntu installed.
#
server=ru.archive.ubuntu.com

# Dir=          -r      # Path from the main server, so http://my.web.server/$dir, Server dependant
#
inPath=/ubuntu

# Proto=        --method=       # Protocol to use for transfer (http, ftp, hftp, rsync)
# Choose one - http is most usual the service, and the service must be available on the server you point at.
# For some "rsync" may be faster.
proto=rsync

# Outpath=              # Directory to store the mirror in
# Make this a full path to where you want to mirror the material.
#
outPath=/mirror/debmirror/amd64

# By default bandwidth is not limited. Uncommend this variable and set it to the apropriate
# value in Kilobytes per second. Also don't forget to uncomment the --rsync-options line in the last section below.
bwlimit=1000

# The --nosource option only downloads debs and not deb-src's
# The --progress option shows files as they are downloaded
# --source \ in the place of --no-source \ if you want sources also.
# --nocleanup  Do not clean up the local mirror after mirroring is complete. Use this option to keep older repository
# Start script
#
debmirror       -a $arch \
                --no-source \
                -s $section \
                -h $server \
                -d $release \
                -r $inPath \
                --progress \
                --method=$proto \
                --rsync-options "-aIL --partial --bwlimit=$bwlimit" \
                $outPath

Скрипт настроен на российский миррор и лимит в 1 мегабайт в секунду, чтобы не забивать канал, как минимум при первоначальной скачке. Ну и релиз поменял на noble, ибо нынче уже 2024 год и в ходу у меня 24.04. Далее просто запускаем этот скрипт и идем заниматься своими делами. Оно медленно и печально высосет кучу гигабайт. Реально КУЧУ гигабайт. На момент написания размер зеркала был в районе двухсот гигов.

Ну а дальше просто везде разбрасываем новый ubuntu.list, заменяя им ubuntu.sources

deb http://mirror/ubuntu noble main restricted universe multiverse
deb http://mirror/ubuntu noble-security main restricted universe multiverse
deb http://mirror/ubuntu noble-updates main restricted universe multiverse

И точно так же миррорим что-то другое. К примеру, возжелал я поставить InfluxDB. Можно пакетики тащить, а можно зеркало сделать.

wget -q https://repos.influxdata.com/influxdata-archive_compat.key
gpg --no-default-keyring --keyring /mirror/debmirror/mirrorkeyring/trustedkeys.gpg --import influxdata-archive_compat.key
mkdir -p /mirror/debmirror/influx/
cat influxdata-archive_compat.key | gpg --dearmor > /mirror/debmirror/influx/key.gpg
cd /var/www/html
ln -s /mirror/debmirror/influx influx

И чуточку поправленный скрипт без комментариев. Изменил только откуда брать, куда ложить и то, что не надо использовать rsync. Адреса и прочее я нагло упер из инструкции с официальной страницы https://www.influxdata.com/downloads/, когда выбрал Ubuntu&Debian

# cat influx.sh 
#!/bin/bash

export GNUPGHOME=/mirror/debmirror/mirrorkeyring
arch=amd64
section=main
release=stable
server=repos.influxdata.com
inPath=/debian
proto=http
outPath=/mirror/debmirror/influx

debmirror       -a $arch \
                --no-source \
                -s $section \
                -h $server \
                -d $release \
                -r $inPath \
                --progress \
                --method=$proto \
                --rsync-extra=none \
                $outPath

Ну и потом на хосте, куда что-то от influx будет ставиться:

wget http://mirror.hlevnoe.lan/influx/key.gpg -O /usr/share/keyrings/influx.gpg

cat > /etc/apt/sources.list.d/influx.sources 
Types: deb
Architectures: amd64
Signed-By: /usr/share/keyrings/influx.gpg
URIs: http://mirror.hlevnoe.lan/influx
Suites: stable
Components: main

Дальше совершенно стандартно: apt update && apt install...

Умный дом. MQTT сервер

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

Исторически сложилось, что для централизации подобного используется протокол MQTT. Он легкий, простой и поддерживается всеми участвующими в деле устройствами.

Вообще у меня уже есть один mqtt сервер, встроенный в wirenboad. Но есть два больших но: 1) сам по себе wirenboard очень дохлый (хотя народ радостно на него даже Home Assistant в докере водружает) и 2) у меня будет очень много устройств, общающихся по MQTT.

Поэтому решение простое: поднимаем на виртуалке MQTT сервер и заставляем всех с ним работать. А кто не умеет или умеет не кошерно – забирать с тех данные самим. Для реально больших нагрузок или отказоустойчивости народ ставит EMQX, но у меня такого не будет, поэтому использую mosquitto.

apt install mosquitto mosquitto-clients

Все настройки оставляю по умолчанию, просто добавляю один мост wirenboard->mosquitto.

# cat /etc/mosquitto/conf.d/wirenboard.con
connection wirenboard
address wirenboard:1883
bridge_insecure true
topic # in 0

Принцип простой: тупо подписываемся на все топики с сервера wirenboard. Паролей и логинов нет, всяких TLS тоже не наблюдается. Проверить работоспособность полученного решения тоже проще простого:

mosquitto_sub -t \#

Если все хорошо, то вы должны увидеть бегущую колонку цифр. Wirenboard сам по себе генерирует кучу трафика, так что никаких пауз не будет. А если у вас, как и у меня, уже подключены датчики, то трафик становится довольно большим для глаз.

Первая ачивка получена!

Как сбросить кеш только для одного файла

Дело было как-то вечером. Есть у меня дома контроллер wirenboard. Пока идет знакомство, наладка и отстройка, управляет светом около стола, да и меряет температуру по всему дому. Но не суть. наткнулся я на одну интересную багофичу: если пощелкать переключателями, а потом тут же обрубить питание, то эти самые переключатели после загрузки окажутся в рандомном состоянии.

Небольшое расследование со службой поддержки wirenboard показало, что дело в одном маленьком файлике. Вернее с тем, как linux с ним обращается. Верхнеуровневый софт честно в него пишет нужное, а вот линукс, желая сберечь ресурс emmc, начинает активно кешировать и сбрасывает файловый кеш тогда, когда в 99% уже поздно.

Казалось бы, фигня вопрос: засунь в крон sync и дело в шляпе. Ок, не в крон, это перебор, а после inotify и всё. Но сбрасывать всю FS ради одного файла… В общем, рецепт ниже.

# cat /etc/systemd/system/libwbmqtt-saver.service 
[Unit]
Description=Drop file cache for libwbmqtt.db if it changed

[Service]
ExecStart=/bin/bash -c 'inotifywait -qq -e modify /var/lib/wb-mqtt-gpio/libwbmqtt.db && dd of=/var/lib/wb-mqtt-gpio/libwbmqtt.db oflag=nocache conv=notrunc,fdatasync count=0 status=none'
Restart=always

[Install]
WantedBy=multi-user.target

Всё написано на скорую руку, но тем не менее, прекрасно работает. Вся магия в том, что dd открывает фаил на запись, записывает 0 байт и закрывает, сбрасывая кеш. Такую оптимизацию подсмотрел где-то в инете, мое первоначальное решение было гораздо страшнее (и нет, не покажу).

В общем, жужжит как надо.

Fedora 40 Wifi cannot connect to network

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

Однако через некотрое время индеец зоркий глаз стал замечать, что на WiFi жалуется только ноутбук на Fedora. Windows, MacOS и андроиды и iOS цеплялись хорошо и никаких призывов не выдавали. И это бы продолжалось еще долго, но вчера линукс сказал “все, я больше не хочу соединяться с сетью”. Совсем.

Симптомы простые: ноутбук видит WiFi, соединяется, но через 45 секунд происходит тайм-аут DHCP и он отсоединяется. Установка статического адреса не помогает. Он перестает отваливаться, но пакеты никуда не ходят.

Проверка с помощью tcpdump показала, что в общем-то на это есть резоны: в канале было тихо. Причем настолько тихо, что даже запущенный с ноутбука ping не было видно. Тут я наконец-то понял, что проблемы именно на моей стороне.

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

Включил точку доступа на телефоне. Ноутбук мгновенно прицепился и сообщил, что все в порядке.

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

Так я сделал вывод, что железная часть работает. Дело в софте. И тут мне повезло запустить еще раз tcpdump как раз во время той самой паузы до таймаута. И внезапно я увидел бегающие туда-сюда пакетики, характерные для любой сети. Точно софт!

Стал разбираться. Оказалось, что добрые идиоты, пишущие Network Manager, где-то налажали в последних апдейтах и теперь мак-адрес меняется так, что он вводит сетевую в кому (или что-то еще в потрохах, но разбираться было лень). Ок, значит проблема простая: надо найти, где это выключается и дело в шляпе!

А вот тут возникла проблема. Оно нигде не выключается. Все найденные рецепты про wifi.cloned-mac-address и ethernet.cloned-mac-address не дали ровном счетом ничего. Повторяю: николай, иван, хартон, ульяна, яна. Так как дело было вечером, я решил не мучаться и вернуться на шаг назад. Говоря другими словами, вырубить нафиг NetworkManager.

Первым делом отвязываем wpa_supplicant от NM, хардкодим интерфейс и выключаем сам NM

# cat /usr/lib/systemd/system/wpa_supplicant.service
[Unit]
Description=WPA supplicant
Before=network.target
Wants=network.target
#After=dbus.service

[Service]
#Type=dbus
Type=oneshot
RemainAfterExit=yes
#BusName=fi.w1.wpa_supplicant1
EnvironmentFile=-/etc/sysconfig/wpa_supplicant
ExecStart=/usr/sbin/wpa_supplicant -B -i wlp0s20f3 -c /etc/wpa_supplicant/wpa_supplicant.conf
# -u $INTERFACES $DRIVERS $OTHER_ARGS
ExecStart=/usr/sbin/dhclient wlp0s20f3
ExecStop=/usr/bin/killall -q wpa_supplicant
ExecStop=/usr/bin/killall -q dhclient
[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl disable NetworkManager.service
# systemctl stop NetworkManager.service

Потом конфигурируем ручками wpa_supplicant

# cat /etc/wpa_supplicant/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

network={
    ssid="multik"
    psk="VERY_SECRET_PASSWORD"
}

И рассказываем системе, что делать с сетью (ну и чтобы dhclient не ругался)

# cat /etc/sysconfig/network-scripts/ifcfg-wlp0s20f3 
DEVICE="wlp0s20f3"
ONBOOT=yes
NETBOOT=yes
IPV6INIT=yes
BOOTPROTO=dhcp
HWADDR="68:3e:26:b0:b1:93"
NAME="wlp0s20f3"
NM_CONTROLLED="no"

И самым последним шагом правим конфиг NSS, чтобы он не страдал херней, ибо всякие resolvd тоже ушли гулять вслед за NM

# cat /etc/nsswitch.conf 
....
#hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
hosts:      files myhostname dns
....

Все. Можно перезапустить сервисы, а можно отребутиться для проверки. Сеть есть, внезапно никто ни на что не жалуется и не отваливается.

Update: проверил на live образах. Все отлично коннектится и радуется жизни. То есть это именно обновления как-то и где-то что-то наковыряли

Привожу медиатеку к единому стилю

В предидущем посте я прошелся по библиотеке и расставил везде теги и обложки. Но теперь надо решить другую проблему: у меня есть mp3, m4a и flac файлы. Причем я точно знаю, что некоторые flac и m4a получены из mp3. Да, источники музыки были не всегда адекватными …

Поэтому шаг номер раз: приводим всю библиотеку в mp3 формат. То, что из m4a и flac перезапишутся mp3 – пофиг

find . -type f -name "*.m4a" | parallel 'ffmpeg -y -i {}  -map_metadata 0 -codec:a libmp3lame -qscale:a 1 {.}.mp3'

find . -type f -name "*.flac" | parallel 'ffmpeg -y -i {}  -map_metadata 0 -codec:a libmp3lame -qscale:a 1 {.}.mp3'

Теперь можно грохнуть “оригиналы”. И совсем маленький шаг: необходимо избавиться от дубликатов. Так как источников было много, то и для некоторых популярных песен было аж до 5 вариантов. Пишу маленький скрипт, который удаляет все дубликаты меньшего размера (да, буду считать, что бОльший размер означает лучшее качество).

#!/bin/bash

IFS=$(echo -en "\n\b")

function traverse() { 
    # lets find copies in directory and i dont want use .m?? in search
    for file in $(ls -1 ${1} |grep -e \(1\).mp3 -e \(2\).mp3 -e \(3\).mp3 -e \(4\).mp3 -e \(5\).mp3) 
    do
        l="${1}/${file%????????}*" # cut (X).mp3 from file name
        # delete all files except first and biggest
        ls -1S ${l} | tail -n +2 | xargs -d '\n' rm -f
        # Now rename file. Leave mv alone for errors "the file is same" - its working indicator for me :)
        ffin="${l%?}.mp3"
        mv  $l $ffin        
    done
    # now lets find another directory to deep in
    for file in $(ls "$1")
    do
        if [[ -d ${1}/${file} ]]; then
            traverse "${1}/${file}"
        fi
    done
}

function main() {
    traverse "$1"
}

main "$1"

И натравливаем его на библиотеку. Я специально не стал обрамлять вокруг mv, что бы хоть что-то выводило во время работы, поэтому сообщения типа mv: '/mnt/swamp/Reloaded//松居慶子/Dream Walk/04 Fire in the Desert.mp3' and '/mnt/swamp/Reloaded//松居慶子/Dream Walk/04 Fire in the Desert.mp3' are the same file стали для меня индикатором, что скрипт работает.

В результате у меня теперь есть библиотека музыки, где все разложено по полочкам (иногда полупустым), протегано и с обложками. Но (ох уж это но) есть куча песен с битрейтом 96 и 128 кбит/с. Но как к этому подобраться автоматически – я пока не представляю.

Навожу порядок в музыке

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

Ситуацию усложняло то, что куча файлов имело очень говорящие названия типа 3.mp3. Естественно, каких-либо тегов тоже ожидать не приходилось. Ну вот просто как-то понравилась мне песенка, я ее и забросил в архив …

Наконец в очередной раз я подошел к этой свалке. Тыкался, тыкался, смотрел на всякие редакторы тегов и горестно вздыхал. Пока не решил погуглить, как можно для всего этого поиспользовать всякие шазамы и прочие новомодные (почти) штучки. И вуаля!

https://picard.musicbrainz.org/

Оставлю эту ссылку отдельной строкой. Жрет mp3, ищет по аудиотпечатку что же это за трек и заполняет теги, добавляет обложку и раскладывает получившееся красиво. Я в совершеннейшем восторге. На тестовой выборке в 7 тыщ файлов не нашла соответствие только для 3. Но их никто не знает, ни яндекс, ни яблоки. Мелочь …

Обходим DNS hi-jack

Не так давно некоторые (я не буду показывать пальцем) провайдеры начали заниматься херней. А именно блокировать или подменять DNS ответы. И ладно бы блочили какой-нибудь абстрактный facebook.com, так они ломают к примеру резолвинг обратных записей, что например для почтовых серверов больно и печально. Если обратиться к техподдержку, то там начинают лепетать про защиту от угроз и предлагают пользоваться серверами провайдера, ведь они защищены и вообще лучше всех.

В общем, на данный момент это все лечится очень просто. Берем любой клиент DNS over HTTPS (DoH), ставим его и направляем весь днс трафик через него. Для ubuntu рецепт следующий:

apt install dnscrypt-proxy
systemctl enable dnscrypt-proxy
systemctl start dnscrypt-proxy

В результате на 127.0.2.1:53 появляется DNS сервер, который кладет всевозможные причиндалы на провайдерские потуги. Ну а дальше во всех клиентах просто указываем этот сервер. Лично я просто добавил одну строчку на главном домашнем кеширующем bind

cat /etc/bind/named.conf.options | grep fo
        forwarders { 127.0.2.1 ; };

Ну и попутно подобным шагом вы провайдеру статистику “куда вы ходите” поломаете. Ибо “кто с чем к нам, тот тем и получит”

PS Да, это все лечится VPN, но кто даст гарантию, что и провайдер VPN не займется тем же самым?

Знай свой cgroup

Давеча столкнулся с непонятным (для меня до сегодня) поведением cgroup. Изначально описание проблемы было очень информативным “сервер тормозит”.

Захожу я на сервер и вижу картину маслом:

Куча свободной памяти, но сервер сидит в свопе и выбираться оттуда категорически не желает. Я последовательно начал перебирать все известные мне лимиты и ограничения: везде норм, хорошо и ничего не вызывает подозрений.

Так как эта нода кубернетеса, то я посмотрел и на ограничения подов в /sys/fs/cgroup/memory/. Тоже все согласно описанному, везде memory.limit_in_bytes соответствуют нужному.

Затем я скопипастил микроскрипт что бы посмотреть, кто занял своп

SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
    PID=`echo $DIR | cut -d / -f 3`
    PROGNAME=`ps -p $PID -o comm --no-headers`
    for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
    do
        let SUM=$SUM+$SWAP
    done
    if (( $SUM > 0 )); then
        echo "PID=$PID swapped $SUM KB ($PROGNAME)"
    fi
    let OVERALL=$OVERALL+$SUM
    SUM=0
done
echo "Overall swap used: $OVERALL KB"

Но скрипт выдал совершенно не совпадающие с системными утилитами значение. Согласно его выводу, своп использовался на 6 гигов. А я вижу на скриншоте выше – 12. Проверил выборочно значения из /proc – совпадают с высчитанными …

Ок, проверю вообще работу подсистему памяти. Набросал быстренько микропрограммку на С, которая раз в секунду сжирала гиг памяти. top честно показал сначала исчерпание free, потом окончание свопа. После пришел OOM и убил программку. Всё правильно, всё так и должно быть.

Долго я ломал голову и пробовал разные варианты. Пока в процессе очередного созерцания top внезапно глаз не зацепился за главного пожирателя памяти. Вернее за его показатель VIRT в 32 гига памяти. Так-то я смотрел на %MEM и RES. В общем, появился резонный вопрос “какого?”

Забрезжила идея, что что-то не так с cgroup. Ок, делаю группу с лимитом памяти в 10 гигов, проверяю, что memory.limit_in_bytes стоят, запускаю снова программку-пожиратель памяти … и вуаля! Через 10 секунд сожралось ровно 10 гигов RAM, и начал жраться своп. Вопрос “какого?” стал более актуальным

Начал гуглить. https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt говорит скромно

memory.memsw.usage_in_bytes # show current usage for memory+Swap (See 5.5 for details)

memory.limit_in_bytes # set/show limit of memory usage

memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage

Про memsw я специально добавил. Но на этой машине Ubuntu 20.04 с cgroup V2 и параметра с memsw нет. Нахожу дальнейшим гуглежом https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

The main argument for a combined memory+swap facility in the original cgroup design was that global or parental pressure would always be able to swap all anonymous memory of a child group, regardless of the child’s own (possibly untrusted) configuration. However, untrusted groups can sabotage swapping by other means – such as referencing its anonymous memory in a tight loop – and an admin can not assume full swappability when overcommitting untrusted jobs.

Особенно понравились слова про саботаж. То есть, докер ограничивал использование только RAM, но не SWAP. Теперь, когда проблема стала понятной, стало понятно, что и надо гуглить.

https://docs.docker.com/engine/install/linux-postinstall/#your-kernel-does-not-support-cgroup-swap-limit-capabilities

Грубо говоря, надо добавить в конфиг grub

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Но тут нода “боевая”, надо дать доработать сервису, поэтому просто увеличили лимиты для пода.

Как говорится, все “побежало и поскакало”

PS Про то, что на ноде с k8s не должно быть свопа я в курсе. Как и то, что начиная с версии 1.21 он поддерживается.

Свой gitlab на centos 7

Получив очередной счет от gitlab и github одновременно, я как-то задумался: а нафига я им плачу, когда я все это могу поднять на своем сервере? “Все это” – это кучку приватных git и простую ci/cd систему. Поставил и решил написать напоминалку, что бы в следующий раз не гуглить.

Процесс установки не вильно отличается от описанного на сайте, но есть несколько НО:

Во-первых, в centos7 nginx идет без поддержки passenger. Поэтому обновляем на версию из “пассажирской” репы.

curl --fail -sSLo /etc/yum.repos.d/passenger.repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo
yum-config-manager --enable cr
yum install -y passenger
rpm -e nginx-mod-http-perl --nodeps
yum update nginx

Во-вторых, нигде в мануале не указано, что gitlab требует nodejs для работы

yum install nodejs

И наконец, нигде не указано, что gitlab не работает без unicorn. Во всех мануалах написано, что если у вас внешний nginx, отрубите встроенный и unicorn. Так вот, этого делать нельзя, иначе получите неработающий gitlab-workhouse

Из других неочевидных тюнингов стал вынос порта unicorn с 8080 и изменение размера буферов у постгреса. Иначе на моем загруженном сервере он отказывался запускаться.

unicorn['port'] = 8088
postgresql['shared_buffers'] = "100MB"

В остальном единственной засадой было изменение прав на сокеты, но это только из-за моей конфигурации, где куча всяких пользователей лезут в в один каталог. Так как сервер “домашний”, проще стало дать всем права на запись.

Больше никаких отступлений от официального руководства.

Новый датацентр. Сертификаты в почту

Для своих нужд я обычно ставлю Zimbra Open Source Edition. Простой, дуракоустойчивый почтовый сервер со всякими необходимыми плюшками. Но есть в нем одна маленькая проблема: по умолчанию он генерит самоподписанные сертификаты, на которые ругаются всякие почтовые клиенты. Значит, надо подсунуть сертификаты от letsencrypt

Сделаем на сервере каталог для сертификатов

mkdir -p /opt/zimbra/ssl/letsencrypt/
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/

Опять же, маленький скриптик, который пускается руками после обновления сертификатов и проверки готовности всего ко всему. Он же zimbra_check

cat /opt/www/chain.pem >> /etc/letsencrypt/live/mail.ka12.co/fullchain.pem 
scp  /etc/letsencrypt/live/mail.ka12.co/* root@mail:/opt/zimbra/ssl/letsencrypt/
ssh root@mail "chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"

Логика понятна из текста: добавляем CA ключ (отсюда) в цепочку, копируем все это в потроха зимбры и проверяем, согласится ли она это съесть. Обычно ответ “да”, но иногда она взбрыкивает и надо смотреть, чего же ей не нравится. Если ошибок нет, то можно запустить zimbra_deploy

#!/bin/bash
ssh root@mail "runuser -l zimbra -c 'zmcontrol stop'"
ssh root@mail "cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.`date \"+%Y%m%d\"`"
ssh root@mail "runuser -u zimbra cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"
ssh root@mail "runuser -l zimbra -c '/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem'"
ssh root@mail "runuser -l zimbra -c 'zmcontrol start'"

Он тормозит нафиг всю зимбру, бекапит и деплоит сертификаты и снова запускает все назад.

Новый датацентр. Web

Что самое главное во всем этом? Правильно, наши интернетики с кисками и прочим. А значит, надо обеспечить заход снаружи внутрь по https

На данный момент я знаю всего 3 способа: с помощью nginx, apache и traefik. Apache как-то старо, traefik наоборот, слишком новомодно.

Предупреждаю сразу: использовать в докере nginx c nginx-gen и companion, как описано вот тут https://github.com/gilyes/docker-nginx-letsencrypt-sample – нельзя. Проблема простая: генератор тупо мешает ip бэкэндов как ему понравится.

Краткий план: ставим виртуалку

virt-builder centos-7.4 --arch amd64 -o nginx.ka12.co.img --size 20G --format qcow2 --hostname nginx.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc
virt-install --name nginx.ka12.co --network bridge=virbr100 --memory 2048 --disk path=nginx.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

бутстрапим ее

ansible-playbook -i inventory -l nginx* centos-bootstrap.yml

Добавляем в нее нужное

yum -y install freeipa-client && ipa-client-install --mkhomedir
yum install certbot python2-certbot-nginx nginx

И запускаем nginx

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
systemctl start nginx

Берем из git (https://github.com/kiltum/newdc/tree/master/nginx) и кладем в /opt/www

Там два темплейта – первый для просто “сделай так, что бы nginx узнал о сайте”, а второй – уже готовый полноценный конфиг.

Ну а что делает скрипт new_site, думаю разберетесь сами. Только email правильный пропишите.

Запускаем ./new_site mail.ka12.co и вот результат:

После меняем конфиг сайта как нам надо и вуаля! Теперь по приходу емайла от letsencrypt заходим и обновляем все сразу.

Новый датацентр. Докер

Следующим большим шагом в постройке “датацентра” у меня будет разворачивание докера. Без него нынче никуда, да и удобный он, зараза.

Согласно всем мануалам для новичков, для минимально живучего кластера необходимо заиметь три машины. А у меня одна, но зато физическая. Значит, поднимаю три виртуалки и туда запихиваю докер.

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

Добываю/делаю правильный ifcfg фаил

cat ifcfg-eth0
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="172.16.100.11"
PREFIX="24"
GATEWAY="172.16.100.1"
NM_CONTROLLED="no"

Добавляю пароль рута в файл root_pass и кладу рядом свой публичный ключ. Рядом же resolv.conf. Затем создаю образ диска

virt-builder centos-7.4 --arch amd64 -o docker1.ka12.co.img --size 80G --format qcow2 --hostname docker1.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc

И запускаю машину с ним.

virt-install --name docker1.ka12.co --network bridge=virbr100 --memory 8096 --disk path=docker1.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

Минута и виртуалка готова. Меняем ip адрес в конфиге+хостнейм и повторяем так еще два раза. Все, ноды для кластера готовы.

Добавляем их в инвентори и бутсрапим до приемлемого состояния.

ansible-playbook -i inventory -l docker* centos-bootstrap.yml

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

yum -y install freeipa-client && ipa-client-install --mkhomedir

ansible-playbook -i inventory docker-install.yml

И на любой машине проверяю, что докер докерит

docker run hello-world

Так как у нас инфраструктура пока из одного хоста, заморачиваться распределенным хранилищем нет смысла от слова совсем. Поэтому просто раскидаю по хостам nfs

На хосте:

mkdir -p /opt/nfs
chmod 777 /opt/nfs
cat /etc/exports
/opt/nfs 172.16.0.0/16(rw,sync,no_root_squash,no_all_squash)
systemctl restart nfs-server

Проверяю, что увидит докер

# showmount -e 172.16.100.1
Export list for 172.16.100.1:
/opt/nfs 172.16.0.0/16

Создаю супер-каталог для volume

mkdir -p /opt/nfs/data
chmod 777 /opt/nfs/data

Теперь на докер-хосте создаю volume


docker volume create --driver local --opt type=nfs --opt o=addr=172.16.100.1,rw --opt device=:/opt/nfs/data --name data

И проверяю

[root@docker1 ~]# docker volume ls
DRIVER VOLUME NAME
local data
[root@docker1 ~]# docker volume inspect data
[
{
"CreatedAt": "2018-01-27T08:46:56-05:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/data/_data",
"Name": "data",
"Options": {
"device": ":/opt/nfs/data",
"o": "addr=172.16.100.1,rw",
"type": "nfs"
},
"Scope": "local"
}
]

Теперь проверяю, как с этим будут работать контейнеры

docker container run -ti -v data:/data alpine sh

Там в /data можно посоздавать файлики и вообще поиграться “как будто в реальной жизни”.

Новый датацентр. Сервер.

Долго ли, коротко, но дошел я до того, что мне стало уж очень дорого пользоваться услугами Amazon. Оно удобно, но дорого. Значит, мне опять дорога назад, к выделенному серверу.

Но терять кучку удобных штук типа докера нет желания, поэтому буду строить сразу и с запасом. Итак, что мне охота

1. Централизованное управление аккаунтами. Для всяких ssh, git и прочим
2. KVM и докер.
3. Чистый, не засранный хост. Не хочу видеть по интерфейсу и 10 правил на каждый контейнер.
4. Разное.

Итак, стадия номер 1 или “подготовка”. Все использованное мной можно найти тут: https://github.com/kiltum/newdc Ну и я подозреваю, что вы уже имеете опыт администрирования linux, поэтому буду только намечать путь.

Арендую новый сервер. Hetzner, leaseweb – их много. И ставлю туда пустую и голую CentOS 7. Никаких панелей, рюшечек и прочего. Из моих уже личных требований – поставить все на raid1.

Бутстраплю ее с помощью ansible и роли centos-bootstrap.yml. Там снос selinux, firewalld, установка ntp и прочих пакетиков и обновление системы. Самый необходимый минимум.

Ставлю KVM. Эта операция одноразовая, поэтому можно и руками.

yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install

Сношу дефаултную сеть от KVM. Это автоматически избавляет меня от кучки правил в iptables.

virsh net-autostart --disable default
virsh net-destroy default

Создаю тупой интерфейс, куда буду цеплять с помощью бриджа виртуалки

modprobe dummy numdummies=1
echo "dummy" > /etc/modules-load.d/dummy.conf
echo "options dummy numdummies=1" >> /etc/modprobe.d/dummy.conf

Генерирую для него мак-адресс (в принципе можно от балды, но лучше что бы с первыми октетами от KVM – так симпатичней)

hexdump -vn3 -e '/3 "52:54:00"' -e '/1 ":%02x"' -e '"\n"' /dev/urandom

И делаю конфиг-фаил для этого интерфейса

cat > /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
MACADDR=52:54:00:1b:e1:80
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
IPV6INIT=no
BRIDGE=virbr100

и описываю бридж

cat > /etc/sysconfig/network-scripts/ifcfg-virbr100
DEVICE=virbr100
NAME=virbr100
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
DELAY=2
STP=on
IPADDR=172.16.100.1
NETMASK=255.255.255.0
IPV6INIT=no

Поднимаю созданное

ifup virbr100

В результате я получил следующее

2: dummy0: mtu 1500 qdisc noqueue master virbr100 state UNKNOWN qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever
...
5: virbr100: mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.1/24 brd 172.16.100.255 scope global virbr100
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever

Разрешаю форвардинг пакетиков между интерфейсами

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

Для полноценной работы виртуалок я добавляю в стандартный набор правил еще одно, которое обеспечивает виртуалкам выход в интернет. Вместо иксиков подставьте свой внешний ipшник

-A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x

И в принципе все, я готов создать первую виртуалку.

virt-install --name head.ka12.ko --network bridge=virbr100 --memory 1024 --disk path=head.ka12.co.img,size=30 --cdrom ../iso/CentOS-7-x86_64-Minimal-1708.iso --graphics vnc,listen=172.16.100.1 --noautoconsole

И получаю к ней доступ по VNC

virsh vncdisplay head.ka12.co

Так как пока нету ничего даже похожего на нормальный доступ, пробрасываю VNC порт на локальную машину

ssh -L 5901:172.16.100.1:5900 kiltum@ka12.co

Дальше открываю VNC клиент и по адресу localhost:5901 получаю консоль виртуалки. Дальше как обычно “Далее-далее-подождать и перезагрузить”. Опять же можно было заморочиться и использовать автостарты, но мне лень такое делать на редких и одноразовых операциях.

У этой новой виртуалки будет совершенно ожидаемый адрес 172.16.100.2. После “ребута” инсталлятора снова запускаем и ставим в автозапуск

virsh start head.ka12.co
virsh autostart head.ka12.co

Первым делом надо решить вопрос с доступом в мою “инфраструктуру”. Тут пока ничего лучше не придумали, как openvpn. Запихиваю в /etc/resolv.conf временный адрес DNS сервера и начинаю

yum -y install epel-release mc
yum -y install openvpn easy-rsa

Меняю конфиги openvpn

cat server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 172.16.101.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 172.16.0.0 255.255.0.0"
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 172.16.100.2"
;push "dhcp-option DOMAIN ka12.co"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 3

Обратите внимание, специально закомментировал некоторые строки, которые понадобятся в будущем. Теперь генерирую ключи

mkdir -p /etc/openvpn/easy-rsa/keys
cp -rf /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa
mcedit /etc/openvpn/easy-rsa/vars
cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
cd /etc/openvpn/easy-rsa/keys
cp dh2048.pem ca.crt server.crt server.key /etc/openvpn
cd /etc/openvpn/easy-rsa
./build-key client

Разрешаю форвардинг

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

и запускаю openvpn

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

так как там все по умолчанию, очищаю правила фаерволла на виртуалке

iptables -F

Все, теперь на хосте надо открыть порт 1194/udp и пробросить его на виртуалку

-A PREROUTING -d x.x.x.x/32 -i eth0 -p udp --dport 1194 -j DNAT --to-destination 172.16.100.2
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

Добавляю роутинг до подсети vpn

ip route add 172.16.101.0/24 via 172.16.100.2

cat > /etc/sysconfig/network-scripts/route-virbr100
172.16.101.0/24 via 172.16.100.2 dev virbr100

Делаю темплейт клиентского конфига

cat client.template
client
dev tun
proto udp
remote vpn.ka12.co 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
key-direction 1
remote-cert-tls server
mssfix
<ca>
ca.crt
</ca>
<cert>
client.crt
</cert>
<key>
client.key
</key>
<tls-auth>
ta.key
</tls-auth>

И заполняю его (в дальнейшем я сделал маленький скрипт gen_config.sh)

sed -e '/ca.crt/rca.crt' -e '/client.crt/reasy-rsa/keys/client.crt' -e '/client.key/reasy-rsa/keys/client.key' -e '/ta.key/rta.key' -e '/crt/d' -e '/\.key/d' client.template | sed -e 's/#.*$//' -e '/^$/d' > cl.ovpn

Цепляюсь и проверяю доступность хоста через vpn

traceroute 172.16.100.1
traceroute to 172.16.100.1 (172.16.100.1), 64 hops max, 52 byte packets
1 172.16.101.1 (172.16.101.1) 53.941 ms 48.797 ms 47.938 ms
2 172.16.100.1 (172.16.100.1) 49.186 ms !Z 48.813 ms !Z 49.865 ms !Z

Пробрасываю ключ, бутстраплю виртуалку и ставлю в ней FreeIPA
ssh-copy-id root@172.16.100.2

ansible-playbook -i inventory -l head.ka12.co centos-bootstrap.yml

yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns

ipa-server-install --setup-dns --mkhomedir --allow-zone-overlap

Меняю шелл по умолчанию

kinit admin
ipa config-mod --defaultshell=/bin/bash

Внезапно оказалось, что FreeIPA с 1 гигом памяти стартует очень тяжко. Добавляю памяти

virsh setmaxmem head.ka12.co 4G --config
virsh setmem head.ka12.co 2G --config

И включаю VPN на полную

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 172.16.100.2"
push "dhcp-option DOMAIN ka12.co"

Добавляю pam сервис

cd /etc/pam.d/
ln -s system-auth openvpn

Добавляю группу openvpn и sshd и заношу в нее меня. В принципе все тоже самое можно сделать через веб-интерфес FreeIPA.

ipa hbacsvc-add openvpn
ipa hbacrule-add allow_openvpn
ipa hbacrule-add-service allow_openvpn --hbacsvcs=openvpn
ipa hbacrule-add-user allow_openvpn --user=kiltum
ipa hbacrule-add-service allow_sshd --hbacsvcs=sshd
ipa hbacrule-add-user allow_sshd --user=kiltum
ipa hbacrule-add-host allow_sshd --hosts=head.ka12.co
ipa hbactest --user=kiltum --host=head.ka12.co --service=sshd

Теперь остался последний шаг. Добавляю в конфиг сервера

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

а в конфиг клиента

auth-user-pass

И всё.

В случае проблем проверить работу авторизации можно и прямо на стороне сервера:

pamtester openvpn kiltum authenticate

Что же получил на данном этапе?

1. Хост, на котором крутится только KVM и больше ничего. А значит: ошибиться негде, ломать тоже особо нечего.
2. OpenVPN, доступ до которого защищен сразу двумя методами: клиентским сертификатом и логином-паролем.
3. Внутренний DNS, который снаружи никак не виден.
4. Управление пользователями/группами/сервисами. Располагается исключительно во внутренней сети.
5. Даже если опустить везде фаирволлы, то ничего нового не будет доступно снаружи.

CentOS 7 80×24

Новые инсталляции CentOS раздражают тем, что по умолчанию переключают экран в большое разрешение. Даже для текстовой консоли. Лично мне это неудобно, ибо 99% машин у меня в виртуалках …

Решение простое

- vi /etc/default/grub # удалить ‘rhgb quiet’, добавить ‘nomodeset’
- grub2-mkconfig -o /boot/grub2/grub.cfg
- reboot

Игрища с сервером – 3 или openvpn и ipv6

Сделав очередной openvpn сервер, я задался вопросом: а нафига я его вообще делал? Нет, что бы добираться безопасно до своих ресурсов, это да. Но одна из главных задач – дать клиенту ipv6 в мире ipv4. И именно её он не выполняет. Значит сейчас починим.

Самый простой вариант “в лоб” – перевести сервер в бридж режим и пусть клиенты будут представляться хост-машине как еще одни виртуалки. Минус – замучаюсь с безопасностью. Плюс – тупо и надежно.

Вариант посложнее – выпилить кусочек ipv6 сети и давать её клиентам. Минус тут один – некоторые клиенты почему-то желают видеть у себя /64 и никак иначе. А у меня всего одна /64. Нет, можно получить еще через любого туннельного брокера, но не хочу.

Значит вариант остается один: взять приватную ipv6 подсеть и сделать раздачу из него. Для выбора сетки мы можем брать все что нам понравится, главное что бы первый байт адреса был fd. Вот тут можно даже побаловаться, просто обновляя страничку.

Я возьму для своих крамольных целей сеть fdab:cdef:1234:5678::/64

Почитав маны, добавляю следующие строчки в конфиг сервера

server-ipv6 fdab:cdef:1234:5678::/64
tun-ipv6
push tun-ipv6

И перезагружаю сервер

systemctl restart openvpn@server.service

Переподключаю клиента и смотрю в логи. Вижу заветную строку.

Fri Jan 29 03:12:31 2016 /usr/sbin/ip addr add dev tun0 local 10.100.2.6 peer 10.100.2.5
Fri Jan 29 03:12:31 2016 /usr/sbin/ip -6 addr add fdab:cdef:1234:5678::1000/64 dev tun0
Fri Jan 29 03:12:31 2016 /usr/sbin/ip route add 10.100.0.0/24 via 10.100.2.5

Пробую с клиента пингануть сервер

$ ping6 fdab:cdef:1234:5678::1 -c 2
PING fdab:cdef:1234:5678::1(fdab:cdef:1234:5678::1) 56 data bytes
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=1 ttl=64 time=48.1 ms
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=2 ttl=64 time=48.2 ms

Работает! Теперь осталось самая мелочь – запушить правило роутинга, адрес ДНС и собственно роутинг сделать.

Строчка конфига

push "route-ipv6 2000::/3"

Заставит маршрутизировать весь ipv6 трафик через openvpn. Почти как redirect-gateway def1, но только для ipv6.

Но так как у нас приватная сеть, то я могу пинговать только openvpn. Другие хосты согласно правилам хорошего тона, такие поползновения обламывают.

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

systemctl stop firewalld
yum -y install iptables-services
systemctl enable iptables
systemctl enable ip6tables
systemctl start iptables
systemctl start ip6tables

Добавляем правила для SNAT и открываем 1194/udp на вход
-A POSTROUTING -s 10.100.2.0/24 -o eth0 -j SNAT --to-source 10.100.0.133
-A POSTROUTING -s fdab:cdef:1234:5678::/64 -o eth0 -j SNAT --to-source 2a01:4f8:171:1a43:5054:ff:fe0d:da49

-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

И удаляем мешающееся

-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Теперь последний шаг – sysctl.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding=1

То, что надо перечитать – перечитываем, то, что надо перезагрузить – перезагружаем.

Если все сделано правильно, клиент VPN начнет пинговать внешние ipv6 ресурсы. traceroute у меня почему-то обламывался на первом же хопе. Посмотрел tcpdump – видимо, не до конца допилили модуль, отвечающий за NAT: адреса не переписываются. Но с другой стороны – ну и пофиг: если очень надо, то я смогу зайти прямо на хост.

Последняя проверка: а файлики-то клиент утащит?

$ wget -6 google.com
--2016-01-29 04:07:49-- http://google.com/
Resolving google.com (google.com)... 2607:f8b0:4005:800::1002
Connecting to google.com (google.com)|2607:f8b0:4005:800::1002|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw [following]
--2016-01-29 04:07:49-- http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw
Resolving www.google.de (www.google.de)... 2607:f8b0:4010:800::101f
Connecting to www.google.de (www.google.de)|2607:f8b0:4010:800::101f|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

[ <=> ] 19,066 97.8KB/s in 0.2s

2016-01-29 04:07:50 (97.8 KB/s) - ‘index.html’ saved [19066]

Утащил!

Значит, можно удовлетворенно потирать руки и идти спать

Игрища с сервером – 2 (openvpn, ssh и freeipa)

Наконец-то можно приступить к самому приятному: выбиванию окон во внешний мир. Или VPN. Ответы на вопросы зачем, почему и куда оставлю за рамками. Мне надо и все тут. Для организации канала буду использовать широко известный openvpn.

Ставим удобности.

yum -y install epel-release mc

Для начала подниму для проверки просто сервер. Без каких-либо излишеств.

yum -y install openvpn easy-rsa
cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn
mcedit /etc/openvpn/server.conf

Конфиг после удаления лишнего получился примерно такой

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.100.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.100.0.0 255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.100.0.10"
push "dhcp-option DOMAIN local.multik.org"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 3

Полностью по мануалу, без каких-либо отклонений. Значение каждой строчки можно посмотреть в документации.

Теперь ключи. Опять же, не отходя от канонов.

mkdir -p /etc/openvpn/easy-rsa/keys
cp -rf /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa
mcedit /etc/openvpn/easy-rsa/vars

Тут я поправил строки “по умолчанию”

export KEY_COUNTRY="RU"
export KEY_PROVINCE="RU"
export KEY_CITY="Moscow"
export KEY_ORG="VseMoe"
export KEY_EMAIL="multik@multik.org"
export KEY_OU="Internet"
...
export KEY_NAME="Server"
...
export KEY_CN="vpn.vsemoe.com"

Дальше просто лог команд, везде давим Enter.

cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
cd /etc/openvpn/easy-rsa/keys
cp dh2048.pem ca.crt server.crt server.key /etc/openvpn
cd /etc/openvpn/easy-rsa
./build-key client

Разрешаем форвард

mcedit /etc/sysctl.conf
net.ipv4.ip_forward = 1
sysctl -p

И стартуем сервер

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

Теперь на хосте надо открыть порт 1194/udp и перебросить его на виртуалку с openvpn

-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
-A PREROUTING -d 136.243.151.196/32 -i eth0 -p udp --dport 1194 -j DNAT --to-destination 10.100.0.133

И на самой виртуалке открыть тем или иным образом порт

firewall-cmd --add-service=openvpn --permanent
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

Теперь перетаскиваем на клиента все client* файлы и ca.crt и делаем конфиг (обычный текстовый файл)

client
dev tun
proto udp
remote 136.243.151.196 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
ca ca.crt
cert client.crt
key client.key

Пробуем соедениться

$ sudo openvpn --config confif.vpn
Wed Jan 27 03:55:22 2016 OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Wed Jan 27 03:55:22 2016 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Wed Jan 27 03:55:22 2016 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Jan 27 03:55:22 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Wed Jan 27 03:55:22 2016 UDPv4 link local: [undef]
Wed Jan 27 03:55:22 2016 UDPv4 link remote: [AF_INET]136.243.151.196:1194
Wed Jan 27 03:55:22 2016 TLS: Initial packet from [AF_INET]136.243.151.196:1194, sid=3dd59a35 34ce24da
Wed Jan 27 03:55:22 2016 VERIFY OK: depth=1, C=RU, ST=RU, L=Moscow, O=VseMoe, OU=Internet, CN=vpn.vsemoe.com, name=Server, emailAddress=multik@multik.org
Wed Jan 27 03:55:22 2016 VERIFY OK: depth=0, C=RU, ST=RU, L=Moscow, O=VseMoe, OU=Internet, CN=server, name=Server, emailAddress=multik@multik.org
Wed Jan 27 03:55:23 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 27 03:55:23 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 27 03:55:23 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 27 03:55:23 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 27 03:55:23 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Jan 27 03:55:23 2016 [server] Peer Connection Initiated with [AF_INET]136.243.151.196:1194
Wed Jan 27 03:55:25 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jan 27 03:55:25 2016 PUSH: Received control message: 'PUSH_REPLY,route 10.100.0.0 255.255.255.0,dhcp-option DNS 10.100.0.10,route 10.100.2.1,topology net30,ping 10,ping-restart 120,ifconfig 10.100.2.14 10.100.2.13'
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: route options modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jan 27 03:55:25 2016 ROUTE_GATEWAY 172.16.137.2/255.255.255.0 IFACE=eno16777736 HWADDR=00:0c:29:fa:0a:54
Wed Jan 27 03:55:25 2016 TUN/TAP device tun1 opened
Wed Jan 27 03:55:25 2016 TUN/TAP TX queue length set to 100
Wed Jan 27 03:55:25 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jan 27 03:55:25 2016 /usr/sbin/ip link set dev tun1 up mtu 1500
Wed Jan 27 03:55:25 2016 /usr/sbin/ip addr add dev tun1 local 10.100.2.14 peer 10.100.2.13
Wed Jan 27 03:55:25 2016 /usr/sbin/ip route add 10.100.0.0/24 via 10.100.2.13
Wed Jan 27 03:55:25 2016 /usr/sbin/ip route add 10.100.2.1/32 via 10.100.2.13
Wed Jan 27 03:55:25 2016 Initialization Sequence Completed

Как видно по последней строчке, соединение установилось. Пробуем добраться до любого хоста “внутри” сети.

$ ssh root@10.100.0.10
ssh: connect to host 10.100.0.10 port 22: No route to host

Облом. По простой причине – ничего в сети 10.100.0 не знает про сеть 10.100.2, которую я отдал под VPN. Самое простое решение – включить маскарадинг на выходе

firewall-cmd --permanent --add-masquerade
firewall-cmd --reload

Пробую еще раз

$ ssh root@10.100.0.10
The authenticity of host '10.100.0.10 (10.100.0.10)' can't be established.
ECDSA key fingerprint is fb:c1:72:a2:9a:a1:df:f5:d0:95:09:a4:3b:2e:9d:68.

Сработало. Это хорошо. Теперь немного добавим безопасности путем добавление пре-авторизационного ключа. Опять же, по мануалу

openvpn --genkey --secret ta.key
tls-auth ta.key 0

В принципе, тут можно остановиться. Сервер работает, создаешь по ключу на клиента и вперед. Но мне так не охота. Я хочу сделать так, что бы конфигурационный файл был у всех одинаковый, а пользователи авторизовались по классическому логину и паролю. А логины и пароли брались бы из FreeIPA.

Опять же, вариантов много. Самый распространенный – это использование freeipa как ldap сервера. Мне лично лень. Я решил воспользоваться вариантом, когда freeipa авторизует пользователей в системе (так как это стандартный способ), а openvpn авторизовать уже через пользователей в системе.

Ставим на vpn все необходимое и подключаемся к ипе (подробности в ранних постах).

yum install -y ipa-client
ipa-client-install --mkhomedir

И тут оно обламывается. По простой причине – для vpn.local.multik.org нет адреса в базе. А у машины два локальных интерфейса и какой использовать для чего – непонятно.

Идем в виртуалку с ipa и добавляем

[root@ipa ~]# kinit admin
Password for admin@LOCAL.MULTIK.ORG:
[root@ipa ~]# ipa dnsrecord-add
Record name: vpn
Zone name: local.multik.org
Please choose a type of DNS resource record to be added
The most common types for this type of zone are: A, AAAA

DNS resource record type: A
A IP Address: 10.100.0.133
Record name: vpn
A record: 10.100.0.133

И снова пробуем – теперь все получится.

Теперь небольшой трюк. Что бы не давать по умолчанию доступ до VPN всем, я создам новый “сервис”.

cd /etc/pam.d/
ln -s system-auth openvpn

Теперь Осталось мелочь – создать в ипе HBAC сервис openvpn и установить правила. Создаем сервис, группу для него и соединяем вместе

[root@ipa ~]# ipa hbacsvc-add openvpn
----------------------------
Added HBAC service "openvpn"
----------------------------
Service name: openvpn

[root@ipa ~]# ipa hbacrule-add allow_openvpn
-------------------------------
Added HBAC rule "allow_openvpn"
-------------------------------
Rule name: allow_openvpn
Enabled: TRUE

[root@ipa ~]# ipa hbacrule-add-service allow_openvpn --hbacsvcs=openvpn
Rule name: allow_openvpn
Enabled: TRUE
Services: openvpn
-------------------------
Number of members added 1
-------------------------

Проверяю, что натворил.

[root@ipa ~]# ipa hbacrule-find allow_openvpn
-------------------
1 HBAC rule matched
-------------------
Rule name: allow_openvpn
Enabled: TRUE
Services: openvpn
----------------------------
Number of entries returned 1
----------------------------

Добавляю к правилу пользователя и хост

[root@ipa ~]# ipa hbacrule-add-user allow_openvpn --user=multik
Rule name: allow_openvpn
Enabled: TRUE
Users: multik
Services: openvpn
-------------------------
Number of members added 1
-------------------------

[root@ipa ~]# ipa hbacrule-add-host allow_openvpn --hosts=vpn.local.multik.org
Rule name: allow_openvpn
Enabled: TRUE
Users: multik
Hosts: vpn.local.multik.org
Services: openvpn
-------------------------
Number of members added 1
-------------------------

Проверяю, что сработает на меня и на админа (который вроде как и не должен иметь доступ)

[root@ipa ~]# ipa hbactest --user=admin --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: allow_openvpn

[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Matched rules: allow_openvpn

Как вижу, в системе есть правило по умолчанию, которое дает доступ всем до всего. Но если его просто выкусить, то я тупо лишусь доступа И по ssh тоже. Поэтому надо сделать аналогичное для ssh

[root@ipa pam.d]# cd
[root@ipa ~]# ipa hbacsvc-add sshd
ipa: ERROR: HBAC service with name "sshd" already exists

Опс, сервис такой уже по умолчанию есть. Ну пойду дальше

[root@ipa ~]# ipa hbacrule-add allow_sshd
----------------------------
Added HBAC rule "allow_sshd"
----------------------------
Rule name: allow_sshd
Enabled: TRUE
[root@ipa ~]# ipa hbacrule-add-service allow_sshd --hbacsvcs=sshd
Rule name: allow_sshd
Enabled: TRUE
Services: sshd
-------------------------
Number of members added 1
-------------------------
[root@ipa ~]#

ipa hbacrule-add-user allow_sshd --user=multik
ipa hbacrule-add-host allow_sshd --hosts=vpn.local.multik.org

Проверяю

[root@ipa ~]# ipa hbactest --user=admin --host=vpn.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: allow_openvpn
Not matched rules: allow_sshd
[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Matched rules: allow_sshd
Not matched rules: allow_openvpn

Все на месте. Выкусываю нафиг
[root@ipa ~]# ipa hbacrule-disable allow_all
------------------------------
Disabled HBAC rule "allow_all"
------------------------------

Согласно выводу выше, я теперь не могу залогиниться на хост vsemoe-com пользователем multik.

[root@ipa ~]# ssh multik@vsemoe-com
multik@vsemoe-com's password:
Connection closed by UNKNOWN

Не соврала система. “Не пущаит”. Проверяю почему

[root@ipa ~]# ipa hbactest --user=multik --host=vsemoe-com.local.multik.org --service=sshd
---------------------
Access granted: False
---------------------
Not matched rules: allow_openvpn
Not matched rules: allow_sshd

Добавляю хост, как разрешенный к коннекту на него по ssh

[root@ipa ~]# ipa hbacrule-add-host allow_sshd --hosts=vsemoe-com.local.multik.org
Rule name: allow_sshd
Enabled: TRUE
Users: multik
Hosts: vpn.local.multik.org, vsemoe-com.local.multik.org
Services: sshd
-------------------------
Number of members added 1
-------------------------

Будет пускать?

[root@ipa ~]# ipa hbactest --user=multik --host=vsemoe-com.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_sshd
Not matched rules: allow_openvpn

Должно. Проверяю

[root@ipa ~]# ssh multik@vsemoe-com
multik@vsemoe-com's password:
Last failed login: Thu Jan 28 12:53:43 MSK 2016 from 2a01:4f8:171:1a43:5054:ff:fea4:8c6 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Mon Jan 25 16:51:46 2016 from 10.100.0.254

Как говорится, работает. Теперь последняя проверка: пустит ли пользователя multik на хосте vpn для сервиса openvpn?

[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_openvpn
Not matched rules: allow_sshd

Для vpn пустит, а по ssh не пустит. Теперь остались сущие мелочи. Добавялем в конфиг сервера

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

а в конфиг клиента

auth-user-pass

и пробуем

$ sudo openvpn --config confif.vpn
Thu Jan 28 04:57:42 2016 OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Thu Jan 28 04:57:42 2016 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Enter Auth Username: ******
Enter Auth Password: ***********

Как видим, спросило логин и пароль. И дальше как обычно. Но каждый раз вводить логин и пароль лень. Всякие ViscoCity и прочие умеют это. Научим и консольного клиента.

Сделаем обычный текстовый файлик из 2х строчек: логина и пароля. И укажем его имя сразу после auth-user-pass. Если все сделано правильно, то openvpn ничего не будет спрашивать, а просто возьмет и прицепится.

Теоретически, на этом можно и закончить процесс. Но некрасиво как-то. “Клиентами” моего сервиса будут люди, далекие от техники. Дизайнеры всякие и менеджеры. Пока им объяснишь, чего куда совать и на что нажимать …

Технология очень простая. Берем исходный конфиг для клиента, и добавляем к нему следующие строки

key-direction 1

<ca>
—–BEGIN CERTIFICATE—–
ca.crt
—–END CERTIFICATE—–
</ca>

<cert>
—–BEGIN CERTIFICATE—–
client.crt
—–END CERTIFICATE—–
</cert>

<key>
—–BEGIN PRIVATE KEY—–
client.key
—–END PRIVATE KEY—–
</key>

<tls-auth>
—–BEGIN OpenVPN Static key V1—–
ta.key
—–END OpenVPN Static key V1—–
</tls-auth>

Внутрь просто копируем содержимое соответствующих файлов. Любым текстовым редактором. Ну и убираем строки

ca ca.crt
cert client.crt
key client.key

Полученному файлу надо поставить расширение ovpn и его магическим образом станут понимать практически все системы, заявляющие о поддержке openvpn.

Всё. Я получил в свое распоряжение VPN сервер. Управляемый хоть из консоли, хоть из веб-морды (как? я не писал? сходите браузером на адрес ipa сервера). Ну вообще-то не только VPN сервер, но в этой рассказке я писал только про VPN.

Удачи!

Новый сервер с игрищами и блудницами – 5

Или баррикадируемся от подборщиков паролей.

Захожу я утром на свой сервер, а мне добрая система сообщает

Last failed login: Sat Jan 23 10:23:49 MSK 2016 from 183.3.202.106 on ssh:notty
There were 5278 failed login attempts since the last successful login.

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

-A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP
-A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
#-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Как это работает, можно почитать на хабре в комментах.

Поглядел в логи – ляпота и чистота.

Теперь (лично мне) надо поставить 6ю центось. Надо по двум причинам: попробовать графическую консоль (ибо в полном тексте как 7я оно не ставится), и надо для OpenVZ, у которой опять же с 7й еще есть проблемы.

Поначалу я попробовал SPICE, предлагаемый по умолчанию. Тормозит дико. Даже на толстых каналах. Плюс клиентов нет под всякие разные операционки. Попробовал vnc – вот это другое дело. Не скажу, что прямо как “на настоящем”, но работать вполне можно.

virt-install --name openvz --ram 8912 --disk path=/vm/openvz.qcow2,size=8,bus=virtio,cache=none --vcpus 4 --os-type linux --network bridge=virbr0,model=virtio -c /vm/iso/CentOS-6.7-x86_64-minimal.iso --accelerate --noautoconsole --graphics vnc,password=test,listen=10.100.0.254 -v --input tablet,bus=usb

Теперь ssh -L 5900:10.100.0.254:5900 root@host и любым VNC клиентом на 127.0.0.1:5900. Пароль, как видно из команды – test. Просто, удобно и понятно.

Но мне понравилось, что можно в машину забраться и через virsh console. В винтуальной машине делаем

cat /etc/init/ttyS0.conf
stop on runlevel[016]
start on runlevel[345]
respawn
instance /dev/ttyS0
exec /sbin/mingetty /dev/ttyS0

В самый конец /etc/securetty добавляем
ttyS0

И запускаем

initctl start ttyS0

И в общем, должны попасть через virsh console. Для логов загрузки, для kernel в /etc/grub.conf добавляем

console=ttyS0

У меня все получилось. Дальше иду как написано в вики OpenVZ. Ставлю, мигрирую и так далее.