LINUX.ORG.RU
ФорумAdmin

Ошибки в логах Bind

 


1

1

Имеем bind

BIND 9.9.5-3ubuntu0.7-Ubuntu (Extended Support Version) <id:f9b8a50e> built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
compiled by GCC 4.8.2
using OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014
using libxml2 version: 2.9.1

Ubuntu 14.04 x64
Сервер IBM x3550

При сетевом трафике в 30-40 mbit/s и выше сыпятся постоянно ошибки
17-Feb-2016 12:25:09.875 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:09.875 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.610 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.610 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.611 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.611 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.612 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.612 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.612 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.612 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.612 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.612 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:11.612 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:11.612 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:14.085 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:14.085 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:14.085 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:14.085 general: error: internal_send: 127.0.0.1#33778: Invalid argument
17-Feb-2016 12:25:19.554 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:19.554 general: error: socket.c:1915: unexpected error:
17-Feb-2016 12:25:19.554 general: error: internal_send: 127.0.0.1#55331: Invalid argument
17-Feb-2016 12:25:19.554 general: error: internal_send: 127.0.0.1#55331: Invalid argument


Нагрузки по RAM или CPU нету. Тариф 100мбит. так что в ширину канала тоже не упирается.

Конфиг bind обычный
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
options {
        directory "/var/cache/bind";
        statistics-file "/var/cache/bind/named.stats";
        dnssec-validation auto;
        auth-nxdomain no;
        recursion yes;
        listen-on {
                127.0.0.1;
                192.168.60.1;
                192.168.2.1;
                };
        allow-recursion {
                127.0.0.0/8;
                192.168.48.0/20;
                192.168.2.0/24;
                };
        forwarders {
                77.88.8.8;
                77.88.8.1;
                };
        allow-query {
                any;
                };

};

statistics-channels {
     inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};


zone "." {
        type hint;
        file "/etc/bind/db.root";
};



zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
        };

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
        };


logging {
        channel bind.log {
                file "/var/lib/bind/bind.log";
                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        category general {
                bind.log;
                };
        category general {
                bind.log;
                };
        category resolver {
                bind.log;
                };
        category notify {
                bind.log;
                };
        category client {
                };
        category queries {
                bind.log;
                };
        };

★★

Ответ на: комментарий от blind_oracle

Конечно поднят

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0a:cd:2a:27:b3 brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.xxx/30 brd xxx.xxx.xxx.xxx scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:cdff:fe2a:27b3/64 scope link
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:1a:64:11:af:ad brd ff:ff:ff:ff:ff:ff
    inet 192.168.60.1/20 brd 192.168.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0:2
       valid_lft forever preferred_lft forever
    inet 192.168.25.1/24 brd 192.168.25.255 scope global eth0:25
       valid_lft forever preferred_lft forever
    inet 192.168.8.1/24 brd 192.168.8.255 scope global eth0:8
       valid_lft forever preferred_lft forever
    inet 192.168.15.1/24 brd 192.168.15.255 scope global eth0:15
       valid_lft forever preferred_lft forever
    inet6 fe80::21a:64ff:fe11:afad/64 scope link
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:1a:64:11:af:af brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.xxx/28 brd xxx.xxx.xxx.xxx scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::21a:64ff:fe11:afaf/64 scope link
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.20.30.1/24 brd 10.20.30.255 scope global tun0
       valid_lft forever preferred_lft forever

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

1. Бинд не в чруте случаем? Если да то сделать нормально.

2. Попробовать убрать ipv6 в системе вообще и в бинде (опцией -4 вроде) в частности.

3. В dmesg есть что?

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

1. нет
2. уже стоит, все равно ошибка.
3. Вообще ничего.

as_lan ★★
() автор топика
Ответ на: комментарий от blind_oracle

Немного поковырял и выяснилось что это связанно со сквидом.

127.0.0.1#33778: Invalid argument

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

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

1. Бинд не в чруте случаем? Если да то сделать нормально.

А чем плох bind в chroot ? У меня больше десятка лет так работает, проблем не вижу.

AS ★★★★★
()
Ответ на: комментарий от AS

Та ничем, в общем, если правильно приготовлен. Просто решая проблему конфигурацию нужно пытаться упростить :)

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Еще бы знать какие лимиты проверить.

as_lan ★★
() автор топика
Ответ на: комментарий от blind_oracle

Собрал сегодня dnsperf. за 60 секунд

  Queries sent:         36754
  Queries completed:    36362 (98.93%)
  Queries lost:         392 (1.07%)


так что не думаю, что какие-то лимиты. В обычное время бинд в минуту и 200 запросов не обрабатывает. А тут 36362. И причем в этот момент не было ошибок. Но в течении дня все же встречаются ошибки. И сквид как оказалось не причем. Убрал сквид. Пользователи идут напрямую. DNS обрабатывает только напрямую их запросы (а не через сквид, как до этого). И все равно ошибки.

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

Ты пойми, что это ошибки не бинда, а ядра. Бинд использует системные вызовы для открытия сокета и отправки в него данных. При отправке ядро ему возвертает invalid argument по какой-то причине. Наиболее вероятно что он пытается отправить на всякие unrouted сети, либо из-за каких-то настроек ядра неправильно выбирается source адрес.

Посмотри что у тебя настроено нестандартно и\или криво в сетевой части, в sysctl и т.п.

blind_oracle ★★★★★
()
Ответ на: комментарий от hotpil

Я в курсе как это читается, но мне как-то похер, ибо «байнд» выглядит стрёмно. Иди сублимируй в другое место.

blind_oracle ★★★★★
()
Ответ на: комментарий от as_lan

ну так попроси бинд использовать определенный диапазон портов через «use-v4-udp-ports { range xxxx yyyy; };» который не пересекается с /proc/sys/net/ipv4/ip_local_port_range

vel ★★★★★
()
Ответ на: комментарий от vel

Я ж сегодня ответил уже. Сквид не причем. Без сквида тоже эти ошибки.

24-Feb-2016 15:54:07.217 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:07.217 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:07.217 general: error: internal_send: 192.168.60.229#61422: Invalid argument
24-Feb-2016 15:54:07.217 general: error: internal_send: 192.168.60.229#61422: Invalid argument
24-Feb-2016 15:54:15.930 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:15.930 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:15.930 general: error: internal_send: 192.168.60.189#61597: Invalid argument
24-Feb-2016 15:54:15.930 general: error: internal_send: 192.168.60.189#61597: Invalid argument
24-Feb-2016 15:54:19.616 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:19.616 general: error: socket.c:1915: unexpected error:
24-Feb-2016 15:54:19.616 general: error: internal_send: 192.168.60.158#56682: Invalid argument
24-Feb-2016 15:54:19.616 general: error: internal_send: 192.168.60.158#56682: Invalid argument
24-Feb-2016 15:54:53.006 general: error: internal_send: 192.168.60.118#60760: Invalid argument
24-Feb-2016 15:54:53.006 general: error: internal_send: 192.168.60.118#60760: Invalid argument

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

хм, а nat на этой машине есть или блокирующие правила в iptables по состоянию соединения (интересует только local output)

vel ★★★★★
()
Ответ на: комментарий от vel

Сейчас везде ACCEPT, в syslog куча ошибок подобного рода

Feb 24 17:09:52 router named[15428]: client 127.0.0.1#56232 (cs633922.vk.me): error sending response: invalid file
Feb 24 17:09:53 router named[15428]: client 127.0.0.1#56232 (cs627329.vk.me): error sending response: invalid file
Feb 24 17:09:53 router named[15428]: client 127.0.0.1#56232 (cs628630.vk.me): error sending response: invalid file
Feb 24 17:09:53 router named[15428]: client 127.0.0.1#56232 (cs627227.vk.me): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (cs633529.vk.me): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (cs631118.vk.me): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (cs630328.vk.me): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (sync.1dmp.io): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (cs629122.vk.me): error sending response: invalid file
Feb 24 17:10:01 router named[15428]: client 127.0.0.1#56232 (cs509107v4.vk.me): error sending response: invalid file
Feb 24 17:10:09 router named[15428]: client 192.168.60.233#52569 (r.mail.ru): error sending response: invalid file
Feb 24 17:10:16 router named[15428]: client 127.0.0.1#56232 (b.scorecardresearch.com): error sending response: invalid file
Feb 24 17:10:16 router named[15428]: client 127.0.0.1#56232 (top-fwz1.mail.ru): error sending response: invalid file

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

В сети есть еще один тестовый сервер. Slave (проблемный master). В сквиде указывают dnsserver его адрес. В его логах ошибок нет. Сами сервера практически одинаковые. Только ядро разное. На проблемном 3.17.8 с патчами imq. На втором 3.19.0-49. Но проблема не в этом, так как ошибки начали сыпаться наверное не больше месяца назад. Ядро же стоит уже месяца 2 или больше. Посмотрел вывод sysctl на обоих, серьезной разницы нет.

as_lan ★★
() автор топика
Последнее исправление: as_lan (всего исправлений: 3)
Ответ на: комментарий от as_lan

гм. а не слишком ли медленно резолвятся имена ? Может клиент по таймауту уже отвалился и ответ некому принять ? Для проверки я бы собрал трафик на dev lo по 2-м фильтрам - 53 порт udp и icmp

vel ★★★★★
()
Ответ на: комментарий от vel

Мысль. Завтра проверю. Только по какой причине может быть медленный резолв? Интернет не может быть, ведь другой сервер резолвит нормально. А интернет он получает с этого сервера (выступает шлюзом). Днс сервера пробовал другие (и яндекс и гугл). Версии бинда одинаковые. Конфиги тоже (за исключением секций master/slave)

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

Клиент с адресом 127.0.0.1 - это какой-то процесс. Есть подозрение, что он закрывает сокет быстрее, чем приходит ответ.

А в сквиде, про который ты говорил как сконфигурирован резолвинг - сколько dns-серверов указано в dns_nameservers? Если у тебя больше одного сервера указано, то возможно один из них присылает ответ чуть раньше.

vel ★★★★★
()
Ответ на: комментарий от vel

1. Ну в логах видны же адреса обычных устройств в сети. Не только 127.0.0.1 фигурирует с ошибкой. Просто он чаще так как веб и https трафик завернут на сквид.
2. Там только одна строка. dns-серверов 127.0.0.1

as_lan ★★
() автор топика
Ответ на: комментарий от hotpil

Если напишут БАЙНД то большинство местной аудитории просто пройдет мимо этой темы. Существует большое кол-во терминов прижившихся исторически. Например также роут а не рут.

anc ★★★★★
()
Ответ на: комментарий от as_lan

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

C перезагрузкой сложнее. Машина рабочая. Надо ночью остаться либо рано утром попробовать.
И зачем вы про IMQ так =) Вполне себе нормальный патч. Сколько лет у меня работает что дома, что на работе.

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Не уверен. Но возможно нашел причину. Не так давно настроил сквид на прозрачное проксирование https. И вроде даже все работало. 100-150 компов спокойно ходили на свои джимейлы и прочие https сайты. Устав сегодня искать причину (по tcpdump тоже ничего странного не увидел) решил поотключать все службы на машрутизаторе. Удалил правила редиректа 80 и 443 портов. Сделал conntract -F. И вот уже полчаса как ни одной ошибки. Конечно это еще не 100%, ведь полчаса чистых логов не показатель. Но что-то мне кажется что с вероятностью 80% в этом дело. Сейчас вернул редирект только по 80 порту и так же все без ошибок. В фоне запустил сборку squid с опцией disable-internal-dns. Быть может это поможет.

as_lan ★★
() автор топика
Ответ на: комментарий от blind_oracle

До обеда все было прекрасно. Без ошибок. Но сейчас опять повалили.

as_lan ★★
() автор топика
Ответ на: комментарий от blind_oracle

Копаю дальше. А дальше еще более странное =)

(127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.094 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.259 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.087 ms
ping: sendmsg: Invalid argument
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.092 ms
ping: sendmsg: Invalid argument
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.070 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.287 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.082 ms
64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=0.104 ms
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
64 bytes from 127.0.0.1: icmp_seq=14 ttl=64 time=0.093 ms
64 bytes from 127.0.0.1: icmp_seq=15 ttl=64 time=0.090 ms
64 bytes from 127.0.0.1: icmp_seq=16 ttl=64 time=0.089 ms


Тоже самое если пинговать интерфейс 192.168.60.1.

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

Ну, я изначально говорил тебе что проблема в сетевой части. Показывай iptables, ip route/rule, что нестандартного в sysctl и так далее - явно чего-то наоптимизировал чтобы так сломать систему :)

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

1. Ядро не причем.Сейчас перезагрузился в стандартное ядро. Ошибки опять пошли. Мало того. Сделал бекап и развернул на другой машине. Все равно ошибки.
2. iptables

iptables-save
# Generated by iptables-save v1.4.21 on Fri Mar  4 08:58:35 2016
*nat
:PREROUTING ACCEPT [2768438:328126981]
:INPUT ACCEPT [1687347:103327334]
:OUTPUT ACCEPT [243167:16461028]
:POSTROUTING ACCEPT [238497:15788245]
-A PREROUTING -s 192.168.60.111/32 -j RETURN
-A PREROUTING -s 192.168.60.6/32 -j RETURN
-A PREROUTING -s 192.168.48.0/20 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.60.1:53
-A PREROUTING -s 192.168.48.0/20 ! -d 192.168.48.0/20 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.60.1:3129
-A PREROUTING -s 192.168.48.0/20 ! -d 192.168.48.0/20 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.60.1:3128
-A PREROUTING -d xxx.xxx.xxx.xxx/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.60.30:3389
-A PREROUTING -d xxx.xxx.xxx.xxx/32 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.8.239:21
-A PREROUTING -d xxx.xxx.xxx.xxx/32 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.8.239:21
-A POSTROUTING -s 192.168.48.0/20 -j MASQUERADE
-A POSTROUTING -d 192.168.60.30/32 -p tcp -m tcp --dport 3389 -j SNAT --to-source xxx.xxx.xxx.xxx
COMMIT
# Completed on Fri Mar  4 08:58:35 2016
# Generated by iptables-save v1.4.21 on Fri Mar  4 08:58:35 2016
*mangle
:PREROUTING ACCEPT [46006272:42571061949]
:INPUT ACCEPT [16330784:20424667175]
:FORWARD ACCEPT [29662571:22145201712]
:OUTPUT ACCEPT [15618183:20438247972]
:POSTROUTING ACCEPT [44754167:42384130771]
COMMIT
# Completed on Fri Mar  4 08:58:35 2016
# Generated by iptables-save v1.4.21 on Fri Mar  4 08:58:35 2016
*filter
:INPUT DROP [9191:553847]
:FORWARD ACCEPT [472673:175888108]
:OUTPUT ACCEPT [15557991:20413338746]
-A INPUT -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 7777 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 7777 -j ACCEPT
-A INPUT -s 192.168.48.0/20 -j ACCEPT
-A INPUT -s 192.168.2.0/24 -j ACCEPT
-A INPUT -s 192.168.25.0/24  -j ACCEPT
COMMIT
# Completed on Fri Mar  4 08:58:35 2016

3. ip route
ip route
default via 193.33.241.197 dev eth2
10.20.30.0/24 dev tun0  proto kernel  scope link  src 10.20.30.1
109.70.184.144/28 dev eth1  proto kernel  scope link  src xxx.xxx.xxx.xxx
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.1
192.168.8.0/24 dev eth0  proto kernel  scope link  src 192.168.8.1
192.168.15.0/24 dev eth0  proto kernel  scope link  src 192.168.15.1
192.168.25.0/24 dev eth0  proto kernel  scope link  src 192.168.25.1
192.168.48.0/20 dev eth0  proto kernel  scope link  src 192.168.60.1
193.33.241.196/30 dev eth2  proto kernel  scope link  src xxx.xxx.xxx.xxx

4. ip rule
0:      from all lookup local
32762:  from xxx.xxx.xxx.xxx lookup 20 (внешний ip 1)
32763:  from xxx.xxx.xxx.xxx lookup 10 (внешний ip 2)
32764:  from all to 77.88.8.1 lookup 20
32765:  from all to 77.88.8.8 lookup 10
32766:  from all lookup main
32767:  from all lookup default

5. sysctl
net.ipv4.ip_forward=1
net.core.rmem_default = 212992
net.core.wmem_default = 212992
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.conf.all.send_redirects = 1

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

as_lan ★★
() автор топика
Ответ на: комментарий от as_lan

-A PREROUTING -s 192.168.60.111/32 -j RETURN
-A PREROUTING -s 192.168.60.6/32 -j RETURN

Это зачем?

-A POSTROUTING -d 192.168.60.30/32 -p tcp -m tcp --dport 3389 -j SNAT --to-source xxx.xxx.xxx.xxx

Тут странно, в начале наверное должно быть -s 192.168...

У тебя случаем какого-нибудь IPSECа нету? ip xfrm policy должен быть пустой.

Плюс попробуй «ping -I lo 127.0.0.1» и посмотри будут ли ашыпки.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

1. Это нужно, чтоб iptables дальше не пускал по правилам трафик с этих адресов. А дальше видно, что 53 и 80 порты заворачиваются на сам сервер (bind и squid соответственно)
2. Это правило скорее всего по ошибке осталось. Первое давно удалил, а это забыл.
3. ipsec не стоит
4. Проблема решилась. По крайней мере 3-4 дня уже нет этих ошибок. настроил сеть по новой, но вот с горяча очистил весь конфиг interface и настроил с нуля. Поэтому что было проблемой сейчас не могу сказать. Правда есть 2х недельный бекап. На досуге вытащу оттуда старый конфиг и буду сверять и искать причину.

В этом конфиге через up ip route/rule добавлялись некоторые правила, которые сейчас в принципе не нужны. Возможно в этом была проблема. Но тогда почему проблема появлялась случайным образом. Ночью например вообще в логах ничего не было. Днем могли бы часами логи чистые, а потом резко сыпаться ошибки.

as_lan ★★
() автор топика
Последнее исправление: as_lan (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.