Что-то странное произошло с сетью

[Алексей Витальевич Коротков]

Приветствую.

Какая-то непонятная бурда с сетью.

Произошло в точности не заметил когда, но в последние дни. Может, вчера.

Вот так примерно работают пинги (вложение ping.txt).

А вот так попытка обновить пакетную базу (вложение apt.txt).

В браузере веб-страницы открываются, но не все сразу, некоторые только
со второй попытки.

Debian stable с бэкпортами.

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

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

Куда копать?

[Victor Wagner]

В Fri, 19 Nov 2021 17:21:42 +0400
Алексей Витальевич Коротков <a.v.ko...@gmail.com> пишет:

> Приветствую.
>
> Какая-то непонятная бурда с сетью.
>
> Произошло в точности не заметил когда, но в последние дни. Может,
> вчера.
>
> Вот так примерно работают пинги (вложение ping.txt).
>
> А вот так попытка обновить пакетную базу (вложение apt.txt).
>
> В браузере веб-страницы открываются, но не все сразу, некоторые только
> со второй попытки.

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

[Алексей Витальевич Коротков]

On Fri, 19 Nov 2021 17:04:43 +0300
Victor Wagner wrote:

VW> Такое впечатление что почему-то машина разучилась работать по
VW> протколоу IPv4, и хочет до всего достукиваться только по IPv6.

Где/что смотреть тогда?

[Andrey Jr. Melnikov]

В /etc/resolv.conf для начала.

[Алексей Витальевич Коротков]

On Fri, 19 Nov 2021 19:10:36 +0300
Andrey Jr. Melnikov wrote:

AJM> В /etc/resolv.conf для начала.

$ cat /etc/resolv.conf
nameserver 192.168.1.1
search desktop

Тот же nameserver на домашнем сервере (это адрес роутера), и там всё
работает без проблем.

[Max Nikulin]

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

/etc/gai.conf
# For sites which prefer IPv4 connections change the last line to
#
# precedence ::ffff:0:0/96 100

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 12:36:45 +0700
Max Nikulin wrote:

MN> Можно вот здесь подкрутить, но проблема где-то в другом месте. По
MN> крайней мере, позволит работать, пока не станет понятно, что именно
MN> сломалось.
MN>
MN> /etc/gai.conf
MN> # For sites which prefer IPv4 connections change the last line to
MN> #
MN> # precedence ::ffff:0:0/96 100

У меня отключён IPv6 (через GRUB).

И при обращении по IP, кстати, проблема та же. Так что совет выше про
настройки /etc/resolv.conf в моей проблеме неактуален.

$ ping 192.168.1.1
ping: socket: Семейство адресов не поддерживается протоколом
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.324 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.417 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.309 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.309/0.350/0.417/0.047 ms

[Max Nikulin]

On 20/11/2021 14:19, Алексей Витальевич Коротков wrote:
> У меня отключён IPv6 (через GRUB).

Подозрение, что где-то что-то отключили лишнего. Может, через sysctl

> И при обращении по IP, кстати, проблема та же. Так что совет выше про
> настройки /etc/resolv.conf в моей проблеме неактуален.
>
> $ ping 192.168.1.1
> ping: socket: Семейство адресов не поддерживается протоколом

На английском проще будет сопоставить текст с кодом ошибки

LANG=en_US.UTF-8 ping -с 1 192.168.1.1

А еще лучше то же самое из под strace (возможно, с -s64) чтобы видно
было системный вызов и с какими аргументами возникает ошибка.

Не уверен, что с debug или verbose ping расскажет про ошибку больше. Еще
можно попробовать другие команды, которые можно сделать более
разговорчивыми, например curl -v -I 192.168.1.1

[Tull Jethro]

Чисто предположение: а то, что является роутером правильно
адреса/настройки через DHCP отдало?

сб, 20 нояб. 2021 г. в 12:42, Алексей Витальевич Коротков
<a.v.ko...@gmail.com>:
>
> On Sat, 20 Nov 2021 15:32:37 +0700
> Max Nikulin wrote:
>
> MN> Подозрение, что где-то что-то отключили лишнего.
>
> Вряд ли. Ничего не трогал из настроек давно, и вплоть до вчерашнего дня
> всё работало идеально.
>
> MN> На английском проще будет сопоставить текст с кодом ошибки
> MN>
> MN> LANG=en_US.UTF-8 ping -с 1 192.168.1.1
>
> Вложил ping.txt от команды
> LANG=en_US.UTF-8 ping -c 1 192.168.1.1 > ping.txt 2>&1
>
> MN> А еще лучше то же самое из под strace (возможно, с -s64) чтобы
> MN> видно было системный вызов и с какими аргументами возникает ошибка.
>
> Вложил strace.txt от команды
> LANG=en_US.UTF-8 strace -s64 ping -c 1 192.168.1.1 > strace.txt 2>&1
>
> MN> Не уверен, что с debug или verbose ping расскажет про ошибку
> MN> больше. Еще можно попробовать другие команды, которые можно сделать
> MN> более разговорчивыми, например curl -v -I 192.168.1.1
>
> Вложил curl.txt от команды
> curl -v -I 192.168.1.1 > curl.txt 2>&1
>
> getmail вот такую ошибку выдаёт
> socket error ([Errno 97] Address family not supported by protocol)
> но со второго раза отрабатывает.
>
> ПС. Из вчерашнего обновления приехало iproute2:amd64 (5.14.0-1~bpo11+1,
> 5.15.0-1~bpo11+1).

[Max Nikulin]

On 20/11/2021 16:39, Алексей Витальевич Коротков wrote:
> У меня отключён IPv6 (через GRUB).

> socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = -1 EAFNOSUPPORT (Address family not supported by protocol)

Кажется, ping не знает, что IPv6 отключен в grub, и пытается его
использовать. Меня правда немного настораживает, что в strace.txt я не
вижу следов успешно принятого пакета.

curl, похоже, увидев IPv4 адрес, не пытался что-то делать с IPv6 и
отрабатывает без ошибок.

Можно еще почитать
curl -v -I
http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease
ну и из-под strace уже без -v

Нет ли тут какого-нибудь proxy (например, для apt)?

ip address list
ip link list
ничего подозрительного не показывают?

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 13:06:58 +0300
Tull Jethro wrote:

TJ> Чисто предположение: а то, что является роутером правильно
TJ> адреса/настройки через DHCP отдало?

Я не использую DHCP, адреса постоянные.

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

Кстати, письма не только получать, но и отправлять получается тоже
только со второй попытки.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 17:04:44 +0700
Max Nikulin wrote:

MN> Кажется, ping не знает, что IPv6 отключен в grub

До вчерашнего дня знал. И настройки я не менял никакие.

MN> Можно еще почитать
MN> curl -v -I
MN> http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease
MN> ну и из-под strace уже без -v

$ curl -v -I
http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease

С первой попытки не соединяется (curle.txt).

Со второй проходит (curlr.txt).

Со strace (curls.txt).

MN> Нет ли тут какого-нибудь proxy (например, для apt)?

Экспериментировал с proxy, но это было ещё в прошлом году, сейчас нет
его. Есть только переменная окружения no_proxy, но она не влияет, так
как proxy нет.

MN> ip address list
MN> ip link list
MN> ничего подозрительного не показывают?

Вроде, нет.

[Max Nikulin]

On 20/11/2021 18:36, Алексей Витальевич Коротков wrote:
> * Could not resolve host: cloud.r-project.org
> * Closing connection 0
> curl: (6) Could not resolve host: cloud.r-project.org

У меня провайдер недавно чудил. Отдавал 2 DNS сервера, второй работал
нормально, а первый с заметной долей с первого раза не мог отдать адрес.
Если адрес уже был в кэше, то все работало. Может совпадение, но потом
видел в новостях, про учения по изоляции рунета примерно в эти же дни.

Попробуйте по нескольку раз команды с DNS серверами провайдера и
*разными* SOME_HOST, которые с малой вероятностью спрашивают другие
пользователи (например, из списка зеркал debian)

time dig @YOUR_DNS +tries=1 +retry=0 -t A SOME_HOST

Примерно такой командой я собирал статистику:
time dig @YOUR_DNS +short +noanswer +tries=1 +retry=0 -t A SOME_HOST ;
echo "Exit code $?"

Подозрение, что

ping: socket: Семейство адресов не поддерживается протоколом

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

[Oleg Chernov]

Здравствуйте,

On 20-11-2021 11:39, Алексей Витальевич Коротков wrote:
> Вложил strace.txt от команды
> LANG=en_US.UTF-8 strace -s64 ping -c 1 192.168.1.1 > strace.txt 2>&1
>

socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission
denied)

вот эта строчка из Вашего strace.txt наводит на мысль о SELinux (или
файерволле)



--
Best regards,
Oleg A. Chernov
OAC4-RIPE
WildPark ISP, Nikolaev, Ukraine
+380512 709555

[Dmitry Semyonov]

On Sat, 20 Nov 2021 at 15:34, Oleg Chernov wrote:

> socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission
> denied)
>
> вот эта строчка из Вашего strace.txt наводит на мысль о SELinux (или
> файерволле)

Или о том, что strace и "sudo strace -u $USER" ведут себя по-разному.

--
...Bye..Dmitry.

[Dmitry Semyonov]

On Sat, 20 Nov 2021 at 10:20, Алексей Витальевич Коротков wrote:

> У меня отключён IPv6 (через GRUB).

Точно?

cat /proc/cmdline
grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

> И при обращении по IP, кстати, проблема та же.

А так?
ping -4 ...

--
...Bye..Dmitry.

[Dmitry Semyonov]

On Sat, 20 Nov 2021 at 10:20, Алексей Витальевич Коротков wrote:

> У меня отключён IPv6 (через GRUB).

Точно?

cat /proc/cmdline
grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

ip a | grep inet6

> И при обращении по IP, кстати, проблема та же.

А так?

ping -4 192.168.1.1

--
...Bye..Dmitry.

[Max Nikulin]

Я это сразу не заметил, но это подтверждение моей догадки, что ping.txt
делался в одних условиях (ругнулся, но пакет отправил), а

LANG=en_US.UTF-8 strace -s64 ping -c 1 192.168.1.1 > strace.txt 2>&1

в других - ping не смог отправить пакет, потому что не дали открыть ни
один сокет (ошибку он показал только для последней попытки, которая была
по IPv6). У меня локально похожая команда отработала без проблем,
поэтому начал подозревать, что по ошибке ее выполнили, скажем, из qemu,
которому не дали серевой интерфейс, поэтому ему не хватает прав для icmp.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 14:28:15 +0200
Oleg Chernov wrote:

Добрый вечер,

OC> вот эта строчка из Вашего strace.txt наводит на мысль о SELinux
OC> (или файерволле)

SELinux не используется, файерволл не включен.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 19:15:58 +0700
Max Nikulin wrote:

MN> У меня провайдер недавно чудил. Отдавал 2 DNS сервера, второй
MN> работал нормально, а первый с заметной долей с первого раза не мог
MN> отдать адрес. Если адрес уже был в кэше, то все работало. Может
MN> совпадение, но потом видел в новостях, про учения по изоляции
MN> рунета примерно в эти же дни.

Дело в том, что второй компьютер с таким же Дебьяном работает без такой
проблемы. Через тот же роутер.

MN> Попробуйте по нескольку раз команды с DNS серверами провайдера

У меня DNS от Яндекса и Гугла.

MN> time dig @YOUR_DNS +tries=1 +retry=0 -t A SOME_HOST
MN>
MN> Примерно такой командой я собирал статистику:
MN> time dig @YOUR_DNS +short +noanswer +tries=1 +retry=0 -t A
MN> SOME_HOST ; echo "Exit code $?"

Вот, например:
# time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
security.debian.org 151.101.66.132
151.101.194.132
151.101.2.132
151.101.130.132

real 0m0,209s
user 0m0,019s
sys 0m0,011s
# echo "Exit code $?"
Exit code 0

# time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
cloud.r-project.org ;; Warning: Client COOKIE mismatch
d3caqzu56oq2n9.cloudfront.net.
13.33.246.115
13.33.246.110
13.33.246.114
13.33.246.67

real 0m0,228s
user 0m0,010s
sys 0m0,016s
# echo "Exit code $?"
Exit code 0

MN> Подозрение, что
MN> ping: socket: Семейство адресов не поддерживается протоколом
MN> это отдельная проблема, а на соседнем сервере проблема не так
MN> заметна, потому что там зоопарк репозиториев меньше.

Она появилась одновременно со всем остальным. Т.е. все сетевые
программы стали работать криво одновременно.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 16:42:56 +0300
Dmitry Semyonov wrote:

DS> cat /proc/cmdline
DS> grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.5.0-0.bpo.2-amd64 root=UUID=8a87c5eb-a97e-4f53-8f42-05e8d2700c5e ro ipv6.disable=1 quiet
# grep . /proc/sys/net/ipv6/conf/*/disable_ipv6
grep: /proc/sys/net/ipv6/conf/*/disable_ipv6: Нет такого файла или каталога

DS> А так?
DS> ping -4 ...

$ ping -4 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.326 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.356 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.359 ms

^C
--- 192.168.1.1 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.292/0.333/0.359/0.027 ms

Похоже, что угадали. Но тогда вопрос: почему до вчерашнего для всё было
отлично? Обновление iproute2 повлияло?

[Dmitry Semyonov]

On Sat, 20 Nov 2021 at 18:28, Алексей Витальевич Коротков wrote:

> BOOT_IMAGE=/boot/vmlinuz-5.5.0-0.bpo.2-amd64

Что-то больно старое ядро... В stable и то новее, судя по
https://packages.debian.org/search?keywords=linux-image-amd64.


> почему до вчерашнего дня всё было отлично? Обновление iproute2 повлияло?

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

С другой стороны, разведение зоопарка из разных репозиториев пакетов -
не очень хорошая идея, если нет чёткого понимания зачем это делается,
и как они друг с другом уживаются. В Вашем случае, я бы посоветовал
перейти на чистый stable, удалив/переустановив всё, что сейчас
установлено не оттуда (apt list --installed | grep -v /stable). Не так
уж много времени прошло со времени последнего релиза, чтобы пытаться
бежать впереди паровоза.

--
...Bye..Dmitry.

[Maksim Dmitrichenko]

сб, 20 нояб. 2021 г. в 18:28, Алексей Витальевич Коротков <a.v.ko...@gmail.com>:

DS> А так?
DS> ping -4 ...

$ ping -4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.326 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.356 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.359 ms
^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.292/0.333/0.359/0.027 ms

Похоже, что угадали. Но тогда вопрос: почему до вчерашнего для всё было
отлично? Обновление iproute2 повлияло?

Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает ping пропобовать открывать сокет семейства протоколов IPv6, что у вас, судя по strace и происходит.

Но вызывать ping из-под strace категорически нельзя, потому что strace не дает запуститься ping с правами root (у него должен быть установлен бит SUID). И это хорошо видно в вашем выводе strace, когда у него не получается открыть socket семейства IPv4 (AF_INET)  для SOCK_DGRAM, PROTO_ICMP с ошибкой EPERM. Собственно у вас ping и лезет к созданию сокета IPv6 просто потому что у него обломалось создание сокета ICMPv4. 

Приложите вывод strace пинга из-под root'а.

ЗЫ: А может вы (или какая-то программа хулиганская) сбросила SUID-бит у ping?

--

With best regards
  Maksim Dmitrichenko

[Maksim Dmitrichenko]

сб, 20 нояб. 2021 г. в 20:55, Maksim Dmitrichenko <dmit...@gmail.com>:

ЗЫ: А может вы (или какая-то программа хулиганская) сбросила SUID-бит у ping?

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

У меня вот так:

$ /sbin/getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

[Eugene Berdnikov]

On Sat, Nov 20, 2021 at 01:39:38PM +0400, Алексей Витальевич Коротков wrote:
> Вложил ping.txt от команды
> LANG=en_US.UTF-8 ping -c 1 192.168.1.1 > ping.txt 2>&1

Вот это

capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0,
+inheritable=0}) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0,
+inheritable=0}) = 0
prctl(PR_SET_KEEPCAPS, 1) = 0
getuid() = 1000
setuid(1000) = 0
prctl(PR_SET_KEEPCAPS, 0) = 0
getuid() = 1000
...

socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission denied)

socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)

совершенно закономерно: видно, что "strace ping ..." запускается не от
рута, а под uid/gid=1000/1000), а в таком случае при запуске под strace
на применяются capabilities, соответственно capget не выдаёт, а capset
не ставят нужную CAP_NET_RAW, в результате не удаётся создать raw socket,
необходимый для пинга -- последний вызов socket() выдаёт EPERM.

Насколько я понимаю, ping без strace исправно работает под этим uid/gid,
хоть и ругается на ipv6.

Интересно, давно ли перезагружался компьютер. :)

И поскольку говорилось о наличии рядом другого компьютера с рабочей
системой, предлагаю сравнить diff-ом выдачу "sysctl -a" с этих компов.
Разумеется, отсекая всё что не относится к сети.
--
Eugene Berdnikov

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 20:38:01 +0300
Dmitry Semyonov wrote:

DS> Что-то больно старое ядро... В stable и то новее, судя по
DS> https://packages.debian.org/search?keywords=linux-image-amd64.

Да, это из бастера.

Это другая проблема. Не грузятся новые ядра.

Причём после обновления 10 -> 11 новое ядро загружалось, но потом
перестало. Сейчас уже трудно сказать, после чего именно. Просто
загрузка останавливается. Хорошо, что сохранилось старое.

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

Убрал из GRUB, сделал в /etc/sysctl.d/. Проблема исчезла старая, но
вылезла новая:

$ LANG=en_US.UTF-8 ping -c 1 debian.org
ping: connect: Cannot assign requested address

Тогда убрал вообще. Сейчас пинги все без проблем работают.

Но почему-то в браузере некоторые страницы грузятся всё равно только со
второго раза.

DS> С другой стороны, разведение зоопарка из разных репозиториев
DS> пакетов - не очень хорошая идея, если нет чёткого понимания зачем
DS> это делается, и как они друг с другом уживаются. В Вашем случае, я
DS> бы посоветовал перейти на чистый stable

У меня и так stable, только с бэкпортами. Остальное - стороннее ПО
(Хром, например). В офрепо из него нет почти ничего, а что есть, не
должно влиять на мою ситуацию.

Основной гипотезой у меня сейчас новый iproute2 + старое ядро. Потому
что до вчерашнего дня проблем с сетью не было вообще.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 20:55:25 +0300
Maksim Dmitrichenko wrote:

MD> Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает
MD> ping пропобовать открывать сокет семейства протоколов IPv6, что у
MD> вас, судя по strace и происходит.

Убрал ту строчку из груба. Сейчас с пингами всё нормально.

MD> ЗЫ: А может вы (или какая-то программа хулиганская) сбросила
MD> SUID-бит у ping?

Его нет нигде: ни на десктопе, ни на домашнем сервере, ни на VPS с
таким же Дебьяном.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 21:20:35 +0300
Eugene Berdnikov wrote:

EB> Интересно, давно ли перезагружался компьютер.

С час назад.

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

EB> И поскольку говорилось о наличии рядом другого компьютера с рабочей
EB> системой, предлагаю сравнить diff-ом выдачу "sysctl -a" с этих
EB> компов. Разумеется, отсекая всё что не относится к сети.

Гляну.

После убирания отключения IPv6 старые проблемы ушли, но есть новые.
getmail получает почту со второго раза, в перый раз он выдаёт

operation error (error resolving name pop.gmail.com during connect
([Errno -2] Name or service not known))

Пакетная база обновляется не со всех сторонних репо. С CRAN, например,
не работает.

[Maksim Dmitrichenko]

сб, 20 нояб. 2021 г. в 21:38, Алексей Витальевич Коротков <a.v.ko...@gmail.com>:

Основной гипотезой у меня сейчас новый iproute2 + старое ядро. Потому
что до вчерашнего дня проблем с сетью не было вообще.

Маловероятно вообще. Тем более, что команда ping к пакету iproute2 не имеет никакого отношения 

[Maksim Dmitrichenko]

сб, 20 нояб. 2021 г. в 21:38, Алексей Витальевич Коротков <a.v.ko...@gmail.com>:

On Sat, 20 Nov 2021 20:55:25 +0300
Maksim Dmitrichenko wrote:

MD> Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает
MD> ping пропобовать открывать сокет семейства протоколов IPv6, что у
MD> вас, судя по strace и происходит.

Убрал ту строчку из груба. Сейчас с пингами всё нормально.

Верните строчку и пришлите strace из-под root'а или из-под sudo, если вы хотите, чтобы вам помогли с диагностикой.

 

MD> ЗЫ: А может вы (или какая-то программа хулиганская) сбросила
MD> SUID-бит у ping?

Его нет нигде: ни на десктопе, ни на домашнем сервере, ни на VPS с
таким же Дебьяном.

Я второе письмо вдогонку послал с  разъяснением того, что ныне SUID-бит заменяют capability.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 21:59:39 +0300
Maksim Dmitrichenko wrote:

MD> Верните строчку и пришлите strace из-под root'а или из-под sudo,
MD> если вы хотите, чтобы вам помогли с диагностикой.

В текущем виде проблем с пингами нет. Есть с аптом и getmail, а также с
частью страниц в браузере. Работает только со второй попытки. Вероятно,
с другими сетевыми приложениями тоже возможна такая же ерунда, пока не
пробовал. Что именно стрейсить? Пинги, наверно, нет смысла.

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 22:01:49 +0300
Maksim Dmitrichenko wrote:

MD> Маловероятно вообще. Тем более, что команда ping к пакету iproute2
MD> не имеет никакого отношения

Вообще. Всё пинговалось, всё обновлялось, всё грузилось с первого раза.

Проблема не с пингами конкретно, а вообще сеть криво работает.

[Maksim Dmitrichenko]

сб, 20 нояб. 2021 г. в 22:31, Алексей Витальевич Коротков <a.v.ko...@gmail.com>:

On Sat, 20 Nov 2021 21:59:39 +0300
Maksim Dmitrichenko wrote:

MD> Верните строчку и пришлите strace из-под root'а или из-под sudo,
MD> если вы хотите, чтобы вам помогли с диагностикой.

В текущем виде проблем с пингами нет.

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

 

Есть с аптом и getmail, а также с
частью страниц в браузере. Работает только со второй попытки. Вероятно,
с другими сетевыми приложениями тоже возможна такая же ерунда, пока не
пробовал. Что именно стрейсить? Пинги, наверно, нет смысла.

Ну strace apt'а, например. Только нужен strace не когда оно работает, а когда оно не работает. А лучше всего оба. А то в случае с curl'ом вы приложили именно работающий strace.

Ну и параллельно, я бы сдампил на всякий случай трафик с помощью dumpcap, если таковой будет. Причем интересно не только сами попытки приконнектиться к нужному адресу, но всё, что этому предшествует - ARP, DNS и вот это всё.

[Алексей Витальевич Коротков]

В общем, пока вернул старую версию iproute2 и снова отключил IPv6.

Всё начало работать (то, что проверил: пинги, апт, гетмейл) как до
обновления.

Благодарю всех за помощь.

[Eugene Berdnikov]

On Sat, Nov 20, 2021 at 11:05:50PM +0400, Алексей Витальевич Коротков wrote:
> После убирания отключения IPv6 старые проблемы ушли, но есть новые.
> getmail получает почту со второго раза, в перый раз он выдаёт
>
> operation error (error resolving name pop.gmail.com during connect
> ([Errno -2] Name or service not known))

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

Почему так может происходить -- есть варианты, не вижу смысла их
вдаваться в их обсуждение. Проще и быстрее посмотреть дамп трафика,
как было здесь предложено, хотя бы на проблемном хосте.

Только я не знаю, где взять dumpcap... а tcpdump в Дебиане точно есть.
Запускать его под рутом, примерно так:

tcpdump -nlUv -i any -s0 port domain
--
Eugene Berdnikov

[Алексей Витальевич Коротков]

On Sat, 20 Nov 2021 23:20:12 +0300
Eugene Berdnikov wrote:

EB> tcpdump -nlUv -i any -s0 port domain

После возврата к состоянию до обновления всё заработало.

Если обнаружатся какие-то косяки снова, то попробую.

[Max Nikulin]

Я рад, что проблема решилась. Пара замечаний напоследок.

On 20/11/2021 22:25, Алексей Витальевич Коротков wrote:
> On Sat, 20 Nov 2021 19:15:58 +0700
> Max Nikulin wrote:
>
> MN> Попробуйте по нескольку раз команды с DNS серверами провайдера
>
> У меня DNS от Яндекса и Гугла.

Можно было сравнить с запросами к своему роутеру.

> Вот, например:
> # time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
> security.debian.org 151.101.66.132

Вы бы еще yandex.ru спросили у яндекса, я ведь просил

> MN> *разными* SOME_HOST, которые с малой вероятностью спрашивают
другие пользователи

> # time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
> cloud.r-project.org ;; Warning: Client COOKIE mismatch
> d3caqzu56oq2n9.cloudfront.net.

А вот на более экзотическом доменном имени заметно, что одно из
проявлений проблемы - DNS. С DNS cookie до сих пор не сталкивался, но
поиск говорит, что сервер можно сконфигурировать так, чтобы он реже
отвечал для неправильных cookie.

> * Could not resolve host: cloud.r-project.org
> * Closing connection 0
> curl: (6) Could not resolve host: cloud.r-project.org

и следом

> * Trying 13.33.246.110:80...
> * Connected to cloud.r-project.org (13.33.246.110) port 80 (#0)

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

> В текущем виде проблем с пингами нет. Есть с аптом и getmail, а также с

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

согласуется с проблемой с DNS

> Что-то странное произошло при разрешении «cloud.r-project.org:http» (-5 - С именем узла не связано ни одного адреса)
> Ошиб https://download.virtualbox.org/virtualbox/debian bullseye InRelease
> Что-то странное произошло при разрешении «download.virtualbox.org:https» (-5 - С именем узла не связано ни одного адреса)
> Ошиб http://dl.google.com/linux/chrome/deb stable InRelease
> Что-то странное произошло при разрешении «dl.google.com:http» (-5 - С именем узла не связано ни одного адреса)

тоже DNS. mirror.yandex.ru, который с заметной вероятностью закэширован,
там прошел гладко.

А почему новый iproute2 не подружился с DNS кинетики, провайдера,
яндекса или гугла, осталось непонятным.

[Алексей Витальевич Коротков]

On Sun, 21 Nov 2021 15:11:28 +0700
Max Nikulin wrote:

MN> Я рад, что проблема решилась.

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

Вот getmail сегодня снова выдал:

socket error ([Errno 99] Cannot assign requested address)

Но со второго раза сработало.

На домашнем сервере на ночь запустил загрузку видео через yt-dlp. Утром
проверил, скачалось 80.6% и ошибка

error [Errno -2] Name or service not known>

В общем, работает с косяками.

MN> А почему новый iproute2 не подружился с DNS кинетики, провайдера,
MN> яндекса или гугла, осталось непонятным.

У меня подозрение, что он не дружен с моим старым ядром от бастера.

На домашнем сервере именно таких проблем, как на десктопе, не
проявлялось. А там новая версия iproute2 и последнее ядро из бэкпортов.
Надо будет ещё на своём VPS поэкспериментировать, он вообще в
дата-центре в США. DNS, соответственно, там совсем другие.

На компьютерах у меня в /etc/resolv.conf стоит
nameserver 192.168.1.1

А на Кинетике (который 192.168.1.1) серверы DNS такие
77.88.8.8
77.88.8.1
77.88.8.88
77.88.8.2
77.88.8.7
77.88.8.3
8.8.8.8
192.168.8.1
(именно в таком порядке).

192.168.8.1 это адрес модема.

[Eugene Berdnikov]

On Sun, Nov 21, 2021 at 02:45:35PM +0400, Алексей Витальевич Коротков wrote:
> На компьютерах у меня в /etc/resolv.conf стоит
> nameserver 192.168.1.1
>
> А на Кинетике (который 192.168.1.1) серверы DNS такие
> 77.88.8.8
> 77.88.8.1
> 77.88.8.88
> 77.88.8.2
> 77.88.8.7
> 77.88.8.3
> 8.8.8.8
> 192.168.8.1
> (именно в таком порядке).
>
> 192.168.8.1 это адрес модема.

В такой толпе серверов неудивительно распостранение глюков и багов,
особенно во время пандемии... :) Без дампа трафика гадать тут можно
бесконечно, подозревая и косяки Кинетика (в котором может быть зашит
dnsmasq прошлого века), и модем, а в качестве безумной фантастики
ещё iproute2 и версию ядра.
--
Eugene Berdnikov

[Алексей Витальевич Коротков]

On Sun, 21 Nov 2021 16:44:34 +0300
Eugene Berdnikov wrote:

EB> В такой толпе серверов неудивительно распостранение глюков и багов

Первые 6 появляются после включения функции Яндекс DNS в Кинетике.

И это годами стабильно работало без глюков. До позавчерашнего дня,
когда пришло последнее обновление.

[Алексей Витальевич Коротков]

Update.

Отключил на Кинетике Яндекс DNS, и всё стало нормально работать.

Видимо, с этими серверами в последние дни что-то неладно.