LINUX.ORG.RU
решено ФорумAdmin

Чудеса с DNS

 , ,


1

3

Есть один шлюз на Debian 7.8. Ничего примечательного - держит l2tp до провайдера, openvpn до впски, dnsmasq раздаёт адреса по dhcp и кэширует dns.

С недавних пор у системы начал отваливаться dns. Отваливается следующим образом - в один прекрасный момент любая попытка разрешить имя проваливается. dnsmasq, nslookup, dig - не работает ничего. Сервера, естественно, разные. При этом и запрос и ответ видны в tcpdump, а машины в сети могут спокойно работать напрямую с теми же самыми dns-серверами, которые не работают на шлюзе.

В логах абсолютно ничего необычного. Единственное но - сразу перед падением были кратковременные проблемы с интернетом (это точно было у провайдера - инет отваливался частично). Проблема проявляется далеко не сразу - с последнего ребута (по той же причине) прошло 10 дней.

От напасти не помогает перезапуск впнов, сетевых интерфейсов, и сети вообще. В общем-то, единственное рабочее решение - перезапуск всей машины целиком.

Вопрос - что это может быть, и как это лечится?

Не использовать провайдерский dns. Не использовать pdnsd (если вдруг ты его используешь), у dnsmasq лично для себя я определил оптимальный cachesize, равный 756. Можешь использовать google dns, или настроить dnscrypt, при этом не забудь сделать исключения и указать google/yandex dns для ntp и провайдерский для l2tp.

Алсо глупый вопрос, но интернет во время того, когда отваливается dns хотя-бы есть?
Возможно у тебя проблемы с l2tp сессией, ну и конечно же провадерский dns, если ты им пользуешься, наверняка в это время отваливаются. Есть еще такой небольшой трюк, когда ты указываешь второй или третий ip aдрес l2tp сервера провайдера, но все-таки я бы порекомендовал тебе избавиться от этого провайдера ну и все-таки по причине того, что ip aдреса l2tp сервера могут измениться, все-таки лучше ресолвить их через dns провайдера в «локальной сети» (потому-что не трудно догадаться о каком провайдере идет речь).

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

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

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

dig @10.7.0.1 google.com
nslookup google.com 8.8.8.8
nslookup google.com 85.21.192.5
При этом если в момент выполнения любой из команд слушать нужный интерфейс tcpdump'ом, то и запрос и ответ прекрасно видны.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Есть некоторые особенности.

т.е. на шлюзе всё это вернёт таймаут, тогда как те же самые команды на любой другой машине в сети выдадут корректный результат.

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

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

На сервере не работает вообще ничего, dnsmasq не отвечает на запросы даже для локальной зоны. Правила iptables проверял, пробовал вообще отключать фильтрацию - толку от этого тоже 0.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Правила iptables проверял, пробовал вообще отключать фильтрацию - толку от этого тоже 0.

Ты делал flush? И даже после этого ничего? Да сервер не контейнер случайно?

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

Я делал iptables-restore и временно включал -P INPUT ACCEPT (по умолчанию политика DROP). Сервер - отдельная машина.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Ну тогда неудивительно.
А, лучше дай «iptables -L» или сохрани правила, сделай flush и поработай над правилами. Не забудь про icmp и разрешить и INPUT/OUTPUT на lo.

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

Так а смысл, если iptables-restore по умолчанию делает flush таблицам, которые он модифицирует? У меня это mangle и nat.

Правила, очевидно, корректные, потому что после перезапуска применяются они же, и всё работает. ICMP и lo разрешены и так.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Присоединяюсь. Все-таки проверь iptables -F; iptables -t nat -F; iptables -t mangle -F. Слишком уж сильно похоже на него, пакеты прилетают но до приложения не доходят и опять-таки, через цепочку forward проходят а вот на input нет.

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

Вот выдержка из filter - всё, что относится к INPUT.

Основной dns имеет адрес 10.7.0.1, который доступен через tun0 (там 10.7.0.0/24). Третье правило в списке - принимать всё, что приходит из tun0. Всё остальное - это ppp0, там соединения разрешаются через state. OUTPUT не фильтруется вообще. Этот же конфиг грузится при старте системы, он же был активен и перезаписывался в момент проявления бага.

# Generated by iptables-save v1.4.14 on Tue Jan 26 17:56:30 2016
*filter
:INPUT DROP [23099:2303648]
:FORWARD ACCEPT [21382873:25305697757]
:OUTPUT ACCEPT [18365594:25526106641]
:INCOMING - [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i eth1 -j INCOMING
-A INPUT -i ppp0 -j INCOMING
-A INPUT -p icmp -j ACCEPT
-A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT
koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Кроме filter есть еще другие таблицы, вы все-таки попробуйте очистить в момент бага. Я серьезно. Проблемы-то три команды выполнить.
Кстати обратил внимание, ничего про логи не сказано, в логах случайно ничего странного не появляется в момент бага? И другие соединения, например ssh на том же интерфейсе нормально работают?

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

Я знаю. Таблица mangle пустая, в nat - маскарадинг и проброс портов. Попробую, конечно, но с учётом того, что iptables-restore делает flush по умолчанию и дальше грузит рабочие правила, вероятность того, что это поможет кажется мне сомнительной. Но даже если это поможет, как лечить причину?

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Смотреть что там было прописано когда не работало.

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

ЗЫ Хотя да, еще раз внимательно перечитал то что выше, весьма сомнительно что поможет, но я с горя бы попробовал. Ну и все то что написал выше, что в логах, что с работой других соединений на том же интерфейсе.

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

В логах ничего необычного не видно. Работает всё кроме dns - openvpn, ssh подключается, l2tp не падает. Более того, dnsmasq продолжает нормально работать dhcp сервером, тогда как dns у него работать перестаёт.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Стоп, ты пишешь «У меня это mangle и nat.» и потом «Таблица mangle пустая» - что-то не сходиться в показаниях.

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

Думаю одно, пишу другое. Mangle пустая, filter и nat - используются.

# Generated by iptables-save v1.4.14 on Tue Jan 26 18:07:51 2016
*mangle
:PREROUTING ACCEPT [3181135:2680571054]
:INPUT ACCEPT [1044200:116240428]
:FORWARD ACCEPT [2136933:2564330386]
:OUTPUT ACCEPT [1840332:2588983890]
:POSTROUTING ACCEPT [3977265:5153314276]
COMMIT
# Completed on Tue Jan 26 18:07:51 2016
koi-sama
() автор топика

покрути на предмет увеличения сессий в nf_conntrack(вроде так) в sysctl
возможно косяк в fail2ban

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

Цепочка fail2ban в iptables была пустая, а больше оно нигде и не должно влиять. Вряд ли conntrack, но попробую.

net.netfilter.nf_conntrack_max = 65536
conntrack v1.2.1 (conntrack-tools): 10419 flow entries have been shown.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

А покажи просто dig, скажем lor'а без указки dns сервера выполненный на сервере с dnsmasq (на нем ведь у тебя проблемы?). Просто есть подозрение, что у тебя dnsmasq работает, а вот ns сервер на машине с которой у тебя проблемы указан нерабочий/никак не связанный с dnsmasq, который же и крутится на этой машине. Либо, там стоит провайдерский и когда интернет отваливается, тебе отдается некорректный/не рабочий ns сервер. Проще говоря у тебя есть два варианта либо использоваться свой же dns на сервере с dnsmasq либо к примеру гугловский (там dns у тебя будет работать даже если будут проблемы с твоим же dnsmasq). Да заметь, что Dnsmasq это dns forwarder, а не dns сервер. По умолчанию dnsmasq использует твой dns из resolv.conf, но может быть настроено, что dnsmasq использовал совершено другие nameservers, тем более если учесть лимит nameserver'ов в resolv.conf.
P.S.: Не знаю насколько читабельно выглядит, то что я написал.

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

По умолчанию там провайдерский сервер, который так же отлично работает через forward.

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

koi-sama
() автор топика
25 марта 2016 г.

Приключения продолжаются.

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

По симптомам, кстати, оказалось похоже на работу rp_filter с маршрутизацией с помощью iptables (fwmark + другой шлюз + rp_filter = отбрасывание пакетов). Но rp_filter я полностью отключал и всё остальное тоже сбрасывал.

koi-sama
() автор топика

Если в tcpdump'е виден ответ, пробуйте отследить его прохождение по таблицам/цепочкам iptables. Либо через -j TRACE, либо через логгирующие правила во всех встроенных цепочках. Для удобства отслеживания шлите DNS-запросы не к DNS провадера, а к какому-нибудь малоизвестному домену, чтобы не было других пакетов с этим src-адресом.

mky ★★★★★
()
18 сентября 2016 г.

Не прошло и года, ребуты стали происходить чаще, а я сподобился собрать наконец новое ядро. Помогло - уже больше недели всё работает нормально.

Что именно это было - я так и не понял.

koi-sama
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.