Доброго времени суток.
Есть схема из 1 мастера и 2х слэйвов для нескольких зон (bind9). Слэйвы имеют белые ip-адреса. С одной зоной все прекрасно, с другой есть странная проблема: задал mx запись (указывающую на mx.yandex.ru.), но обращаясь даже напрямую к одному из двух слэйвов в ответ на -type=mx я получаю soa о_О, как будто mx записи нет. nslookup -type=ns для этой зоны (назовем ее vasya.ru) указывает на мои ns, serial корректно меняется при rndc reload. Вот содержание зоны (имя изменено):

root@ns2:/home/kagerro# cat /var/cache/bind/vasya.ru
$ORIGIN .
$TTL 3600       ; 1 hour
altsmb.ru               IN SOA  ns2.petya.ru. support.petya.ru (
                                2016071401 ; serial
                                7200       ; refresh (2 hours)
                                1800       ; retry (30 minutes)
                                259200     ; expire (3 days)
                                900        ; minimum (15 minutes)
                                )
                        NS      ns1.petya.ru.
                        NS      ns2.petya.ru.
                        A       x.x.x.x
$ORIGIN vasya.ru.
www                     A       x.x.x.x
                        MX      10 mx.yandex.ru.

Доброго времени суток.
debian 7.11, openvpn. На машине 2 физических интерфейса - 10.12.0.2 (этот слушает 1194) и 192.168.0.2. В server.conf есть опция push «route 192.168.0.0 255.255.255.0» и сделан нат в 192.168.0.0 (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE). Все клиенты нормально попадают в 192.168.0.0. Теперь для некоторых клиентов нужно сделать доступ еще и в 10.12.0.0, делаю в клиентском каталоге (/etc/openvpn/ccd) соответсвующие файлы с добавлением push «route 10.12.0.0 255.255.255.0» и делаю нат в 10.12.0.0 (iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE). Теперь некоторые клиенты (для которых эта опция есть в файлах в ccd каталоге) попадают также в 10.12.0.0. НО, если клиент для которого нет этой опции руками запишет себе маршрут в 10.12.0.0, то тоже туда попадает. Вопрос - как этого избежать? единственный приходящий мне в голову вариант - пушать клиентам с доступом в 10.12.0.0 конкретные адреса для tun интерфейса и разрешать nat в 10.12.0.0 только им. Есть какой-то другой вариант?

Доброго времени суток. debian 7.11
Со стороны клиента получал сообщение о timed out, в логе сервера имел следующее:

Wed Jun 15 15:00:57 2016 some_ip_addr:2653 CRL: cannot read: /etc/openvpn/crl.pem: Permission denied (errno=13)

root@ovpn:~# ls -l /etc/openvpn/
итого 40
-rw------- 1 root root 1143 Июн 14 16:24 ca.crt
-rw------- 1 root root  613 Июн 14 16:24 crl.pem
-rw------- 1 root root  424 Июн 14 16:29 dh.pem
-rw-r--r-- 1 root root  986 Июн 14 15:50 openssl.cnf
-rw-r--r-- 1 root root  608 Июн 15 15:23 server.conf
-rw------- 1 root root 1834 Июн 14 16:25 server.key
-rw------- 1 root root  636 Июн 14 16:30 ta.key
-rwxr-xr-x 1 root root 1357 Дек  2  2014 update-resolv-conf
-rw------- 1 root root 4356 Июн 14 16:24 vpn-server.crt

Добрый день.
Имеется debian 7.11, пытаюсь настроить openvpn, делаю по статье https://habrahabr.ru/post/233971/. Не могу понять некоторых вещей касательно openssl.cnf:
1. зачем он нужен вообще? я использую easyrsa3, зачем какой-то конфиг в /etc/openvpn кроме server.conf?
2. в статье приведен пример конфига openssl.cnf и меня смущают вот эти строки:

[ req_distinguished_name ]
organizationName = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName = Location Name
commonName = Common User or Org Name
commonName_max = 64

Доброго времени суток.
Debian 7.9.
ntp.conf:

server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org

driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntpstats

restrict default ignore

restrict 127.0.0.1

restrict 10.12.0.0 mask 255.255.255.0 nomodify notrap nopeer

restrict server 0.ru.pool.ntp.org
restrict server 1.ru.pool.ntp.org

server 127.127.1.1
fudge 127.127.1.1       stratum 3

ntpdate показывает offset с 0.ru.pool.ntp.org 4,5 секунды, ntpdate -s или перезагрузка ntp не помогает:

root@ntpd1:~# ntpdate -q 0.ru.pool.ntp.org
server 185.22.60.71, stratum 2, offset 4.555476, delay 0.06512
server 194.190.168.1, stratum 1, offset 4.558135, delay 0.06430
server 195.3.254.2, stratum 2, offset 4.558638, delay 0.07858
server 93.180.6.3, stratum 2, offset 4.558636, delay 0.06479
24 Mar 12:22:12 ntpdate[19440]: step time server 194.190.168.1 offset 4.558135 sec

Доброго времени суток.
Пытаюсь установить debian 7.8 netinst, и по всем зеркалам в списке получаю в 4й консоли сабжевые сообщения (даже для ftp://ftp.ru.debian.org). Полагаю, такого быть не должно, есть идеи?

Доброго времени суток.
Centos 6.6. Нужно запускать скрипт при поднятии интерфейса (например, eth2). В конце ifup-post имею:

#!/bin/sh
if [ -x /sbin/test_sc ]; then
    /sbin/test_sc ${DEVICE}

Содержание test_sc:

#!/bin/bash
if [ "$DEVICE" == "eth2" ]; then
        ip rule del from 8.8.8.8
        ip route add default via 8.8.8.9 table tablex
        ip rule add from 8.8.8.8 table tablex
fi

test_sc исполняемый, таблица tablex rt_tables добавлена.

При перезагрузке сети скрипт не выполняется. Я не особо линуксоид и с кеносами/редхатами не работал. В дебиане просто ложил скрипт в if-up.d и был доволен. Выше указанный метод подсмотрел здесь http://xmodulo.com/how-to-run-startup-script-automatically-after-network-inte.... Подскажите пожалуйста что я делаю не так.

Доброго времени суток.
squid3, debian wheezy. Была проблема с доступом к некоторым ресурсам, например yandex.ru (хотя, ya.ru работал нормально). В логах фигурировала запись вида

....tcp_miss/503...

taino@nax1:~# cat /etc/sysctl.d/disableipv6.conf
net.ipv6.conf.all.disable_ipv6=1

TCP_MISS/200 156 CONNECT mc.yandex.ru:443 - DIRECT/93.158.134.119 -

Доброго времени суток. Есть мастер и 2 слэйва bind9 для зоны zone.ru. Зона делегирована 2м слэйвам ns1.zone.ru и ns2.zone.ru. Обнаружил, что:

dig @ns1.zone.ru zone.ru axfr

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

options {
        directory "/var/cache/bind";
        listen-on { any; };
        allow-query { any; };
        dnssec-validation auto;
        recursion no;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
        version "unknown";
        transfers-per-ns 3;
};

zone "zone.ru" {
        type slave;
        file "zone.ru";
        //ip мастера - это адрес gre интерфейса мастера, через 
        //который ходит трансфер и нотифаи
        masters { 10.0.1.3; };
        allow-notify { 10.0.1.3; };
        notify no;
        transfer-source 10.0.1.1;
};

Доброго времени суток.
Bind9 авторитетный для domain.ru и домен.рф. Необходимо сделать перенаправление для записи домен.рф на domain.ru (записи на вершине зоны).
Часть зоны домен.рф:

$ORIGIN xn--d1acufc.xn--p1ai.
$TTL 1h
@       IN      SOA     ns2.domain.ru. support.domain.ru. (
                        2015042705
                        2h
                        30m
                        3d
                        15m
                        )
        IN      NS      ns1.domain.ru.
        IN      NS      ns2.domain.ru.
;@      IN      CNAME   domain.ru.
www     IN      CNAME   domain.ru.

Доброго времени суток. Есть несколько vm (vSphere 5) с гостями debian7. Машины живут около 2х месяцев, не раз перезагружались (корректно). На выходных были выключены некорректно (выключение питания). После запуска обнаружилась проблема на всех 3х машинах - имена служб перестали «добиваться» в командах, например:

service networking restart

Доброго времени суток. Собственно вопрос в заголовке, нужны ли корректные ptr записи для хостов, указанных в NS записях зоны? Я таких требований не обнаружил, более того, если указать в nic.ru сервера для делегирования зоны, то все работает и без корректных ptr. Однако, при попытке настроить условную пересылку на windows DNS сервере происходит ошибка при проверке сервера имен, т.е. адрес x.x.x.x резолвится не в нужный мне ns.example.org, а например в vasyan.super.pro (что логично, ведь я не подавал заявку на исправление ptr).

Доброго времени суток.
Хочу уточнить для себя такой момент: сколько времени будет храниться RR в кэше резолвера, если он получил запись не от авторитетного за зону сервера, а от кэширующего спустя N времени. Например:
ns.txx.ru получает A запись tt.example.org (у которой TTL 24 часа) от ns, авторитетного за зону example.org. Спустя 4 часа я запрашиваю эту запись у ns.txx.ru и получаю ее из кэша. В кэше моего резолвера эта запись будет храниться 20 часов или 24?

Доброго времени суток.
Собственно, вопрос - fail или softfail. Читал, что может быть проблема при пересылке писем, но при пересылке отправляющий хост же тоже подменяется. Я не могу представить себе ситуацию когда -all может создать проблему. Может кто-то просветить меня какие минусы несет -all?

Доброго времени суток. После прочтения RFC5617 не все вопросы по использованию ADSP устранились.
1. Значения для тэга dkim (unknown, all, disardable) понятны. Вопрос в том, как это влияет на рецепиента. Я имею в виду, поведение при запросе _adps._domainkey... настраивается на сервере-рецепиенте (я не имел дел с почтовыми серверами) или как? Т.е. я могу задать значение discardable, но решение, принимать ли неподписанное или неверно подписанное письмо, все же за сервером-рецепиентом и гипотетически он может принять и неверно подписанное письмо даже при значении dkim=discardable?
2. Имеет ли смысл вообще заводить запись для ADSP со значением dkim=unknown? Как я понял это равносильно отсутствию записи.
3. Что означают строки «Unrecognized tags MUST be ignored.» и «Any other values (здесь о значении тэга dkim) are treated as „unknown“.». Любые значения кроме all, discardable и all будут игнорироваться рецепиентом и подменяться на unknown?
4. Порядок ADSP lookup меня слегка смутил, описание довольно путанное. Вот как я его понял, поправьте пожалуйста, если я не прав:

Процедура проверки ADSP состоит из 2-х шагов, которые могут выполняться параллельно:
1. Проверка существования домена. Совершается DNS-запрос записи, соответствующей домену отправителя без всяких префиксов (вроде "_adsp..."). Тип запроса может быть любым, т.к. цель - просто удостовериться в существовании домена, например подойдет запрос MX записи. Если домен не существует (ответ NXDOMAIN, rcode=3) алгоритм ADSP lookup останавливается с ошибкой.
2. Проверка ADSP. Запрашивается запись с префиксом "_adsp._domainkey.", соответствующая домену отправителя.
a. Если результат rcode=0 с одной записью, которая является корректной TXT ADSP для этого домена, то она и будет использоваться, алгоритм ADSP lookup завершается.
b. Вот это вообще не понял:
If the result of the query is NXDOMAIN or NOERROR with zero
      records, there is no ADSP record.  If the result of the query
      contains more than one record, or a record that is not a valid
      ADSP record, the ADSP result is undefined
Что означает "undefined", т.е. рецепиент будет вести себя как будто ADSP записи не существует? И как может быть rcode=0 с 0 записей? Т.е. NXDOMAIN возвращается только при отсутствии домена, а rcode=0 с 0 записей, если домен существует, но нет TXT записи с указанным префиксом?

Здравствуйте. Debian 7.8. Нужно при загрузке сетевой подсистемы восстанавливать содержимое одной таблицы и добавлять правило:

ip route add default via x.x.x.x table HH
ip rule add from x.x.x.y table HH

Доброго времени суток.
Попытаюсь описать проблему: debian 7.8, 2 интерфейса:
eth0 #локальный
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
eth1 #белый
address 80.80.80.46 #адресация вымышленная
netmask 255.255.255.240
gateway 80.80.80.33
route

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
80.80.80.32     *               255.255.255.240 U     0      0        0 eth1
localnet        *               255.255.255.0   U     0      0        0 eth0

Доброго времени суток. Тестовая схема мастер и 2 слэйва. До внедрения view трансфер и нотифаи проходили нормально, после внедрения - нет. На сколько я знаю, view влияет только на ответы на запросы, а не на трансфер или я не прав?
named.local на мастере:

acl "localnet" { 194.135.107.0/24; };

view "internal" {
        match-clients { "localnet"; };
        match-destinations { 194.135.107.163; };
        match-recursive-only no;
        zone "test.ru" {
                type master;
                file "internal.test.ru";
                allow-transfer { 10.0.1.1; 10.0.2.2; };
                notify explicit;
                also-notify { 10.0.1.1; 10.0.2.2; };
        };
};

view "external" {
        match-clients { "any"; };
        match-destinations { 194.135.107.163; };
        match-recursive-only no;
        zone "test.ru" {
                type master;
                file "external.test.ru";
                allow-transfer { 10.0.1.1; 10.0.2.2; };
                notify explicit;
                also-notify { 10.0.1.1; 10.0.2.2; };
        };
};

acl "localnet" { 194.135.107.0/24; };

view "internal" {
        match-clients { "localnet"; };
        match-destinations { 194.135.107.162; };
        match-recursive-only no;
        zone "test.ru" {
                type slave;
                file "internal.test.ru";
                masters { 10.0.2.3; };
                allow-notify { 10.0.2.3; };
                notify no;
                transfer-source 10.0.2.2;
        };
};

view "external" {
        match-clients { "any"; };
        match-destinations { 8.8.8.8; };
        match-recursive-only no;
        zone "test.ru" {
                type slave;
                file "external.test.ru";
                masters { 10.0.2.3; };
                allow-notify { 10.0.2.3; };
                notify no;
                transfer-source 10.0.2.2;
        };
};

............
25-Mar-2015 10:33:23.895 general: notice: running
25-Mar-2015 10:33:23.896 general: info: zone test.ru/IN/internal: refresh: unexpected rcode (REFUSED) from master 10.0.2.3#53 (source 10.0.2.2#0)
25-Mar-2015 10:33:23.896 general: info: zone test.ru/IN/internal: Transfer started.
25-Mar-2015 10:33:23.897 xfer-in: info: transfer of 'test.ru/IN/internal' from 10.0.2.3#53: connected using 10.0.2.2#42426
25-Mar-2015 10:33:23.897 xfer-in: error: transfer of 'test.ru/IN/internal' from 10.0.2.3#53: failed while receiving responses: REFUSED
25-Mar-2015 10:33:23.897 xfer-in: info: transfer of 'test.ru/IN/internal' from 10.0.2.3#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
25-Mar-2015 10:33:24.396 general: info: zone test.ru/IN/external: refresh: unexpected rcode (REFUSED) from master 10.0.2.3#53 (source 10.0.2.2#0)
25-Mar-2015 10:33:24.396 general: info: zone test.ru/IN/external: Transfer started.
25-Mar-2015 10:33:24.397 xfer-in: info: transfer of 'test.ru/IN/external' from 10.0.2.3#53: connected using 10.0.2.2#58400
25-Mar-2015 10:33:24.398 xfer-in: error: transfer of 'test.ru/IN/external' from 10.0.2.3#53: failed while receiving responses: REFUSED
25-Mar-2015 10:33:24.398 xfer-in: info: transfer of 'test.ru/IN/external' from 10.0.2.3#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)

Доброго времени суток. Схема из 1 мастера (192.168.1.1) и 2х слэйвов (192.168.1.2 и 192.168.1.3). Для трансфера зоны и нотифаев сделаны gre-туннели
мастер (10.0.1.1) - слэйв1 (10.0.1.2)
и
мастер (10.0.2.1) - слэйв2 (10.0.2.2)
Сделано это, дабы избежать какой-либо фильтрации между ними при передаче зон и нотифаях.
Проблема в том, что если не указывать notify-source на мастере, то оповещения на слэйвы приходят не с 10.0.1.1 и 10.0.2.1 соответственно, а с 192.168.1.1 (хотя в masters указан 10.0.1.1 и 10.0.2.1 соответственно на слэйв1 и слэйв2), и естественно такие оповещения отвергаются. Судя по всему в notify-source можно указать только 1 адрес или * - что означает default IP, но мне нужно указать 2 адреса. Может кто-нибудь подсказать как быть?

P.S. я делал gre-туннели с одинаковым адресным пространством, однако приходилось удалять «connect» маршруты и заводить отдельные, т.к. на мастере 2 gre-интерфейса, я задавал здесь вопрос по этому поводу и мне сказали что с такой схемой я могу получить много подводных камней. И даже если адрес на мастере был бы 1 а не 2 (10.0.1.1 и 10.0.2.1), то интерфейса-то все равно 2 и сомневаюсь, что нотифаи отправлялись бы с обоих.

Доброго времени суток.
Нужен совет по конфигурации схемы авторитетных серверов. Вся адресация и имя зоны вымышленные. Зона test.ru. Как я это себе представляю:
1 мастер:
(ns1): eth0 192.168.1.1
2 слэйва:
(ns2): eth0 192.168.1.2 и eth1 8.8.8.8 (будет указан для делегирования зоны в личном кабинете)
(ns3): eth0 192.168.1.3 и eth1 8.8.4.4 (будет указан для делегирования зоны в личном кабинете)

трансфер зоны и нотифай будут передаваться через gre-туннели на интерфейсах в локальной сети, чтобы мастер и слэйвы не фильтровали друг друга. eth1 - только для запросов извне, eth0 - для запросов изнутри (будет сделан forward для зоны на локальном dns-сервере на эти интерфейсы).
recursion отключен. Эти три машины будут выступать только в роли авторитетных за зону test.ru и больше никаких функций выполнять не будут.

Планирую использовать view, чтобы на запросы из внутренней сети отдавался файл зоны, где в качестве A записей для NS были указаны адреса внутренних интерфейсов. Вопрос в том, как будет выглядеть файл зоны для запросов извне, я не хочу указывать в ns мастер, т.к. у него не будет белого ip-адреса (или придется указывать в A-записи для ns1 локальный адрес, что бесполезно для запросов извне), но в таком случае будет ли производиться трансфер и будет ли ns1 он считаться мастером для зоны. Или может для ns1 стоит указать фэйковый ip-адрес, ведь он все равно не будет указан для делегирования. Дайте пожалуйста совет.