Бывает, что какое-либо письмо не проходит и в логах видно что-то странное, причем методы диагностики без включения полных логов не помогают. Тогда  приходится делать так:

# /usr/local/etc/rc.d/exim stop
# exim -bd -d+all > /var/log/exim-debug.log 2>&1

Здесь мы потушили Exim и пустили его в ручном режиме с выводом полной информации о его работе (-d+all). Неприятная особенность заключается в том, что Exim пишет лог своей работы в stderr, с которым довольно неудобно работать. Потому конструкция «> /var/log/exim-debug.log 2>&1″ перенаправляет stderr в файл /var/log/exim-debug.log.

Все, теперь можно ждать копии проблемного письма, другие пользователи при этом продолжат спокойно работать. После того, как собрали нужное для устранения ошибки количество информации, останавливаем ручной режим нажатием Ctrl-C и запускаем Exim в нормальном режиме работы:

# /usr/local/etc/rc.d/exim start

SPF и DKIM – это механизмы верификации почтового сервера, позволяющие проверить его подлинность. Многие почтовые сервера используют их при получении почты, чтобы быть уверенным в том, что получаемая почта не является спамом. Если вы организуете рассылку со своего почтового сервера, например, периодическую рассылку, либо рассылку писем от вашего интернет-магазина, вам, скорее всего, придется настраивать оба механизма, поскольку это позволит быть уверенным в том, что ваши письма доставляются и автоматически не определяются как спам.

Настройка SPF (Sender Policy Framework).

Настройка SPF является достаточно простой. Для этого достаточно создать записи DNS, определяющие, с каких серверов разрешена отправка почты для данного домена. Использоваться могут два типа записи – TXT и SPF.

domain.ru TXT "v=spf1 a mx ip4:<IP-адрес-почтового-сервера> -all"
domain.ru SPF"v=spf1 a mx ip4:<IP-адрес-почтового-сервера> -all"

В данном примере указывается,  что отправка почты данного домена разрешена только с хоста с адресом <IP-адрес-почтового-сервера>, для которого есть записи типа A и MX, со всех остальных отправка запрещена.

После добавления записей не забудьте изменить serial для зоны DNS и перезагрузить информацию о доменной зоне. Если вы всё сделали правильно, то при отправке письма на другой домен, например, на gmail.com, в заголовках письма вы увидите следующий заголовок:

Настройка SPF записи

SPF-запись — проверка отправителя.

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле «From» вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя).

SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Рассмотрим простой пример SPF-записи:

 example.org. IN TXT "v=spf1 +a +mx -all"

Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций:

 

  • «v=spf1» — используемая версия SPF.
  • «+» — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это «Pass»;
  • «-» — Отклонить (Fail);
  • «~» — «мягкое» отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;
  • «?» — нейтральное отношение;
  • «mx» — включает в себя все адреса серверов, указанные в MX-записях домена;
  • «ip4» — опция позволяет указать конкретный IP-адрес или сеть адресов;
  • «a» — указываем поведение в случае получения письма от конкретного домена;
  • «include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
  • «all» — все остальные сервера, не перечисленные в SPF-записи.

 

Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.

 

  • «+a» — разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org;
  • «+mx» — разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org;
  • «-all» — все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

 

Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример:

 example.org. IN TXT "v=spf1 mx ip4:78.110.50.123 +a:mail.ht-systems.ru include:gmail.com ~all"

Теперь более подробно о используемых опциях...

 

  • «mx» — принимать письма от серверов, указанных в MX-записях;
  • «ip4:78.110.50.123» — принимать письма, отправленные с IP-адреса 78.110.50.123;
  • «+a:mail.ht-systems.ru» — то же, что и a:mail.ht-systems.ru. Принимать от mail.ht-systems.ru;
  • «include:gmail.com» — принимать письма с серверов, разрешенных SPF-записями gmail.com;
  • «~all» — принимать письма со всех остальных серверов, но помечать их как СПАМ

 

А теперь рассмотрим еще более «экзотичный» пример. В описании возможных опций указывалось, что возможно указание сетей ip-адресов. Стоит отметить, что это применимо и к записям «a» и «mx». Рассмотрим следующий пример:

 example.org. IN TXT "v=spf1 mx/24 a:hts.ru/24 -all" 

«mx/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена;
«a:hts.ru/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена hts.ru;
«-all» — всех остальных отправителей — блокируем.

Иногда можно встретить следующие записи (очень редко):

«ptr» — проверяет PTR-запись IP-адреса отправителя. Если она сходится с указаным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен. Серьезным недостатком даного метода есть то, что генерируется очень большое количество DNS-запросов;
«exists» — выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Кстати, не имеет значения, на какой IP-адрес резолвится домен, даже если это «серые» сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).

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

 example.org. IN TXT "v=spf1 ptr:example.org exist:example.org -all"

Также не будет излишним ознакомиться со следующими опциями: redirect и exp.

«redirect» — указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена. Пример:

 example.org. IN TXT "v=spf1 redirect:example.com ~all"

В даном примере будет проводится проверка SPF-записи домена example.com, а не example.org.

«exp» — использование даной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи, даже после опции all. Рассмотрим более детально механизм работы опции exp.

Допустим, что у домена example.org следущая SPF-запись:

 example.org. IN TXT "v=spf1 +a +mx -all exp=spf.example.org"

Теперь содаем TXT-запись для домена spf.example.org:

 spf.example.org. IN TXT "You host not allowed e-mail to me"

В результате этих шаманских действий SPF-запись будет контролировать, чтобы почта доставлялась только от валидных хостов, а всем остальным будет отправляться сообщение о ошибке, прописанное в TXT-записи домена spf.example.org.

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

Received-SPF:

Настройка DKIM (DomainKeys Identified Mail).

Настройка DKIM несколько сложнее, чем настройка SPF. Для работы этого механизма необходимо следующее:

– Почтовый сервер должен уметь подписывать письма
– Должны быть созданы приватный и публичный ключи
– Должны присутствовать записи в DNS, указывающие на наличие поддержки DKIM

Генерация ключей.

Ключи можно сгенерировать при помощи OpenSSL. Генерация приватного ключа:

# openssl genrsa -out dkimprivate.key 1024 
Generating  RSA private key, 1024 bit  long modulus
.++++++
.....................++++++
e is 65537 (0x10001) 

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

chmod 400 /etc/ssl/ private/dkimprivate.key

Генерация публичного ключа:

openssl rsa -pubout -in dkimprivate.key -out dkimpublic.key
writing  RSA key

Ключи готовы. Их можно разместить в директории, где хранятся другие ключи. Для Debian'а это директория /etc/ssl/private. Сгенерировать их можно также при помощи программы opendkim-genkey, входящую в пакет opendkim-tools. Теперь надо добавить записи в DNS. Записей будет две.

_domainkey.domain.ru.        TXT o=~;"
mail._domainkey.domain.ru. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoCH8kcKOUHIx1Gbv461a9iZYaqS3LfjGLHR1aJEQkAChMEB5xc74UeEcTWo0rx5sBAgbhUj/5nefL4K4cxFLnFIKkPZZp/e2euTsKd0c3kE3Go5vu9jERzXnsb0jAQO0K85Jfw/gQahTC4qDOce5B5REsXtMtUR8r9J+dnACpzQIDAQAB"
_adsp._domainkey.domain.ru.   TXT "dkim=all"

То, что идет после «p=» – это ключ, содержащийся в файле dkimpublic.key, он записывается в одну строчку. А запись «_adsp._domainkey.domain.ru» определяет, должны ли подписываться письма. Возможные варианты:
«dkim=all» – все письма должны подписываться
«dkim=discardable» – неподписанные письма не должны приниматься
«dkim=unknown» – то же самое, что и отсутствие такой записи.
После создания записей изменяем serial и перезагружаем настройки bind'а, если у вас установлен он. И теперь осталось последнее – настроить почтовый сервер. В качестве почтового сервера возьмем Postfix.

Настройка поддержки DKIM почтовым сервером Postfix.

Последняя и, пожалуй, самая важная часть – включение подписи писем почтовым сервером. Самое первое, что нужно сделать на этом этапе, – это установить opendkim:

apt-get  install opendkim

Теперь необходимо настроить этот сервис. Первым делом поменяем файл /etc/default/opendkim. Впишем туда следующую строчку:

SOCKET="inet:10024@localhost"

Теперь наш сервер будет запускаться на порту 10024 на loopback-интерфейсе. Следующий файл, который необходимо изменить, – это /etc/opendkim.conf.

Раскомментируем строчку со словом Domain, вписываем название нашего домена:

Domaindomain.ru

Теперь указываем файл с приватным ключом:

KeyFile/etc/sll/private/dkimprivate.key

После этого указываем селектор, который мы использовали для сгенерированного ранее публичного ключа, указывая его в записи DNS. В нашем случае это «mail»:

Selectormail

Дописываем строчку:

Backgroundyes

Теперь можно рестартовать opendkim:

service opendkim restart

И последний шаг – настройка непосредственно Postfix'а. Изменяем файл /etc/postfix/main.cf. Добавим туда следующие строчки:

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:10024
non_smtpd_milters = inet:localhost:10024

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

Authentication-Results: mx.google.com;
spf=pass(google.com:>domain of user@domain.ru designates 62.113.208.35 as permitted sender) smtp.mail=user@domain.ru;
dkim= pass header.i=@domain.ru

Если вы видите строчки «spf=pass» и «dkim=pass», значит вы все сделали правильно и ваш почтовый сервер теперь будет значительно лучше восприниматься другими почтовыми серверами, с чем я вас и поздравляю

Программа MTR (сокращенно от My TraceRoute) – это программа для мониторинга прохождения пакетов, позволяющая определить узел, на котором происходят потери пакетов. Кроме простоты использования ее также отличает наличие как графического интерфейса, так и текстового, поэтому ее удобно использовать как на десктопных конфигурациях, так и на серверах без графической подсистемы.

Установка MTR

В Debian/Ubuntu для установки MTR достаточно команды

apt-get install mtr

И сразу после установки программой можно сразу пользоваться

Loss % – все потерянные пакеты между компьютером и серверами.

SNT – количество отправленных пакетов.

LAST – Задержка последнего отправляемого пакета .

Avrg – Среднее время ожидания всех пакетов.

Best – Отображает лучший Round Trip Time для этого пакета на этом хосте (shortest RTT).

Disregard 100% – это сто процентная потеря если есть другие узлы, перечисленные после.

Wrst – Отображает худший Round Trip Time для этого пакета на этом хосте (longest RTT).

Графический режим

Для запуска в графическом режиме вызываем окно для запуска программ (часто это Alt+F2) и вводим «mtr», или в меню графической оболочки просто выбираем из списка программ «Mtr».

Интерфейс простой, он включает в себя следующие элементы: IP-адрес или имя хоста, интервал посылки пакетов, кнопка «Пауза», кнопка «Рестарт», кнопка «О программе», кнопка «Выход» и самый главный элемент: информационное поле, содержащее информацию о трассе и потерях пакетов.

Всё, что надо сделать – это просто ввести имя хоста и нажать клавишу «Enter».

 

Вы видите список всех узлов, через которые проходят пакеты до указанного вами хоста.

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

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

Текстовый режим работы

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

-h, –help Краткая справка
-v, –version Вывод версии программы
-c <число>
–report-cycles <число>
Количество циклов проверки (количество отправленных пакетов по сути)
-r
–report
Режим отчета. Программа выполнит указанное при помощи параметра -c количество циклов, выведет отчет и завершит свою работу.
-w
–report-wide
Режим расширенного отчета. Результат такой же, как и при использовании опции -r, но длинные имена хостов обрезаться не будут.
-s <количество-байт>
–psize <количество-байт>
Установить размер пакетов для отправки. Кроме этого можно указать размер пакета при помощи переменной окружения PACKETSIZE, например, такой командой:
«PACKETSIZE=1024 mtr <опции>»
-t
–curses
Форсированный запуск в текстовом режиме. По умолчанию MTR запускается в графическом режиме, если он доступен.
-e
–MPLS
Отображать метки MPLS (Multiprotocol Label Switching), коммутации по меткам трафика, которые закодированы в ответе
-n
–nodns
Не использовать DNS для разрешения имен хостов и отображать вместо них IP-адреса
-o «список-полей»
–order «список полей»
Отображать только указанные поля и в таком порядке, в котором они были указаны
-g
–gtk
Форсировать работу в графическом интерфейсе, если он доступен. Эта опция работает только в том случае, если MTR собран с поддержкой графического режима (а это вполне может быть не так)
-p
–split
Выводить информацию построчно, без перерисовки экрана, с разделением полей пробелом. Этот формат удобен, если вы используете какую-то дополнительную программу-парсер или скрипт для анализа, которому передаются данные.
-l
–raw
Использовать «сырой» формат вывода. То есть выводить неформатированные данные
-a <IP-адрес>
–address <IP-адрес>
Указать адрес интерфейса, с которого будут отправляться пакеты
-i <число-секунд>
–interval <число-секунд>
Интервал между отправляемыми запросами
-u Использовать протокол UDP для отправки пакетов
-4 Использовать только IPv4
-6 Использовать только IPv6

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

Возможно, вы уже слышали про owncloud. Это сервис, позволяющий вам создать собственные сервис синхронизации данных между несколькими компьютерами под разными операционными системами. Аналогичные сервисы, с которыми вы, возможно знакомы: Dropbox и Яндекс.Диск. Однако, если вам недостаточно места, либо вы не хотите отдавать свои данные на хранение сторонней компании, owncloud именно то, что вам нужно. Кроме полного контроля над своими данными вы также получите возможность хранения файлов и контактов, календарь. Кроме того, у owncloud есть клиенты под Windows, Linux и Android, поэтому проблем с доступом из различных операционных систем не будет. К тому же, установка owncloud достаточно проста.
Continue Reading

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

Для подключения виртуального диска в формате VDI используется программа vdfuse, входящая в состав пакета virtualbox-fuse.

Установка пакета

В Debian/Ubuntu пакет устанавливается командой

Если у вас установлена версия VirtualBox от Oracle, может потребоваться установить по зависимостям VirtualBox OpenSource Edition (virtualbox-ose).

Подключение диска

На первом этапе монтируется образ VDI. Это можно сделать следующей командой:

Таким образом мы получим доступ к разделам, которые присутствуют на виртуальном диске. На втором этапе монтируется необходимый раздел:

После этого можно работать с файловой системой на виртуальном разделе.

Параметры командной строки vdfuse

В общем виде формат выглядит так:

Вот какие опции есть у vdfuse:

Опция Значение
-h Помощь
-r Монтировать только для чтения
-t Указать тип образа диска (VDI, VMDK, VHD, или raw). Значение по умолчанию – auto
-f Указать имя файла образа диска
-a Разрешить всем пользователям читать диск
-w Разрешить всем пользователям читать диск и писать на него
-g Работать как приложение (не в фоновом режиме)
-v Выводить дополнительную информацию
-d Включить режим отладки
2

Чем отличается настройка iptables в Debian от других операционных систем? Тем, что достаточно давно сложилось так, что способ загрузки правил iptables оставался на усмотрение администратора, который администрирует сервер. И хотя позже появились такие решения, как ufw, пришедший из Ubuntu, или iptables-persistent, все равно может потребоваться реализовать автоматическую загрузку таблиц самостоятельно. И есть несколько способов это сделать…

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

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

Команда iptables-save выдает на стандартный вывод действующие в данный момент правила iptables, поэтому для сохранения их в файл надо использовать перенаправление потоков:

Команда iptables-restore делает, как вы уже догадались, обратное. То есть восстанавливает правила iptables. Работает она тоже со стандартными потоками, поэтому загрузка правил будет выглядеть так:

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

Способ 1. Простой способ.

Самый простой способ загрузки таблиц – это вызывать загрузку после поднятия основного сетевого интерфейса при помощи параметра post-up, размещенного в файле /etc/network/interfaces

Что для этого потребуется? В первую очередь нам потребуется директория, в которой будут храниться файлы с таблицами. В соответствии со стандартом FHS, это будет /etc/iptables/, в ней мы будем хранить файлы с правилами, полученными при помощи iptables-save. Перед настройкой правил сначала сбросим содержимое правил по умолчанию:

Теперь посмотрим, что у нас получилось:

У вас должны быть чистые списки правил. Это состояние желательно сохранить на случай необходимости сброса правил.

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

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

Теперь делаем еще одно действие, которое нам позволит не переписывать название файла с правилами для загрузки. Создаем символическую ссылку на файл, в который мы только что сохранили правила. Пусть это будет файл iptables-20130904-223007, тогда делаем так:

И последнее, что надо сделать – изменить файл /etc/network/interfaces, дописав одну строчку. Должно получиться примерно следующее:

И после этого сохраняем.

В общем, вот и всё. Теперь после поднятия интерфейса правила iptables будут загружены автоматически. Какие у этого способа есть минусы? Если кто-нибудь изменит файл /etc/network/interfaces, например, какая-нибудь программа-менеджер сети, то строчка с загрузкой правил может потеряться. Не факт, конечно, но вероятность есть. Второе – если у вас несколько сетевых интерфейсов, то вам надо либо вешать на событие post-up каждого интерфейса, либо точно знать, что выбранный вами интерфейс точно поднимается. Вариация этого способа – размещение скрипта загрузки правил в директории /etc/network/{if-pre-up.d|if-up.d}. В таком случае По соответствующему событию правила будут загружаться автоматически.

Способ 2. Совсем простой способ.

Еще более простой способ, которым многие пользуются – это написать шелл-скрипт загрузки правил и вызывать его из, например, /etc/rc.local или еще из какого-нибудь места при загрузке системы. Минус тут очевиден – для сохранения текущего состояния надо будет править этот самый скрипт, что не есть хорошо и удобно. Предыдущий способ в этом смысле выигрывает.

Способ 3. Самый сложный, но и самый интересный с моей точки зрения.

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

Начнем с того, что создадим наш скрипт и поместим его в директорию /etc/init.d, где у нас хранятся скрипты для других сервисов.

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

 

Это наш шаблон скрипта сервиса, который мы с вами сейчас будем доводить до ума.

У нас уже есть обработка параметров и тела всех функций, осталось только написать внутренности этих функций. Начнем со старта, напишем содержимое функции do_start:

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

После этих действий цепочки iptables будут, но никаких запретов не будет. Следующая функция, которую мы напишем – do_list (). Ее задача – вывести список файлов с правилами. И можно сразу указать, какой из них считается файлом по умолчанию.

Теперь мы можем просмотреть список файлов с правилами и сказать, какой из этих файлов является файлом по умолчанию. Это нам необходимо для того, чтобы в дальнейшем можно было указывать, какой файл с правилами должен быть по умолчанию. Следующая функция – do_makedefault (). Ее задача – сделать некоторый файл с правилами файлом по умолчанию, чтобы он загружался автоматически при старте нашего скрипта. Поскольку файл, который у нас загружается, всегда будет иметь одно и то же название, он всегда будет просто символической ссылкой, а указывать эта ссылка будет на разные файлы. В этой функции у нас будет использоваться еще один параметр скрипта, поэтому добавим значение $2 в вызов функции в структуре case. Должно получиться так:

Итак

В самой функции этот параметр превратится в $1, потому что для скрипта он второй, а для функции – первый. Как вы видите ,мы просто удаляем символическую ссылку с названием iptables.default и делаем новую на тот файл, название которого указано. Указывать надо только имя файла, путь указывать не нужно. А флаг -f мы используем для подавления сообщения об ошибке, если такого файла не существует.

И осталась последняя функция – do_savecurrent (). Она будет тоже выполнять всего одно несложное действие – сохранять текущие правила iptables в файл с включенным в название временем сохранения этих самых правил.

Вот, собственно, сам скрипт почти закончен. Осталось сделать еще одну малость – автоматическое создание директорий, в которых будут храниться правила, если их не существует, и, если файл /etc/iptables/iptables.default не существует, то сбросим правила и политики и создадим файл iptables.clean, после чего создадим символическую ссылку на него с названием iptables.default. Для этого напишем отдельную функцию do_init ():

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

Осталось теперь включить получившийся скрипт в автозапуск:

Всё. Теперь правила будут загружаться каждый раз после загрузки, после выполнения скрипта networking. Если сеть стартовать при использовании LSBInit не будет, то правила фаервола загружаться тоже не будут. Надеюсь, этот скрипт будет вам полезен. Любые замечания в комментариях приветствуются.