Haproxy на centos 7. установка и настройка прокси сетевого трафика

HAProxy на CentOS 7. Установка и настройка прокси сетевого трафика

Опубликовано: 23.04.2018

Тематические термины: Haproxy, CentOS

Несмотря на то, что инструкция применима для Linux CentOS, настройка HAProxy применима для других систем, например Ubuntu.

Установка

HAProxy присутствует в репозитории CentOS и может быть установлен командой:

Разрешим автозапуск сервиса и запустим его:

На этом установка и запуск закончены.

Принцип настройки

Конфигурирование HAProxy выполняется в файле /etc/haproxy/haproxy.cfg. Все основные настройки находятся в 4-х секциях:

  1. global. Глобальные настройки, распространяемые на все публикации.
  2. defaults. Настройки, применяемые по умолчанию, если они не указаны явно в публикации.
  3. frontend. Правила обработки запросов, приходящих на сервер и передачи этих запросов серверам backend. Может быть несколько.
  4. backend. Настройка конечных серверов, которые обрабатывают запросы и возвращают результаты. Может быть несколько.

Также есть возможность создать дополнительные секции, например userlist.

Настройка frontend

При настройке прослушивания внешних запросов, основное, что мы указываем:

  • IP-адрес и порт прослушивания.
  • Правила, по которым обрабатываются запросы.
  • Группы серверов, на которые будет перекинут запрос.

Пример:

frontend balance_http     bind 192.168.0.15:80     acl url_stat       path_end       -i .css .js     use_backend static          if url_stat

    default_backend webserver

* в данном случае мы слушаем веб-запросы и если они идут на файлы с расширениями .css или .js, передаем запрос на бэкэнд с название static. Все остальные запросы передаем на бэкэнд webserver.
* где balance_http — название фронтэнда; bind 192.168.0.

15:80 — слушаем на адресе 192.168.0.

15, порту 80; url_stat — название правила; use_backend static   if url_stat — правило обработки, при котором запросы, попавшие под действие правила url_stat, должны быть обработаны бэкэндом static; default_backend — указывает, какой бэкэнд будет использоваться по умолчанию.

Настройка backend

При настройке указываем:

  1. Как распределяется нагрузка между серверами. Доступны варианты:
    • roundrobin — серверы используются по очереди. Нагрузка распространяется равномерно, в зависимости от указанного веса. Вес может быть изменен на лету.
    • static-rr — серверы используются по очереди. Нагрузка распространяется равномерно, в зависимости от указанного веса. Вес не может быть изменен на лету.
    • lessconn — запросы идут к серверу с наименьшим количеством активных подключений.
    • source — запросы от одного и того же IP-адреса идут на один и тот же сервер.
    • uri — запросы с одним и тем же URL (до знака вопроса) будут переправляться на один и тот же сервер.
    • url_param — запросы с одинаковыми параметрами GET (все, что после знака вопроса) будут переправляться на один и тот же сервер.
  2. На какие именно серверы передавать запросы.

Пример:

backend webserver     balance     roundrobin     server  server1 192.168.0.20:80 check

    server  server2 192.168.0.30:80 check

* где webserver — название бэкэнда; balance — опция определения алгоритма распределения запросов между серверами; server — указывает имя и IP-адрес сервера, на который передается запрос; check  — указываем, что необходимо проверять состояние сервера.
* для работы достаточно и одного сервера, но несколько добавят отказоустойчивости. 

После внесения изменений в настройку HAProxy, необходимо перезапустить сервис:

systemctl restart haproxy

или просто перечитать настройки:

Брандмауэр

Для корректной работы сервера, не забываем открывать соответствующие порты. Например, для обработки http и https запросов вводим следующие команды:

firewall-cmd —permanent —add-port=80/tcp

firewall-cmd —permanent —add-port=443/tcp

Подробнее про настройку брандмауэра в Linux при помощи firewalld и iptables.

Примеры использования

Рассмотрим часто встречаемые варианты использования HAProxy.

1. HTTPS запросы

Frontend:

frontend https-frontend     bind *:443 ssl crt /etc/ssl/domaincert.pem     reqadd X-Forwarded-Proto: https

    default_backend https-backend

* где https-frontend — название фронтэнда; bind *:443 — сервер слушает на всех IP-адресах на порту 443 (https); /etc/ssl/domaincert.pem — файл, в котором хранятся алгоритмы для закрытого и открытого ключей; https-backend — бэкэнд, на который будут отправляться запросы.

Backend:

backend https-backend     redirect scheme https if !{ ssl_fc }     server s1 192.168.0.20:80 check

    server s2 192.168.0.30:80 check

* где https-backend — название бэкэнда; s1 и s2 — название серверов, на которые переправляем запросы; 192.168.0.20 и 192.168.0.30 — IP-адреса серверов, на которые переправляем запросы.

2. Распределение запросов по весу (weight)

Если необходимо на определенный сервер отправлять больше запросов, можно применить weight при настройке бэкэнда:

backend weight-backend     …     server server1 192.168.0.20:80 weight 100

    server server2 192.168.0.30:80 weight 80

* в данном примере запросы будут отправляться чаще на сервер server1.

3. Поддержка sticky session

Поддержка sticky session позволит перенаправлять http-запросы пользователя всегда на один и тот же сервер. Это необходимо в том случае, когда не предусмотрен механизм хранения PHP-сессий в общем каталоге.

backend sticky-backend     …     server server1 192.168.0.20:80 cookie check

    server server2 192.168.0.30:80 cookie check

4. Защита паролем

Сделаем необходимость вводить пароль при подключении к серверу.

Сначала получим хэш пароля:

echo -n 'password' | md5sum

В конфиге haproxy создаем список пользователей (отдельная секция):

userlist http-users
    user user1 password 5f4dcc3b5aa765d61d8327deb882cf99

* где http-users — название списка пользователей; user1 — имя пользователя; 5f4dcc3b5aa765d61d8327deb882cf99 — хэш пароля.

В бэкэнде:

backend web-servers     …     acl AuthAccept http_auth(http-users)

    http-request auth realm AcmeCorp if !AuthAccept

Дополнительные настройки

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

Логирование

Открываем конфигурационный файл:

vi /etc/haproxy/haproxy.cfg

Проверяем наличие следующей строки в секции global:

global     …

    log         127.0.0.1 local2

* при ее отсутствии, добавляем.

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

vi /etc/rsyslog.d/haproxy.conf

local2.* /var/log/haproxy.log

Перезапускаем rsyslog:

systemctl restart rsyslog

Постоянное HTTP-соединение

По аналогии с keep-alive у NGINX и Apache. В новых версиях HAProxy настроено по умолчанию. В случае необходимости настройки таймаута, в секции defaults правим:

defaults     …     option http-server-close

    timeout http-keep-alive 10s

Была ли полезна вам эта инструкция?

Да            Нет

Источник: https://www.dmosk.ru/miniinstruktions.php?mini=haproxy-centos7

Установка HAProxy на Linux (Debian/Ubuntu или CentOS/RedHat)

My HAProxy Test Page

Welcome to HA Proxy test page!

There should be more here, but I don't know what to be write :p. Made 25 Jane 2015
by captain.

Так же можно использовать следующий php скрипт cо следующим содержанием:

После создания «index.html» файл, попытаемся получить доступ к сайту.

Session Stickiness

Если ваш веб-приложение служит динамическое содержимое на основе сеансов входа пользователей, посетители будут испытывать странные вещи из-за непрерывного переключения между VPS. «Session Stickiness» гарантирует, то что посетитель будет иметь свои куки наVPS.

Я приведу пример использования следующий PHP кода, чтобы продемонстрировать, как работает все это:

# vim /home/captain/HAproxy/session.php

добавляем:

Этот код создает PHP сессии и отобразит количество просмотров страниц за один сеанс.

И проверяем:

# curl -i http://1.1.1.1/session.php

После запуска haproxy с таким конфигурационным файлом вы можете в браузере открыть страничку http:///stats.

Проведен небольшой эксперимент. При помощи программы wget запросим страничку тысячу раз такой командой:

for i in `seq 1 1000`; do wget http://192.168.103.1 -O -; done

Включаем статистику HAProxy

HAProxy статистика дает много информации о переданных данных, общей связи, состояния сервера и т.д. после установки HAProxy, если вы хотите посмотреть в HAProxy статистику, то ее можно легко настроить.

Отредактируем конфиг балансировщика:

# vim /etc/haproxy/haproxy.cfg

И прописываем (добавляем в самый конец конфига):

[…] listen stats 192.168.103.1:1936 mode http log global maxconn 10 clitimeout 100s srvtimeout 100s contimeout 100s timeout queue 100s stats enable stats hide-version stats refresh 30s stats show-node stats auth user:password stats uri /haproxy?stats

Ваш может получить доступ к статистике используя HAProxy URL-адрес:

URL: http://192.168.103.193:1936/haproxy?stats login: user Пароль: password

статистика в haproxy

По желанию, можно изменить следующие параметры:

  • listen stats 192.168.103.1:1936 — это IP на котором будет отображаться статистика ( мой HAproxy) и порт, нужен для вывода статистике. Например:listen stats 192.168.103.1:8080
  • stats auth user:password, где user — это ваш пользователь и password — это пароль пользователя user. Например:stats auth captain:captain_password
  • stats uri /haproxy?stats — это ссылка по которой будет расположена статистика, ее можно изменить на любую другую. Например: — stats uri /stats— stats uri /haproxy-stats

На этом, моя тема «Установка HAProxy на Linux (Debian/Ubuntu или CentOS/RedHat)» подошла к завершению. Надеюсь было интересно и хорошо рассказано. Если есть Пожелания или замечания, пишите в комментариях.

Источник: https://linux-notes.org/ustanovka-haproxy-na-linux-debian-ubuntu-ili-centos-redhat/

Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux (CentOS)

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

Что такое балансировка нагрузки?

Балансировка нагрузки – это процесс распределения рабочих нагрузок на несколько серверов. Это похоже на распределение рабочих нагрузок между дневной сменой и ночной сменой работников в компании. Балансировка нагрузки повышает надежность сервера, поскольку она преодолевает одноточечный сбой.

Обработка трафика на одном сервере

В этом примере, если веб-сервер не работает, веб-запрос пользователя не может быть доступен в режиме реального времени.

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

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

В этой статье мы собираемся настроить балансировщик нагрузки для веб-сервера с помощью Nginx, HAProxy и Keepalived. Ниже показан пример того, как выглядят серверы с балансировщиками нагрузки.

Использование балансировки нагрузки для эффективной обработки высокого трафика

Итак, что такое Nginx, Haproxy и Keepalived?

nginx

Nginx, произносится как Engine-x является веб-сервером с открытым исходным кодом. Он больше, чем просто Веб-сервер, он может работать как обратный прокси-сервер, почтовый прокси-сервер, балансировщик нагрузки, легкий файловый сервер и кэш HTTP. Nginx был использован во многих популярных сайтах, таких как BitBucket, WordPress, Pinterest, Quora и GoDaddy.

HAProxy

HAProxy означает прокси высокой доступности. Это балансировщик нагрузки с открытым исходным кодом, который обеспечивает балансировку нагрузки, высокую доступность и прокси-решения для приложений на основе TCP и HTTP. Он лучше всего подходит для распределения рабочей нагрузки между несколькими серверами для повышения производительности и надежности серверов.

Функция Haproxy заключается в пересылке веб-запроса от конечного пользователя к одному из доступных веб-серверов. Он может использовать различные алгоритмы балансировки нагрузки как Round Robin, Least Connections  и т. д.

Keepalived

Что делать, если haproxy балансировки нагрузки упадет?

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

  • Уровень 4 (транспортный уровень)
  • Уровень 7 (прикладной уровень)
Читайте также:  Настройка ftp-серверов. частный мастер по настройке ftp сервера

Keepalived может выполнять следующие функции:

  • Проверка работоспособности (работают ли серверы или нет)
  • Реализует третий уровень (виртуальных избыточность протокола маршрутизации) для балансировки нагрузки, отказоустойчивости

Keepalived использования для VIP (виртуальный IP-адрес) как плавающий IP, который плавает между мастером балансировки нагрузки и резервного копирования балансировки нагрузки и используется для переключения между ними. Если главный балансировщик нагрузки отключается, то резервный балансировщик нагрузки используется для пересылки веб-запроса.

Давайте перейдем к моделированию того, как высокая доступность и балансировка нагрузки поддерживается для веб-серверов.

Настройка балансировщика нагрузки в Linux с помощью Nginx, HAProxy и Keepalived

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

Мы использовали CentOS в качестве дистрибутива Linux в этой статье. Вы можете использовать другие дистрибутивы Linux, но мы не можем гарантировать, что все команды (особенно установочные) будут работать в других дистрибутивах.

Требования к настройке подсистемы балансировки нагрузки

4 сервера с установленной системой CentOS (минимальная установка достаточно для этого учебника)

  • 2 CentOS для установки с nginx
  • 2 CentOS для настройки с HAProxy и Keepalived

В этом учебнике мы работали на следующими IP-адресами в качестве примера. Они могут быть изменены в соответствии с вашей системой. Не думайте, что это статические IP-адреса.

Web-сервер:

Источник: https://andreyex.ru/centos-7/balansirovka-nagruzki-s-haproxy-nginx-i-keepalived-v-linux-centos/

Балансировка нагрузки с помощью HAProxy

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

Рассмотрим решение по балансировке нескольких веб-серверов при помощи сервиса HAProxy.

Технические требования

  • Сервер под балансировщик с двумя сетевыми интерфейсами (Рекомендация. Внешний адрес для связи с внешним миром и локальный для общения между узлами кластера);
  • Два и более серверов под распределение запросов/трафика;

В примере будет использоваться дистрибутив Linux CentOS 7.

Установка и настройка backend-серверов

В качестве backend-серверов я буду использовать несколько веб-серверов с NGINX и настроенным SSL.

Прежде всего установим NGINX

Выполним настройку веб-сервера

server_name devservers.network; rewrite ^(.*)$ https://devservers.network$1 permanent; server_name devservers.network; access_log /srv/www/devservers.network/logs/access.log; error_log /srv/www/devservers.network/logs/error.log; root /srv/www/devservers.network/public_html; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; listen 443 ssl http2 proxy_protocol; set_real_ip_from 10.0.1.10/32; real_ip_header proxy_protocol; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; try_files $uri $uri/ /index.html; location ~ .(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {

Конфигурацию SSL можно выполнить и на самом балансировщике, а бэкенд сервера оставить работать на 80 порту, но в моем случае я буду использовать режим SSL Pass-Through.

Не забываем поместить SSL-сертификаты в директорию /etc/nginx/ssl.

Для того, чтобы принимать реальные IP-адреса клиентов на веб-сервере от HAProxy необходимо добавить proxy_protocol в параметр listen, а также указать реальный адрес откуда разрешить принимать запросы:

set_real_ip_from 10.0.1.10/32;real_ip_header proxy_protocol;

Создадим приветственную страницу на обоих веб-серверах touch /srv/www/devservers.network/public_html со следующим содержимым, изменив только номер сервера для его дальнейшего определения:

This is server #1

Добавляем NGINX в автозагрузку и запускаем сервис.

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

firewall-cmd —permanent —add-service=https

Установка и настройка балансировщика

В качестве сервера балансировки я буду использовать VDS сервер с ресурсами 1 vCPU и 1Gb RAM. При правильной настройке, данных мощностей хватит для обслуживания 10-15к одновременных сессий, чего вполне достаточно для среднестатистического интернет-ресурса.

Установим HAProxy

Пакет HAProxy доступен в базовой репозитории CentOS.

Настройка HAProxy

HAProxy обладает очень гибкими настройками и конфигурация может содержать большое количество директив и условий. Конфигурационный файл состоит из нескольких секций. Директивы frontend, backend, listen должны иметь своё имя, к примеру defaults — может, но не обязательно, а такие как global — не должны.

Выполняем конфигурацию HAProxy в файле /etc/haproxy/haproxy.cfg.
Рекомендую использовать свой конфигурационный файл, а представленный по умолчанию оставить как резерв.

Секция global

pidfile /var/run/haproxy.pid

Рассмотрим настройки в директиве global:

  • log — вести лог в /dev/log сохраняя в local0;
  • chroot — настройки безопасности, позволяющие работать HAProxy только в указанной директории;
  • maxconn — максимальное количество соединений на один процесс;
  • daemon — запуск процесса как демона.

Секция defaults

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

В нашем примере указаны следующие параметры:

timeout http-keep-alive 10s
  • log — указывает в какой лог вести запись (global в данном случае означает, что используются параметры, заданные в секции global);
  • mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health;
  • retries — количество попыток соединения с сервером в случае отказа;
  • option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов (рекомендуется включить данную настройку);
  • option redispatch — разрешает программе разорвать и переназначить сессию в случае отказа сервера;
  • contimeout — максимальное время ожидания успешного соединения с сервером.

В примере я использую параметры timeout, которые позволяют более гибко настроить поведение балансировщика. Подробно с доступными параметрами можно ознакомиться в документации к HAProxy

Секция frontend

Укажем HAProxy какие запросы он должен обрабатывать, для этого задаем секцию frontend с именем https-in:

default_backend backend-https-servers

Параметр bind со значением *:443 говорит о том, что HAProxy должен принимать все запросы на 443-й порт. Ещё раз напомню, что в данном примере я использую режим SSL Pass-Through, поэтому настройка SSL на самом HAProxy не выполняется.

Параметр default_backend указывает, какие сервера будут обрабатывать эти запросы. В данном случае — backend-https-servers, именно так необходимо назвать секцию backend.

Секция backend

В этой секции мы задаем алгоритм балансировки (параметр balance) и список серверов-обработчиков (server). В качестве алгоритма балансировки указываем roundrobin.

HAProxy имеет несколько алгоритмов балансировки:

  • roundrobin — каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету;
  • static-rr — то же, что и roundrobin, только изменение весов на лету не даст никакого эффекта;
  • leastconn — выбирает сервер с наименьшим количеством активных соединений;
  • first — выбирает первый сервер с доступными слотами для соединенияsource — на основе хэша IP-адреса отправителя запроса и весов серверов назначается сервер для соединения;
  • uri — сервер выбирается на основе адреса (без параметров) страницы;
  • url_param — сервер выбирается на основе GET-параметров запроса;
  • hdr — сервер выбирается на основе заголовков запроса;
  • rdp-cookie — сервер выбирается на основе cookie (если они не установлены, то применяется обычный roundrobin);

При перечислении серверов используется следующий формат: ключевое слово server, имя сервера, IP-адрес, дополнительные параметры (в данном случае — проверка статуса хоста и Proxy Protocol, которые позволяет перенаправлять реальные IP-адреса клиента с HAProxy на веб-сервер).

backend backend-https-servers server nginx01 10.0.1.3:443 check send-proxy server nginx02 10.0.1.4:443 check send-proxy

Просмотр статистики HAProxy

Для включения расширенной статистики HAProxy необходимо в конфигурационный файл добавить секцию:

stats auth admin:password
  • bind :10001 — HAProxy будет ожидать запросы к порту 10001;
  • stats enable — включить отчёты со статистикой;
  • stats uri — установка адреса страницы с отчётом;
  • stats auth — логин и пароль для авторизации на странице со статистикой;

В секции listen указываем HAProxy, что он должен показывать статистику на странице /haproxy_stats на порту 10001 после ввода логина admin и пароля password.

Проверяем

Переходим по адресу HAProxy (IP-адрес или хостнйем) и просто обновляем страницу. В зависимости от выбранного балансировщиком сервера будем получать ответ This is server #1 либо This is server #2.

Проверяем статистику. Переходим по адресу SITE_NAME:10001/haproxy_stats

На этом всё. Выше рассмотрен самый простой метод балансировки. Более сложная настройка требует грамотно составленного ТЗ и технических данных проекта. HAProxy очень удобный и гибкий в настройке инструмент с помощью которого можно выполнить балансировку и других сервисов, к примеру почтовый сервер, Memcached, Redis и пр.

Источник: https://bogachev.biz/2018/07/09/balansirovka-nagruzki-s-pomoshchyu-haproxy/

Балансировка средствами HAProxy

HAProxy(High Availability Proxy) представляет собой балансировщик нагрузки с открытым исходным кодом для распределения нагрузки в любой службе TCP. HAProxy является бесплатным, быстрым и надежным решением для распределения нагрузки, высокой доступности и проксирования для приложений TCP и HTTP. HAProxy особенно подходит для популярных сайтов с большой посещаемостью.

С момента появления, HAProxy стал распространённым балансировщиком нагрузки с открытым исходным кодом, несмотря на отсутствие рекламы.

Установка HAProxy

Установка производится следующим образом:

apt-get install haproxy

Также можно проверить версию:

haproxy -v

В скрипте init по адресу /etc/default/haproxy присвоим значению ENABLED 1:

ENABLED=1

Для проверки, выполним скрипт init без каких-либо параметров. Результат должен быть следующий:

$ service haproxy
reload restart start status stop

Когда HAProxy установлен, создадим установку, в которой есть 3 образца веб-сервера: 2 Apache и 1 HAProxy. Информация об установке представлена ниже:

Будем использовать три системы, созданных через VirtualBox:

Образец 1 – Балансировщик нагрузки Имя хоста: haproxy OС: Ubuntu

IP: 192.168.205.15

Образец 2 – Веб-сервер 1 Имя хоста: webser01 OС: Ubuntu с LAMP

IP: 192.168.205.16

Образец 3 – Веб-сервер 2 имя хоста: webserver02 OС: Ubuntu с LAMP

IP: 192.168.205.17

Перейдём к настройке HAProxy.

Настройка HAProxy

Создадим резервную копию оригинального файла, для этого переименуем его:

mv /etc/haproxy/haproxy.cfg{,.оригинал}

Создадим файл haproxy.cfg. С помощью текстового редактора создадим файл в /etc/haproxy/haproxy.cfg file следующего содержания:

global log /dev/log local0 log 127.0.0.1 local1 notice maxconn 4096 user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 listen webfarm 0.0.0.0:80 mode http stats enable stats uri /haproxy?stats balance roundrobin option httpclose option forwardfor server webserver01 192.168.205.16:80 check

server webserver02 192.168.205.17:80 check

Пояснение:

global log /dev/log local0 log 127.0.0.1 local1 notice maxconn 4096 user haproxy group haproxy

daemon

Директива файла регистрации событий (log) упоминает сервер системного журнала, на который будут отправляться сообщений журнала событий.

Директива maxconn определяет число одновременных подключений клиентской части системы. Значение по умолчанию установлено 2000 и должно быть настроено в соответствии с Вашей системой.

Директивы user и group изменяют процесс HAProxy для пользователя/группы. Эти значения изменять не следует.

defaults log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000

srvtimeout 50000

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

Директива попыток (retries) определяет количество попыток для выполнения на сервере после сбоя соединения.

Читайте также:  Openvpn на linux ubuntu — установка и настройка сервера

Директивы тайм-аута должны быть изменены. Contimeout определяет максимальное время ожидания успешного соединения с веб-сервером.

Сlitimeout и srvtimeout применяются, когда ожидается, что клиент или сервер получают, или передают данные во время процесса TCP. HAProxy рекомендует устанавливать одно и тоже значение для тайм-аута клиента и сервера.

listen webfarm 0.0.0.0:80 mode http stats enable stats uri /haproxy?stats balance roundrobin option httpclose option forwardfor server webserver01 192.168.205.16:80 check

server webserver02 192.168.205.17:80 check

Верхний блок содержит настройки для клиентской и внутренней части системы. Настроим HAProxy на порт 80 для webfarm, который представляет собой имя для идентификации приложения.

Директивы статистики разрешают соединение со страницей статистики. Данная страница доступна в нашем случае доступна по адресу: http://192.168.205.15/haproxy?.

Директивы балансировки определяют алгоритм балансировки нагрузки, доступны следующие варианты алгоримта:

  • Round Robin (roundrobin)
  • Статический Round Robin (static-rr)
  • Наименее используемые соединения (leastconn)
  • Источник (source)
  • URI (uri)
  • Параметр URL (url_param).

Директива server объявляет внутренний сервер, синтаксис:

server [:port] [param*]

Упомянутые названия появятся в журналах событий и предупреждениях. Существует ещё несколько параметров, поддерживаемых этой директивой и в дальнейшем будет использоваться параметр проверки (check), при котором происходит проверка сервера, иначе сервер будет всегда доступен.

После завершения настройки запустим службу HAProxy:

sudo service haproxy start

Тестирование балансировки нагрузки и преодоления отказа

Добавим имя сервера в стандартные index.html файлы, расположенные в /var/www/index.html

В образце 2 – Веб-сервер 1 (webserver01 с IP- 192.168.205.16), добавим следующее:

sudo sh -c «echo Hostname: webserver01 (192.168.205.16) >> /var/www/index.html»

В образце 3 – Веб-сервер 2 (webserver02 с IP- 192.168.205.17), добавим следующее:

sudo sh -c «echo Hostname: webserver02 (192.168.205.17) >>

/var/www/index.html»

Теперь откроем браузер и через haproxy перейдём по адресу. http://192.168.205.15

Каждый раз при обновлении вкладки нагрузка будет распределятся между веб-серверами.

Статистику haproxy можно посмотреть по адресу http://192.168.205.15/haproxy?stats

Также можно сделать следующее:

  • Запустить один или оба сервера в автономном режиме, чтобы проверить, что будет, когда Вы получаете доступ к HAProxy
  • Настроить HAProxy для использования в качестве пользовательской страницы поддержки
  • Настроить веб-интерфейс для визуального контроля статистики HAProxy
  • Изменить планировщик на что-то другое, нежели round-robin
  • Настроить приоритет/значимость для конкретных серверов

Источник: http://drach.pro/blog/linux/item/90-haproxy-balancing

HAPRoxy для Percona или Galera на CentOS. Его настройка и мониторинг в Zabbix

Хочу отметить, что эта инструкция родилась в процессе внедрения Zabbix в стенах компании Acronis.
В процессе экспертизы и проведенных мною исследований, она доказала свое право на жизнь и благополучно служит нам верой и правдой день ото дня.

Для тех кто не знаком с HAProxy, цитата о предназначении продукта:

От слов к делу, установка и настройка очень просты:

В предыдущем материале я подробно описал какие предварительные операции я проделывал над чистой CentOS 6.4, мои рекомендации актуальный и тут, все пакеты будут указаны с учетом рекомендаций в предыдущем материале:

Репозитории подключены, система в актуальном состоянии, переходим к установке HAProxy:

# Ставим haproxy

# Пишем конфиги

[root@rs-haproxy ~]# nano /etc/haproxy/haproxy.cfg

Теперь перейдем к серверам нашей percona или galera

# Настраиваем механизм проверки наших баз данных, для этого понадобиться xinetd

[root@xtrabackup-node-01 ~]# nano /etc/xinetd.d/mysqlchk

# Очень важно добавить эту запись, иначе ничего не получиться

root@xtrabackup-node-01 ~]# nano /etc/services

# Добавляем службу в автозагрузку и запускаем ее

# Разрешаем доступ к порту проверки

# Добавляем права для доступа clustercheck

# Проверяем все ли у нас получилось, должно получится что то вроде

[root@xtrabackup-node-01 ~]# /usr/bin/clustercheck

# Теперь проверим работу с нашего haproxy хоста

Готово! нужно проделать эту операцию на всех нодах percona/galera

# Это основной инструмент для нашего скрипта, установим его

# Настроим sudo для zabbix, если это не было сделано раньше

# Создаем папку для наших скриптов

# Собственно сам скрипт

rm -f /etc/zabbix/scripts/haproxy.mysql
nano /etc/zabbix/scripts/haproxy.mysql
if [[ -z $1 || -z $2 ]]; then servers=`echo «show stat» | sudo socat /var/run/haproxy stdio | sed 's/,/ /g' | awk '{print $2}' | grep -v -e «pxname» -e '^$'` if [[ -n ${servers} ]]; then JSON=»{ «data»:[» for DEV in ${servers}; do JSON=${JSON}»{ «{#SRV}»:»${DEV}»},» done JSON=${JSON}»]}» echo ${JSON} fi exit 0
else server=»$2″
# echo $server
if [ ${1} = «qcur» ]; then
# echo $1
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}»| sed 's/,/ /g' | awk '{print $3}' exit 0 fi if [ ${1} = «qmax» ]; then
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}» | sed 's/,/ /g' | awk '{print $4}' exit 0 fi
if [ ${1} = «scur» ]; then
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}» | sed 's/,/ /g' | awk '{print $5}' exit 0 fi if [ ${1} = «smax» ]; then
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}» | sed 's/,/ /g' | awk '{print $6}' exit 0 fi if [ ${1} = «econ» ]; then
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}» | sed 's/,/ /g' | awk '{print $14}' exit 0 fi
if [ ${1} = «qlimit» ]; then
echo «show stat» | sudo socat /var/run/haproxy stdio | grep «MySQL,${server}» | sed 's/,/ /g' | awk '{print $26}' exit 0 fi fi

Скрипт сам обнаруживает доступные сервера и передает их zabbix
Проверим это:

# Минимальные настроки для нашего zabbix-agent

# Применяем права на исполнение новому скрипту

# Передаем zabbix наши UserParameter

Теперь проверим правильно ли работает наш скрипт:

# Вот так работает наше автоматическое обнаружение серверов
bash-4.1$ /etc/zabbix/scripts/haproxy.mysql

# Спросим любые данные

Похоже что все в порядке! Перезагружаем службу и любуемся логами

Вот так выглядит наш шаблон под haproxy

Тут можно скачать шаблон для импорта в zabbix

Источник: https://habr.com/post/198448/

haproxy, Ubuntu

Автор: Skull

Статья написана 2017-09-13 13:48:24

Последние правки 2018-03-05 13:04:18

Устанавливаем и настраиваем балансировщик haproxy в Ubuntu. Особенность настройки: два домена, http, https, терминация SSL (https-соединение с клиентами поддерживает haproxy, трафик между haproxy и бекенд-серверами — http).

  • Исходные данные ~# cat /etc/os-release … Ubuntu 16.04.2 LTS … ~# haproxy -v HA-Proxy version 1.7.9-1 2017/08/19 Copyright 2000-2017 Willy Tarreau
  • Установка.Haproxy уже есть в стандартном репозитори Ubuntu 16.04, поэтому: # apt-get update # apt-get -y install haproxy
  • Настройка. В нашем примере: — домены: www.ex1.com, www.ex2.com — в бекенде: два сервера (у нас тест, поэтому сервер один, но с разносом в nginx по портам)Настройка nginx для теста. # backend 1 server { listen 127.0.0.1:81; server_name www.ex1.com; root /var/www/haproxy-test/web1/www.ex1.com; index index.html; } server { listen 127.0.0.1:81; server_name www.ex2.com; root /var/www/haproxy-test/web1/www.ex2.com; index index.html; } # backend 2 server { listen 127.0.0.1:82; server_name www.ex1.com; root /var/www/haproxy-test/web2/www.ex1.com; index index.html; } server { listen 127.0.0.1:82; server_name www.ex2.com; root /var/www/haproxy-test/web2/www.ex2.com; index index.html; } У нас получились два «виртуальных» web-сервера, web1 слушает на 127.0.0.1:81 (http), web2 на 127.0.0.1:82 (http). Также, сделаем четыре файла, index.html с разным содержимым (можно будет сразу видеть, с какого сервера был отдан контент): /var/www/haproxy-test/web1/www.ex1.com/index.html, в него пишем: www.ex1.com — web1 /var/www/haproxy-test/web1/www.ex2.com/index.html, а в этот пишем: www.ex2.com — web1 /var/www/haproxy-test/web2/www.ex1.com/index.html, сюда пишем: www.ex1.com — web2 /var/www/haproxy-test/web2/www.ex2.com/index.html, внутри: www.ex2.com — web2 На самом деле нужно, чтобы содержимое директорий с сайтами на web1 и web2 было идентичным, мы сделали все файлы разными исключительно для теста. Необходимо перезагрузить nginx, чтобы изменения вступили в силу.Настройки haproxy хранятся в /etc/haproxy/haproxy.cfgВ «пустом» файле есть только секции global и defaults. По большому счету их трогать не нужно, если только ради более тонкой настройки. Дописываем свои секции, одну для http, другую для https: listen webhttp bind :80 mode http balance roundrobin cookie srv insert indirect nocache option forwardfor header X-Real-IP option httplog option httpchk HEAD /index.html HTTP/1.0 server webhttp1 127.0.0.1:81 cookie webhttp1 check server webhttp2 127.0.0.1:82 cookie webhttp2 check http-request del-header Proxy listen webssl bind :443 ssl crt /etc/haproxy/ssl mode http balance roundrobin cookie srv insert indirect nocache option forwardfor header X-Real-IP option httplog option httpchk HEAD /index.html HTTP/1.0 server webssl1 127.0.0.1:81 cookie webssl1 check server webssl2 127.0.0.1:82 cookie webssl2 check http-request del-header Proxy — httpchk HEAD /index.html HTTP/1.0 : способ проверки доступности серверов — bind :443 ssl crt /etc/haproxy/ssl : биндим на все ip и порт 443 — /etc/haproxy/ssl : директория, где хранятся сертификаты сайтов
  • Отдельно про сертификаты. Файл сертификата должен включать в себя: публичный ключ, всю цепочку до корневого и сертификат корневого центра, а также приватный ключ.Если сайт один, то файл сертификата можно назвать как угодно и в строке настройки указать полный путь до него: bind :443 ssl crt /etc/haproxy/ssl/site.pem Если сайтов несколько, то файлы необходимо называть по url сайта, например, www.ex1.com.pem, а в настройках указать только директорию, где находятся сертификаты: bind :443 ssl crt /etc/haproxy/ssl Важно! Если haproxy настроен на работу с https, а сертификата для одного из сайтов нет (да, бывает и такое, к сайту не предполагается доступ по https, но пользователь может руками набрать https://www.ex1.com/), то для инициализации соединения будет взят первый сертификат из списка, отсортированного по названию. Для того, чтобы на сайте не светился чужой сертификат, можно выпустить самоподписной сертификат и поместить его в директории сертификатов, чтобы он находился вверху списка, в таком случае посетитель получит сообщение о том, что «к сертификату нет доверия, так как он является самоподписанным. Сертификат недействителен для имени www.ex1.com. Код ошибки: SEC_ERROR_UNKNOWN_ISSUER».Как сделать самоподписной сертификат для haproxy? Нет ничего сложного: ~# openssl req -new -x509 -nodes -out _local.crt -keyout _local.key Далее, склеиваем получившиеся файлы в один: ~# cat _local.crt >> _local.pem ~# cat _local.key >> _local.pem Получившийся _local.pem переносим в директорию с сертификатами (в нашем примере /etc/haproxy/ssl).
  • Мониторинг. Как всякий приличный сервис, haproxy предоставляет возможность мониторинга и просмотра статистики. Для этого необходима дополнительная настройка в /etc/haproxy/haproxy.conf. Есть два варианта. И там и там статистика будет доступна на всех сайтах, которые обслуживает haproxy.Вариант первый, добавить настройки в секцию listen webhttp или в listen webssl или в defaut: stats enable stats uri /stats stats realm Haproxy stats auth admin:12345 stats refresh 30s В первом случае статистика будет доступна при заходе по ссылке вида http://www.ex1.com/stats, во втором по ссылке вида https://www.ex1.com/stats, в третьем и по http и по https. Логин для входа: admin, пароль: 12345.Вариант второй, сделать доступ по отдельному порту через отдельную секцию: listen webstat bind :82 mode http stats enable stats uri / stats realm Haproxy stats auth admin:12345 stats refresh 30s В этом случае доступ к статистике через url вида http://www.ex1.com:82, http://www.ex2.com:82. http или https — зависит от настроек в строке с bind
  • Запуск. # systemctl start haproxy Перезапуск: # systemctl restart haproxy Остановка: # systemctl stop haproxy Автозапуск при загрузке Ubuntu: # systemctl enable haproxy Убрать из автозапуска: # systemctl disable haproxy
Читайте также:  Adblock. как установить adblock. как пользоваться adblock. как удалить adblock. скачать adblock

Источник: https://www.site-motor.ru/docs/ubuntu/haproxy.html

Настройка прокси сервера на CentOS 7 (squid+AD+sams2)

Когда у меня появилась необходимость настроить полноценный прокси сервер на базе CentOS 7, оказалось, что в интернете почти нет актуальной информации на эту тему. Статьи в целом есть, но большинство из них про 6-ю версию, плюс нету полноценной связки с active directory. В своей статье я восполню тематический пробел.

Введение

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

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

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

Здесь у вас вообще нет других вариантов, если вам нужна статистика и ограничение доступа по пользователям.

Приступим к настройке. В своей работе я буду подразумевать, что вы установили и настроили centos по моим рекомендациям. Советую ознакомиться с материалом. Это позволит здесь не тратить время на второстепенные настройки, которые не имеют прямого отношения к теме статьи.

Добавление CentOS 7 в домен Windows

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

Я без проблем ввел компьютер в домен, прошел все проверки, но потом в squid напрочь отказывалась работать ntlm авторизация. Все на вид выглядело нормально, но не работало. Я несколько раз восстанавливал виртуалку и начинал все сначала, перечитав практически все, что смог найти по теме в рунете и буржунете.

В какой-то момент все заработало. Я зафиксировал результат и несколько раз проверил последовательность действий и отточил ее до каждого шага. Проверил несколько раз на чистой системе. По крайней мере на момент написания статьи конфигурация на 100% рабочая, если аккуратно повторить все мои действия. Приступаем.

Сначала остановим и отключим firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Это не значит, что его не надо настраивать. Сейчас другая тема статьи, для локализации проблем необходимо убрать все, что теоретически может мешать при неправильной настройке. Firewall нужно настраивать и у меня есть подробная инструкция по настройке iptables. Рекомендую с ней ознакомиться и аккуратно настроить iptables, когда все получится со squid.

Установим софт для добавления сервера в домен windows:

# yum -y install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation ntp ntpdate

Для продолжения настройки вам необходимо знать следующие вещи — FQDN имя контроллера домена, его ip адрес и учетную запись с правами на ввод компьютера в домен.

Первым делом вручную синхронизируем часы компьютера с контроллером домена:

# ntpdate winsrv.xs.local

Добавляем наш контроллер в список серверов для обновления в файле /etc/ntp.conf, запускаем ntp и добавляем в автозагрузку:

# systemctl enable ntpd
# systemctl start ntpd

Выполняем команду для передачи настроек керберосу:

# authconfig —enablekrb5 —krb5kdc=winsrv.xs.local —krb5adminserver=winsrv.xs.local —krb5realm=WINSRV.XS.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=XS.LOCAL —smbservers=winsrv.xs.local —smbworkgroup=XS —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update

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

  • xs — название домена
  • winsrv — имя контроллера домена
  • winsrv.xs.local — полное имя домена

Вывод после работы команды будет такой:

Job for winbind.service failed. See 'systemctl status winbind.service' and 'journalctl -xn' for details.
getsebool: SELinux is disabled

Это нормально. Обращаю внимание, что SELinux у меня отключен.

Теперь заводим машину в домен:

# net ads join -U administrator
Enter administrators's password:
Using short domain name — XS
Joined 'PROXY' to dns domain 'xs.local'

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

Теперь нужно запустить и добавить в автозагрузку winbind:

# systemctl start winbind
# systemctl enable winbind

Проверяем, все ли у нас корректно работает. Для начала проверим наличие доверительной учетной записи сервера на КД:

# wbinfo -t checking the trust secret for domain XS via RPC calls succeeded

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

# wbinfo -g
# wbinfo -u

Проверим авторизацию пользователя через winbind:

# wbinfo -a XS\control%'pass'
plaintext password authentication succeeded
challenge/response password authentication succeeded

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня.

Теперь запросим билетик кербероса:

# kinit administrator@XS.LOCAL

Дальше вводите пароль. Если ошибки не выскочило, значит все в порядке. Проверим билет командой:

Источник: https://serveradmin.ru/nastroyka-proksi-servera-na-centos-7-squid-ad-sams2/

Установка Squid на Centos 7.3

Squid это пожалуй самый распространенный прокси-сервер для Linux. Прокси-сервер позволяет организовывать контролируемый доступ к сети интернет, а также осуществлять мониторинг ресурсов, на которые заходил пользователь.

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

Как и большинство демонов Linux установить Squid достаточно несложно. В Centos для этого используется менеджер пакетов yum.

yum install squid

После завершения установки необходимо выполнить настройку squid. Основным файлом настройки являетcя файл /etc/squid/squid.conf. Его можно редактировать обычным текстовым редактором, например Vi, Nano и т.д.

Squid имеет достаточно большое количество настроек, они описаны например на официальном сайте. Файл конфигурации работает сверху вниз — т.е то, что описано выше в файле срабатывает первым.

Рассмотрим минимально необходимые из них.

  • acl localnet src … и acl localnet src 10.0.0.0/8 — определяют какие сети для squid будут являться локальными. Необходимо оставить одну, остальные закомментировать.
  • acl … ports и acl Safe_ports 21 — определяют какие порты будет контролировать Squid.
  • http_access
  • http_access deny !Safe_ports
  • http_access deny all
  • Правила доступа deny — запрет, allow разрешение
  • Запрещает соединение по всем портам, кроме группы !Safe_ports
  • Запрещает все соединения, кроме тем что были описаны выше. после этих слов не должно быть других описаний правил доступа иначе они не сработают.
  • http_port указывает на каком порту работает прокси-сервер
  • transparent указывает что прокси будет прозрачным.
  • cache_dir ufs /var/spool/squid 4096 32 256 — указывает где будут созданы каталоги под кэш, суммарный размер, и количество каталогов 1 и второго уровня.

Например нижеприведенный листинг файла /etc/squid/squid.conf настроит прозрачный прокси-сервер (сервер который не заметен пользователю, т.е не требует специальной настройки в браузерах).

# # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed #Здесь указываются какие сети являются локальными #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network #acl localnet src fc00::/7 # RFC 4193 local private network range #acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines #Настройка безопасных портов — т.е порты которые будут открыты, отдельной #группой идет SSL порт acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # # Recommended minimum Access Permission configuration: # # Deny requests to certain unsafe ports #Закрыть все порты кроме безопасных и порта SSL http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost #http_access allow localhost manager #http_access deny manager # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on «localhost» is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed # Собственно правила фильтрации траффика. разрешены соединения из локальной сети и текущего хоста http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy # Все остальные коннекты запрешены http_access deny all # Squid normally listens to port 3128 #Указывается на каком порту работает прокси и будет ли он прозрачным http_port 3128 transparent # Uncomment and adjust the following to add a disk cache directory. #Задается директория под кеш и ее размер, а также количество вложенных #папок первого и второго уровня. cache_dir ufs /var/spool/squid 100 16 256 # Leave coredumps in the first cache dir #Каталог под дампы ядра Squid (служебный каталог) coredump_dir /var/spool/squid

После того как первоначальная настройка выполнена Squid необходимо проинициализировать командой squid -z. Это создаст структуру папок для кеша.

Убедится что сервис запущен, а также управлять им, можно используя systemctl.

  • systemctl status squid — проверить запущен ли squid
  • systemctl start squid — запустить squid
  • systemctl stop squid — остановить squid
  • systemctl enable squid — добавить squid в автозагрузку

После этого данный сервер можно использовать для фильтрации трафика в вашей сети.

Средняя оценка: 5,0, всего оценок: 1

Источник: https://oblako.kz/help/linux/ustanovka-squid-na-centos-7

Ссылка на основную публикацию