Как сохранить правила iptables
Содержание:
- Установка и настройка InfluxDB
- Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.
- Распространенные сообщения об ошибках в Ip_conntrack.pyc
- Ключи iptables и примеры их использования
- Возможности ZCS
- Интеграция с Active Directory
- Motivation
- Настройка zimbra после установки
- 4: Проверка соединения
- Переход к пользовательским цепочкам
- Заключение
Установка и настройка InfluxDB
Если у нас уже есть сервер баз данных, совместимый с telegraf, можно пропустить данный раздел. В противном случае, рассмотрим процесс подготовки сервера и установки InfluxDB. В данной инструкции мы будем разворачивать сервер баз данных на Linux, но при необходимости, InfluxDB может быть установлен на Windows.
Подготовка сервера
1. Время
Для любой базы хранения временных рядов важно своевременно обновлять время на сервере. Задаем временную зону:
Задаем временную зону:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* в данном примере задаем московское время. В каталоге /usr/share/zoneinfo список всех возможных вариантов.
Устанавливаем и запускаем сервис для автоматической синхронизации времени.
а) в CentOS / Red Hat / Fedora:
yum install chrony
systemctl enable chronyd —now
б) в Ubuntu / Debian:
apt-get install chrony
systemctl enable chrony
2. Брандмауэр
Если мы используем фаервол, то необходимо открыть порт 8086, на котором по умолчанию запускается данный сервер баз данных. В зависимости от используемой утилиты управления, команды будут отличаться.
а) Firewalld
По умолчанию, используется в системах на базе RPM. Для открытия нужного нам порта вводим команды:
firewall-cmd —permanent —add-port=8086/tcp
firewall-cmd —reload
б) Iptables
Чаще всего, используется в системах на базе DEB или в ранних версиях RPM. Вводим команду:
iptables -I INPUT 1 -p tcp —dport 8086 -j ACCEPT
… и сохраняем правила:
netfilter-persistent save
* если система вернет ошибку, что программа не установлена, выполним инсталляцию командой apt-get install netfilter-persistent.
3. SELinux
По умолчанию, пакет безопасности SELinux установлен на системах RPM. Чаще всего, его выключают командами:
setenforce 0
sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config
* но если мы хотим настроить SELinux, принцип конфигурирования можно прочитать в инструкции Настройка SELinux в CentOS.
Установка InfluxDB
Мы выполним установку базы данных на примере двух различных систем — CentOS и Ubuntu.
а) Установка InfluxDB на CentOS
Создаем файл с настройками репозитория:
vi /etc/yum.repos.d/influxdb.repo
name = InfluxDB Repository — RHEL $releasever
baseurl = https://repos.influxdata.com/rhel/$releasever/$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
Можно устанавливать InfluxDB:
yum install influxdb
Разрешаем автоматический запуск сервиса и стартуем его:
systemctl enable influxdb —now
б) Установка InfluxDB на Ubuntu
Устанавливаем ключ для репозитория:
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add —
Вводим команду для создания переменных в системном окружении, в которых будут храниться данные о версии дистрибутива:
source /etc/lsb-release
Следующей командой мы создадим файл с настройкой репозитория:
echo «deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable» | sudo tee /etc/apt/sources.list.d/influxdb.list
Обновляем список пакетов:
apt-get update
Теперь установим InfluxDB:
apt-get install influxdb
Разрешаем автоматический запуск сервиса и стартуем его:
systemctl enable influxdb
systemctl start influxdb
Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.
Давайте теперь рассмотрим наш Linux в качестве шлюза для локальной сети во внешнюю сеть Internet. Предположим, что интерфейс eth0 подключен к интернету и имеет IP 198.166.0.200, а интерфейс eth1 подключен к локальной сети и имеет IP 10.0.0.1. По умолчанию, в ядре Linux пересылка пакетов через цепочку FORWARD (пакетов, не предназначенных локальной системе) отключена. Чтобы включить данную функцию, необходимо задать значение 1 в файле /proc/sys/net/ipv4/ip_forward:
netfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Чтобы форвардинг пакетов сохранился после перезагрузки, необходимо в файле /etc/sysctl.conf раскомментировать (или просто добавить) строку net.ipv4.ip_forward=1.
Итак, у нас есть внешний адрес (198.166.0.200), в локальной сети имеется некоторое количество гипотетических клиентов, которые имеют адреса из диапазона локальной сети и посылают запросы во внешнюю сеть. Если эти клиенты будут отправлять во внешнюю сеть запросы через шлюз «как есть», без преобразования, то удаленный сервер не сможет на них ответить, т.к. обратным адресом будет получатель из «локальной сети». Для того, чтобы эта схема корректно работала, необходимо подменять адрес отправителя, на внешний адрес шлюза Linux. Это достигается за счет (маскарадинг) в , в .
netfilter:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT netfilter:~# iptables -P FORWARD DROP netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Итак, по порядку сверху-вниз мы разрешаем уже установленные соединения в цепочке FORWARD, таблице filter, далее мы разрешаем устанавливать новые соединения в цепочке FORWARD, таблице filter, которые пришли с интерфейса eth1 и из сети 10.0.0.1/24. Все остальные пакеты, которые проходят через цепочку FORWARD — отбрасывать. Далее, выполняем маскирование (подмену адреса отправителя пакета в заголовках) всех пакетов, исходящих с интерфейса eth0.
Примечание. Есть некая общая рекомендация: использовать правило -j MASQUERADE для интерфейсов с динамически получаемым IP (например, по DHCP от провайдера). При статическом IP, -j MASQUERADE можно заменить на аналогичное -j SNAT —to-source IP_интерфейса_eth0. Кроме того, SNAT умеет «помнить» об установленных соединениях при кратковременной недоступности интерфейса. Сравнение MASQUERADE и SNAT в таблице:
Кроме указанных правил так же можно нужно добавить правила для фильтрации пакетов, предназначенных локальному хосту — как описано в . То есть добавить запрещающие и разрешающие правила для входящих и исходящих соединений:
netfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
В результате, если один из хостов локальной сети, например 10.0.0.2, попытается связаться с одним из интернет-хостов, например, 93.158.134.3 (ya.ru), при , их исходный адрес будет подменяться на внешний адрес шлюза в цепочке POSTROUTING таблице nat, то есть исходящий IP 10.0.0.2 будет заменен на 198.166.0.200. С точки зрения удаленного хоста (ya.ru), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 198.166.0.200. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 10.0.0.2, после чего пакеты будут передаваться настоящему получателю в локальной сети. Для такого обратного преобразования никаких дополнительных правил указывать не нужно — это будет делать все та же операция MASQUERADE, которая помнит какой хост из локальной сети отправил запрос и какому хосту необходимо вернуть пришедший ответ.
Примечание: желательно негласно принято, перед всеми командами iptables очищать цепочки, в которые будут добавляться правила:
netfilter:~# iptables -F ИМЯ_ЦЕПОЧКИ
Распространенные сообщения об ошибках в Ip_conntrack.pyc
Наиболее распространенные ошибки ip_conntrack.pyc, которые могут возникнуть на компьютере под управлением Windows, перечислены ниже:
- «Ошибка в файле Ip_conntrack.pyc.»
- «Отсутствует файл Ip_conntrack.pyc.»
- «Ip_conntrack.pyc не найден.»
- «Не удалось загрузить Ip_conntrack.pyc.»
- «Не удалось зарегистрировать ip_conntrack.pyc.»
- «Ошибка выполнения: ip_conntrack.pyc.»
- «Ошибка загрузки ip_conntrack.pyc.»
Такие сообщения об ошибках PYC могут появляться в процессе установки программы, когда запущена программа, связанная с ip_conntrack.pyc (например, SUSE OpenStack Cloud x86_64 — 1 of 3), при запуске или завершении работы Windows, или даже при установке операционной системы Windows
Отслеживание момента появления ошибки ip_conntrack.pyc является важной информацией при устранении проблемы
Ключи iptables и примеры их использования
Для работы с таблицами (iptables -t)
Напоминаю, все правила в netfilter распределены по таблицам. Чтобы работать с конкретной таблицей, необходимо использовать ключ -t.
Ключ | Описание |
---|---|
-t filter | Таблица по умолчанию. С ней работаем, если упускаем ключ -t. Встроены три цепочки — INPUT (входящие), OUTPUT (исходящие) и FORWARD (проходящие пакеты) |
-t nat | Для пакетов, устанавливающий новое соединение. По умолчанию, встроены три цепочки — PREROUTING (изменение входящих), OUTPUT (изменение локальных пакетов перед отправкой) и POSTROUTING (изменение всех исходящих). |
-t mangle | Для изменения пакетов. Цепочки — INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING. |
-t raw | Для создания исключений в слежении за соединениями. Цепочки: PREROUTING, OUTPUT. |
Команды
Нижеперечисленные ключи определяют действия, которые выполняет утилита iptables.
Ключ | Описание и примеры |
---|---|
-A | Добавление правила в конец списка:iptables -A INPUT -s 192.168.0.15 -j DROP запретить входящие с 192.168.0.15. |
-D | Удаление правила:iptables -D INPUT 10 удалить правило в цепочке INPUT с номером 10. |
-I | Вставка правила в определенную часть списка:iptables -I INPUT 5 -s 192.168.0.15 -j DROP вставить правило 5-м по списку. |
-R | Замена правила.iptables -R OUTPUT 5 -s 192.168.0.15 -j ACCEPT заменить наше 5-е правило с запрещающего на разрешающее. |
-F | Сброс правил в цепочке.iptables -F INPUT |
-Z | Обнуление статистики.iptables -Z INPUT |
-N | Создание цепочки.iptables -N CHAINNEW |
-X | Удаление цепочки.iptables -X CHAINNEW |
-P | Определение правила по умолчанию.iptables -P INPUT DROP |
-E | Переименовывание цепочки.iptables -E CHAINNEW CHAINOLD |
Условия
Данные ключи определяют условия правила.
Ключ | Описание и примеры |
---|---|
-p | Сетевой протокол. Допустимые варианты — TCP, UDP, ICMP или ALL.iptables -A INPUT -p tcp -j ACCEPT разрешить все входящие tcp-соединения. |
-s | Адрес источника — имя хоста, IP-адрес или подсеть в нотации CIDR.iptables -A INPUT -s 192.168.0.50 -j DROP запретить входящие с узла 192.168.0.50 |
-d | Адрес назначения. Принцип использования аналогичен предыдущему ключу -s.iptables -A OUTPUT -d 192.168.0.50 -j DROP запретить исходящие на узел 192.168.0.50 |
-i | Сетевой адаптер, через который приходят пакеты (INPUT).iptables -A INPUT -i eth2 -j DROP запретить входящие для Ethernet-интерфейса eth2. |
-o | Сетевой адаптер, с которого уходят пакеты (OUTPUT).iptables -A OUTPUT -o eth3 -j ACCEPT разрешить исходящие с Ethernet-интерфейса eth3. |
—dport | Порт назначения.iptables -A INPUT -p tcp —dport 80 -j ACCEPT разрешить входящие на порт 80. |
—sport | Порт источника.iptables -A INPUT -p tcp —sport 1023 -j DROP запретить входящие с порта 1023. |
Перечисленные ключи также поддерживают конструкцию с использованием знака !. Он инвертирует условие, например,iptables -A INPUT -s ! 192.168.0.50 -j DROP
запретит соединение всем хостам, кроме 192.168.0.50.
Действия
Действия, которые будут выполняться над пакетом, подходящим под критерии условия. Для каждой таблицы есть свой набор допустимых действий. Указываются с использованием ключа -j.
Таблица | Действие | Описание |
---|---|---|
filter | ACCEPT | Разрешает пакет. |
DROP | Запрещает пакет. | |
REJECT | Запрещает с отправкой сообщения источнику. | |
nat | MASQUERADE | Для исходящих пакетов заменяет IP-адрес источника на адрес интерфейса, с которого уходит пакет. |
SNAT | Аналогично MASQUERADE, но с указанием конкретного сетевого интерфейса, чей адрес будет использоваться для подмены. | |
DNAT | Подмена адреса для входящих пакетов. | |
REDIRECT | Перенаправляет запрос на другой порт той же самой системы. | |
mangle | TOS | Видоизменение поля TOS (приоритезация трафика). |
DSCP | Изменение DSCP (тоже приоритезация трафика). | |
TTL | Изменение TTL (время жизни пакета). | |
HL | Аналогично TTL, но для IPv6. | |
MARK | Маркировка пакета. Используется для последующей фильтрации или шейпинга. | |
CONNMARK | Маркировка соединения. | |
TCPMSS | Изменение значения MTU. |
Возможности ZCS
Проект калифорнийской компании Zimbra Inc
громко заявившей о себе в 2007
году, сразу привлек к себе внимание. И хотя первые версии по функциональности не
дотягивали до большинства имеющихся тогда OpenSource решений, заложенный в нем
потенциал был огромен, а поэтому интересен многим админам
В результате в
сентябре 2007 года компания была выкуплена Yahoo!, а в начале 2010 перешла к
VMware.
Сегодня в Zimbra
входит стандартный набор приложений, необходимых для любой системы коллективной
работы. В первую очередь это почтовый сервер, позволяющий пользователям работать
с почтой с помощью клиентских программ поддерживающих протоколы POP/POPS и IMAP/IMAPS
или через веб-интерфейс. Обеспечивается фильтрация спама и антивирусная проверка
почты при помощи ClamAV. К слову, простота развертывания почтового сервиса была
оценена еще в первых релизах продукта, поэтому многие админы вместо установки
разношерстной связки сервисов и обеспечения их совместной работы, сразу ставилиZimbra. Пользователь может настроить сбор почты с других ящиков,
сообщения при этом будут копироваться на сервер Zimbra, поддерживается
работа с несколькими доменами.
Учетные записи пользователей можно хранить локально, а также в любом LDAP
сервере, в том числе и домене ActiveDirectory.
Разработчики предоставили специальное API, позволяющее создавать
дополнительные плагины называемые zimlets существенно расширяющие возможности
Zimbra. Используя зимлеты достаточно просто интегрировать в ZCS продукты и
сервисы, разработанные третьими лицами или новые функции, создав единую среду,
обладающую нужной функциональностью. И кстати именно благодаря зимлетам
Zimbra получил такую популярность и функциональность. В стандартной поставке
сервера идет несколько десятков зимлетов, по умолчанию устанавливается лишь
малая часть из них.
Как водится в таких случаях приложение использует клиент-серверную
архитектуру. Серверная часть Zimbra Server написана на Java, является POP3/IMAP
сервером, и базируется на нескольких OpenSource проектах, среди которых nginx,
Apache Lucene, OpenLDAP, MySQL, Postfix, POP3/IMAP4 прокси Perdition, ClamAV,
DSPAM и некоторые другие.
Веб-клиент Zimbra Web Client — обеспечивает интерактивный, удобный и что не
менее важно локализованный веб-интерфейс для получения доступа к данным
пользователя. Построен с применением технологии AJAX, что упрощает
взаимодействие пользователя и выполнение ряда операций
Например, достаточно
навести курсор на дату в календаре, как будет высвечены все события дня, если
навести мышку на адрес в сообщении или контакте, сразу будет показана схема
проезда, щелчок на телефонном номере запустит Skype или Ekiga, позволяя сразу
поговорить с этим человеком и так далее.
И, наконец, клиент совместной работы Zimbra Desktop, который обеспечивает
подключение к серверу и синхронизацию данных (почта, контакты, календарь и так
далее), может использоваться в качестве почтового клиента для любого IMAP/POP3
почтового сервиса.
ZCS предлагается в трех версиях: Open Source Edition, Network Edition (Starter,
Standard и Professional) и Zimbra Appliance (Basic, Standard). Первая
распространяется свободно под OpenSource-подобной ZPL лицензией (Zimbra Public
License). Поддерживает неограниченное количество пользователей, и хотя имеет
некоторые ограничения по сравнению с платными версиями, но они никоим образом не
мешают использованию Zimbra в организациях малого и среднего размера.
Несколько сокращены инструменты администратора, отсутствует возможность
синхронизации с внешними устройствами MS Outlook, отсутствует встроенный
механизм резервного копирования и восстановления, невозможность работы в
кластере и другие (см.
таблицу). Хотя отчаиваться не стоит, некоторые «пропущенные» в OpenSource
версии вопросы давно уже решены мощным комюнити проекта. Так, например в Wiki
можно найти несколько вариантов скриптов, предназначенных для резервирования
текущей установки Zimbra.
С Open Source Edition мы и будем знакомиться далее.
Интеграция с Active Directory
Интеграция с Active Directory должна настраиваться в момент веб-установки сервера. Если у нас уже установлен Openfire, и мы хотим переключиться на использование LDAP, открываем конфигурационный файл:
vi /opt/openfire/conf/openfire.xml
Находим:
<setup>true</setup>
… и правим на:
<setup>false</setup>
Перезапускаем сервис:
systemctl restart openfire
Ждем секунд 10 (приложение перезапускается долго).
Открываем в браузере адрес http://<IP-адрес сервера>:9090 — откроется мастер установки. Проходим снова по всем шагам до настройки профилей и выбираем Сервер каталогов (LDAP):
1) Откроется страница настройки профилей LDAP. Заполняем поля:
* где
- Из списка Тип сервера выбираем Active Directory.
- Protocol выбираем либо ldap, либо ldaps (если наш Active Directory поддерживает запросы с шифрованием).
- В качестве хоста прописываем имя контроллера домена или целиком весь домен.
- База DN — корневая директория LDAP, откуда будет выполняться поиск объектов.
- Администратор DN — учетная запись в LDAP с минимальными правами (на чтение объектов AD). Правильнее всего создать отдельную запись и использовать ее.
Кликаем по Тестовые настройки — мы должны увидеть отчет об успешном прохождении тестирования:
2) Нажимаем Сохранить и продолжить — откроется страница с настройками полей и атрибутов. Данные атрибуты должны соответствовать атрибутам Active Directory. В моем случае пришлось заменить jpegPhoto на thumbnailPhoto и homePostalAddress на physicalDeliveryOfficeName. Правильные атрибуты можно посмотреть в оснастке Active Directory — пользователи и компьютеры (на вкладке Редактор атрибутов любого пользователя).
Нажимаем Тестовые настройки — откроется окно, в котором можно загрузить информацию от случайных профилей в AD и убедиться, что нужные нам данные загружаются корректно. После нажимаем Сохранить и продолжить.
3) На последнем шаге настройки интеграции с Active Directory оставляем предложенные настройки:
… и нажимаем Тестовые настройки — мы должны увидеть информацию о группах, которую сможет получить Openfire. Кликаем Сохранить и продолжить.
Конфигурирование LDAP завершено. Теперь добавим администраторов системы, которые смогут управлять сервером из панели управления:
Обратите внимание, что доступ к панели управления под встроенным администратором Openfire будет невозможен после смены профилей на использование LDAP. Обязательно добавляем хотя бы одного пользователя, у которого будут привилегии настройки
Настройка завершена. Пробуем авторизоваться в панели управления под учетной записью администратора, которую мы добавили. После под своей учетной записью в AD.
Аутентификация на основе групп
Если необходимо ограничить пользователей, которые могут подключаться к серверу, можно использовать группы Active Directory. Для этого открываем панель управления Openfire и переходим в раздел Сервер — Настройки сервера и кликаем по кнопке Изменить:
В открывшемся окне переходим к разделу 2. Отображение пользователей — кликаем по Расширенные настройки и добавляем Пользовательский фильтр:
* например, как на изображении выше, можно добавить фильтр (memberOf=cn=Domain Admins,cn=Users,dc=dmosk,dc=local) — это означает, что к серверу смогут подключиться только те пользователи, которые принадлежат группе Domain Admins.
Motivation
As I was developing ipchains, I realized (in one of those
blinding-flash-while-waiting-for-entree moments in a Chinese
restaurant in Sydney) that packet filtering was being done in the
wrong place. I can’t find it now, but I remember sending mail to Alan
Cox, who kind of said `why don’t you finish what you’re doing, first,
even though you’re probably right’. In the short term, pragmatism was
to win over The Right Thing.
After I finished ipchains, which was initially going to be a minor
modification of the kernel part of ipfwadm, and turned into a larger
rewrite, and wrote the HOWTO, I became aware of just how much
confusion there is in the wider Linux community about issues like
packet filtering, masquerading, port forwarding and the like.
This is the joy of doing your own support: you get a closer feel
for what the users are trying to do, and what they are struggling
with. Free software is most rewarding when it’s in the hands of the
most users (that’s the point, right?), and that means making it easy.
The architecture, not the documentation, was the key flaw.
So I had the experience, with the ipchains code, and a good idea of
what people out there were doing. There were only two problems.
Firstly, I didn’t want to get back into security. Being a security
consultant is a constant moral tug-of-war between your conscience and
your wallet. At a fundamental level, you are selling the feeling of
security, which is at odds with actual security. Maybe working in a
military setting, where they understand security, it’d be different.
The second problem is that newbie users aren’t the only concern; an
increasing number of large companies and ISPs are using this stuff. I
needed reliable input from that class of users if it was to scale to
tomorrow’s home users.
These problems were resolved, when I ran into David Bonn, of
WatchGuard fame, at Usenix in July 1998. They were looking for a
Linux kernel coder; in the end we agreed that I’d head across to their
Seattle offices for a month and we’d see if we could hammer out an
agreement whereby they’d sponsor my new code, and my current support
efforts. The rate we agreed on was more than I asked, so I didn’t
take a pay cut. This means I don’t have to even think about external
conslutting for a while.
Exposure to WatchGuard gave me exposure to the large clients I
need, and being independent from them allowed me to support all users
(eg. WatchGuard competitors) equally.
So I could have simply written netfilter, ported ipchains over the
top, and been done with it. Unfortunately, that would leave all the
masquerading code in the kernel: making masquerading independent from
filtering is the one of the major wins point of moving the packet
filtering points, but to do that masquerading also needed to be moved
over to the netfilter framework as well.
Also, my experience with ipfwadm’s `interface-address’ feature (the
one I removed in ipchains) had taught me that there was no hope of
simply ripping out the masquerading code and expecting someone who
needed it to do the work of porting it onto netfilter for me.
So I needed to have at least as many features as the current code;
preferably a few more, to encourage niche users to become early
adopters. This means replacing transparent proxying (gladly!),
masquerading and port forwarding. In other words, a complete NAT layer.
Even if I had decided to port the existing masquerading layer,
instead of writing a generic NAT system, the masquerading code was
showing its age, and lack of maintenance. See, there was no
masquerading maintainer, and it shows. It seems that serious users
generally don’t use masquerading, and there aren’t many home users up
to the task of doing maintenance. Brave people like Juan Ciarlante
were doing fixes, but it had reached to the stage (being extended over
and over) that a rewrite was needed.
Please note that I wasn’t the person to do a NAT rewrite: I didn’t
use masquerading any more, and I’d not studied the existing code at
the time. That’s probably why it took me longer than it should have.
But the result is fairly good, in my opinion, and I sure as hell
learned a lot. No doubt the second version will be even better, once
we see how people use it.
NextPrevious
Настройка zimbra после установки
Чтобы начать пользоваться сервером, внесем основные настройки. Для этого открываем браузер и вводим адрес https://<IP-адрес сервера>:7071 — должна открыться страница с ошибкой, разрешаем открытие страницы и мы увидим форму для входа в панель администрирования Zimbra. Вводим логин admin и пароль, который задавали при установке.
Добавление домена
Если мы не меняли рабочий домен в настройках во время установки сервера, то основной домен будет таким же, как имя сервера. Как правило, это не то, что нам нужно. И так, заходим в Настройка — Домены. В правой части окна кликаем по значку шестеренки и Создать:
Задаем название для нового домена:
… и кликаем Далее.
В следующем окне выбираем сервер:
… можно нажать Готово.
Теперь поменяем домен по умолчанию. Переходим в Настройка — Глобальные настройки. Меняем значение для поля «Домен по умолчанию»:
… и нажимаем Сохранить.
Создание почтового ящика
Переходим с главного меню панели администрирования в Управление — Учетные записи. Справа кликаем по шестеренке — Создать:
Задаем имя учетной записи, а также фамилию пользователя:
Задаем пароль пользователя и, по желанию, ставим галочку Требуется сменить пароль:
При необходимости создания административной учетной записи ставим галочку Глобальный администратор:
Нажимаем Готово.
4: Проверка соединения
На этом этапе важно подтвердить, что обе ноды могут взаимодействовать друг с другом. Хотя хосты утверждают, что подключены к сети, есть вероятность, что они не могут общаться
Легкий способ узнать IP-адрес ZeroTier для каждого хоста – посмотреть в раздел Members веб-консоли ZeroTier. Возможно, вам придется обновить страницу после авторизации сервера и клиента. Кроме того, для поиска этих адресов вы можете использовать командную строку Linux. Используйте следующую команду на обеих машинах – вам нужно будет использовать первый IP-адрес, указанный в списке. В приведенном ниже примере это 203.0.113.0.
Чтобы проверить соединение между хостами, запустите ping с одного хоста и укажите IP-адрес второго. На клиенте команда будет выглядеть так:
А на сервере – так:
Если с противоположного хоста возвращаются ответы (как показано ниже), то ноды успешно обмениваются данными по SDN.
Вы можете добавить в эту конфигурацию столько машин, сколько захотите, повторив описанные выше процессы установки ZeroTier и добавления машины в сеть.
Теперь, когда вы убедились, что ваш сервер и клиент могут взаимодействовать друг с другом, вы можете попробовать настроить сеть, чтобы обеспечить выходной шлюз и создать собственный VPN.
Переход к пользовательским цепочкам
Следует упомянуть особый класс нетерминальных действий – действия перехода. Они передают оценивание пакета другой цепочке для дополнительной обработки. Мы довольно много говорили о встроенных цепочках, которые тесно связаны с хуками netfilter. Однако iptables также позволяет администраторам создавать свои собственные цепочки.
Правила можно поместить в пользовательские цепочки таким же образом, как и во встроенных цепочках. Разница в том, что пользовательские цепочки могут быть достигнуты только путем перехода к ним из правила (они не регистрируются самим хуком netfilter).
Пользовательские цепочки действуют как простые расширения той встроенной цепочки, которая их вызвала. Например, пользовательская цепочка вернет пакет вызывающей цепочке, если будет достигнут конец списка правил или если критерий активирует действие RETURN. Оценка пакета также может перейти к дополнительным пользовательским целям.
Заключение
В этом мануале вы познакомились с Software-Defined Networking и получили некоторое представление о преимуществах этой технологии и ZeroTier. Также вы знаете, как с помощью этого инструмента настроить VPN. VPN дает вам более глубокое представление о том, как работает маршрутизация в такой сети. Также вы узнали кое-что о правилах потоков.
Теперь, когда у вас сеть «точка-точка», вы можете расширить ее функции, например, настроить общий доступ к файлам. Если у вас есть NAS или файловый сервер, вы можете связать его с ZeroTier и получить быстрый доступ к нему. Если вы хотите поделиться файлами со своими друзьями, вы можете присоединить их к вашей сети ZeroTier. Сотрудники, живущие в разных частях планеты, могут использовать в сети централизованные места хранения данных.
SDNUbuntu 16.04VPNZeroTierZeroTier One