Godless, да, на очень больших размерах ACL потеря производительности будет ощутимой. Я в такой ситуации использовал rejic. Там бинарные базы, они работают существенно быстрее. Но производительность сквида у меня стала проблемой на объёмах порядка десятков тысяч ACE в списках -- реализовывали блокировки РКН на базе Squid. Для сотни-другой-третьей записей в ACL, я думаю, встроенного механизма вполне хватит.
Рональд Макдональд, не путайте сервера в более или менее защищённых окружениях, смотрящие в интернет, и домашний компик, который высунули наружу без какой-либо вменяемой защиты. Он намотает на винты минут за 5-10.
anton13ms, сложность в том, во-первых, нужно делать пачку зеркал -- на бутовые разделы и на последующий(-ие) раздел(ы) с LVM. Во-вторых -- что раздел /boot/EFI не зеркалируется вообще, в принципе. И нужно мутить костыли, обеспечивающие его синхронизацию между двумя физическими дисками. И в третьих -- нужно знать, что собирать RAID нужно с metadata версии 1.0, чтобы метаданные mdadm писал не в начале диска, а в конце.
Короче, тот ещё геморрой. В отличие от упомянутого мной выше gmirror на фре, который просто делает полную копию блочного устройства -- т. е. всего диска целиком. И можешь пилить его на разделы как угодно, в каких угодно вариациях, диски сами зеркалируются автоматом, никаких костылей.
Если альтернатива между линуксовым mdadm и аппаратным рейдом -- я бы выбрал нормальный аппаратный, типа LSI 92xx серии. Вон они на авите по 2000-2500 рублей продаются: https://www.avito.ru/ramenskoe/tovary_dlya_kompyut...
Посмотрите. Процедура настройки загрузки с md RAID1 на компе с UEFI. Ну и зеркалирование по разделам (а не целиком блочного устройства, как это позволяет сделать gmirror во фре, например) в 21-ом веке -- это ну такоэ...
Да, только нормально зеркалировать загрузочный диск через mdadm невозможно. Почитайте на досуге, какие танцы приходится танцевать, чтобы это хоть как-то зеркалировалось, особенно в части, касающейся boot и /boot/EFI разделов.
Это как? :-) В сети 4.5.1.0/30 всего 4 адреса. И 4.5.1.12 туда точно не входит. Такая же история про ether2 -- то, что у вас указано как network, не попдает в подсеть на интерфейсе.
WebDev, если у вас TLS уже есть, то зачем вообще генерировать какие-то ключи? При настройке TLS у сервера по-любому уже должен быть серверный сертификат. Вам остаётся только в настройках сервера указать, что нужно требовать от клиента его клиентский сертификат, и сгенерировать сертификат для клиента, который он будет предъявлять при установке TLS-сессии.
А товарища выше не слушайте, он вообще не в теме, как работает TLS, хотя и утверждет, что читал стандарты.
WebDev, ну во-первых, вы путаете аутентификацию и авторизацию. Это два разных процесса. То, что нужно конкретно вам в данном случае называется "аутентификация". Авторизация -- это про определение того, куда можно аутентифицированному пользователю ходить и что там делать.
Во-вторых, чтобы "просто отдавать данные только своим серверам", как раз и нужна аутентификация. Т. е. сервер статистики должен как-то уметь отличать "свои" сервера от чужих. Для этого "свои" сервера должны как-то себя обозначить, а сервер статистики должен это проверить по каким-то критериям.
В самом простом случае -- это белый список на файрволе, где сервер "предъявляет" свой source IP. Ну, по факту, отдельного никакого предъявления там нет, просто файрвол проверяет IP источника. Но в контексте аутентификации можно рассуждать и так.
Альтернативной схемой аутентификации, которая довольно просто прикручивается, является взаимная аутентификация по сертификатам. Т. е. при подключении клиента, сервер предъявляет свой сертификат, а клиент проверяет -- может он доверять этому сертификату (выписан ли он доверенным удостоверяющим центром), или нет. И затем сервер может запросить клиентский сертификат (в общем случае это опционально, но в вашем случае нужно настроить это обязательным). Тогда клиент должен предъявить свой сертификат, и сервер проверит его по своему списку УЦ, которым доверяет сам сервер. Если всё ОК, то идёт дальнейшее согласование сессии и соединение устанавливается, и вот уже там всё происходит. Именно так работает протокол TLS. Также в рамках этого протокола устанавливается шифрованый канал. Вы утверждаете, что шифрование вам не нужно. Ну ОК, ттолько получается, что кто угодно может подсмотреть идущий по открытому каналу трафик и потом прикинуться вашим сервером (допустим, вы как-то прикрутили парольную аутентификацию между API сервером и сервером статистики), и без проблем гонять запросы к вашему серверу статистики в обход серверов API.
не передаю никаких данных
Вы шутите, что ли? API сервер "дёргает сервер статистики" -- это что, не требует установки соединения, передачи запроса и получения ответа от сервера статистики? А что тогда "передача данных", по вашему?
Вы постановку задачи-то прочитайте сначала. А то неловко как-то получается -- выглядит так, как будто вы с голосами в собственной голове разговариваете.
Задача -- обеспечить возможность получения статистики только от серверов с API-шлюзами, не прибегая при этом к ограничению подключений на уровне IP-адресов. При чём тут пользователи вообще? Пользователями API-шлюз целиком занимается.
Также, пассаж про "симметричное/асимметричное" выдаёт ваше полное незнакомство с сутью TLS, и как там обеспечивается взаимная аутентификация и шифрование трафика. Стыдно, товарищ.
А чем можно воспользоваться -- я уже говорил выше. Я использовал rejik. Вроде как проект ещё жив, и у них тоже есть готовые списки ACL.