Чудеса с DNS

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

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

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

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

dig @10.7.0.1 google.com
nslookup google.com 8.8.8.8
nslookup google.com 85.21.192.5

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

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

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

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

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

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

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

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

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

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

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

Вот выдержка из 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

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

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

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

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

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

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

Думаю одно, пишу другое. 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

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

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

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

А покажи просто 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.: Не знаю насколько читабельно выглядит, то что я написал.

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

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

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

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

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

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

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

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