URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID15
Нить номер: 4953
[ Назад ]

Исходное сообщение
"Блокировка lo в фаерволле ломает запуск DE в Debian 12"

Отправлено ulinna , 26-Апр-25 18:28 
Здравствуйте!
Столкнулась с такой проблемой: в новых версиях Debian (например, Debian 12.5, 12.10), если в фаерволле заблокировать интерфейс lo (loopback), графическая среда (DE) не загружается — после входа остается только черный экран.

Что интересно: дистрибутивы на базе Debian 12, такие как BunsenLabs и SpiralLinux, работают без проблем даже при заблокированном lo. Графическая сессия загружается и работает стабильно.

Пробовала отключить автозагрузку lightdm и стартовать графическую сессию вручную через startx — результат тот же: черный экран.
Также пробовала запускать разные окружения — XFCE и KDE — в обоих случаях поведение одинаковое, значит, проблема не зависит от самой DE.

Хотела бы уточнить:
    Какие именно компоненты в чистом Debian теперь требуют обязательного доступа к lo?
    Почему производные дистрибутивы не страдают от этой проблемы?

Буду благодарна за помощь и любые советы!


Содержание

Сообщения в этом обсуждении
"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено Ия , 27-Апр-25 23:33 
Гоголь:
.. Русь, куда ж несешься ты? дай ответ. Не дает ответа. Чудным звоном заливается колокольчик; гремит и становится ветром разорванный в куски воздух; летит мимо все, что ни есть на земли, и, косясь, постораниваются и дают ей дорогу другие народы и государства.

Ктулху:
О, сисястая и порочная! Заведи tcpdump и узрей, кто долбится в лоно твоё!


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено AS , 28-Апр-25 11:15 
> Гоголь: & много текста..

а разве tcpdump кажет бинари, которые ходят в сокет? он вроде тока srcIP & dstIP кажет..

ss или netstat c "-p"|grep 127\.0\.0\.1:

или iptstate возможно


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено ulinna , 28-Апр-25 16:06 
> Гоголь:
> .. Русь, куда ж несешься ты? дай ответ. Не дает ответа. Чудным
> звоном заливается колокольчик; гремит и становится ветром разорванный в куски воздух;
> летит мимо все, что ни есть на земли, и, косясь, постораниваются
> и дают ей дорогу другие народы и государства.
> Ктулху:
> О, сисястая и порочная! Заведи tcpdump и узрей, кто долбится в лоно
> твоё!

Спасибо за совет.  
Запустила в фоне `tcpdump` на интерфейсе `lo` и получила такие пакеты:

```
06:04:36.160663 lo    In  IP 127.0.0.1.44986 > 127.0.0.1.4101: Flags [S], seq ..., length 0
06:04:36.160696 lo    In  IP 127.0.0.1.4101 > 127.0.0.1.44986: Flags [R.], seq 0, ack ..., length 0
06:04:37.317324 lo    In  IP 127.0.0.1.41360 > 127.0.0.1.631: Flags [S], seq ..., length 0
06:04:37.317330 lo    In  IP 127.0.0.1.631 > 127.0.0.1.41360: Flags [R.], seq 0, ack ..., length 0
```

Также видно, что через сокеты работает соединение:
```
u_str ESTAB 0 0 * 631 * 20748
u_str ESTAB 0 0 @/tmp/.X11-unix/X0 20748 * 631
```

Если X получает отказ в TCP-соединении, то зачем ему вообще доступ к `lo`? Просто для того, чтобы получить отказ?  
Пробовала также запускать X-сервер с опцией `-nolisten tcp`, чтобы полностью отключить TCP. Результат тот же — черный экран, даже если `lo` остаётся открытым.

Я не понимаю, какие изменения вносят BunsenLabs или SpiralLinux, что там всё работает без доступности `lo` и с отключением TCP.  
Если это не X-сервер требует соединений — тогда что именно? И почему эта активность не видна в `tcpdump`?

Пока что остаётся ощущение, что Debian 12.X добавил какую-то скрытую зависимость от loopback-интерфейса на уровне IPC, но конкретики я пока не нашла.


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено школьный админ , 28-Апр-25 21:23 
> Пробовала также запускать X-сервер с опцией `-nolisten tcp`, чтобы полностью отключить
> TCP. Результат тот же — черный экран, даже если `lo` остаётся
> открытым.

Стоит Дебиан 12 последнего обновления.
И блокирование lo интерфейса, и запуск X сервера с указанной опцией никак на раб оту графики не влияют.
Насколько я помню, уже давно tcp в иксах отключена по умолчанию

Во всяком
# ss -tlpn
# ss -ulpn
не показывают, что иксы слушают ка каком-либо порте (обычно это 6000+n)

Правда, у меня десктоп не установлен. Запускается openbox и графический терминал.


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено школьный админ , 29-Апр-25 11:37 
Еще пару слов...
> Пробовала также запускать X-сервер с опцией `-nolisten tcp`, чтобы полностью отключить
> TCP. Результат тот же — черный экран, даже если `lo` остаётся
> открытым.

Сейчас посмотрел на компьютере, где запущен lightdm и lxqt.
Сервер запущен с опцией -nolisten tcp.
# cat /proc/2537/cmdline
/usr/lib/xorg/Xorg:0-seatseat0-auth/var/run/lightdm/root/:0-nolistentcpvt7-novtswitch

Что касается вашей проблемы с lo интерфейсом - думаю, проблема не в иксах. Этот интерфей используется достаточно часто для обращения к различным службам, напр prcbind (порт 111).


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено ulinna , 08-Май-25 17:28 
> Что касается вашей проблемы с lo интерфейсом - думаю, проблема не в
> иксах. Этот интерфей используется достаточно часто для обращения к различным службам,
> напр prcbind (порт 111).

Обновление по проблеме:

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

    Порт 631 оказался связан с пакетами:

        system-config-printer
        system-config-printer-common
    
    После удаления этих пакетов порт 631 исчез из tcpdump.

    Главной причиной зависания DE оказался пакет xbrlapi (экранный Braille-интерфейс). При запуске системы он делал один запрос на порт 4101 через 127.0.0.1, и если lo был недоступен, это мешало дальнейшей загрузке DE.
    После удаления пакета — система загружается нормально даже при полностью закрытом интерфейсе lo.

Таким образом, X-сервер сам по себе не зависит от loopback-интерфейса, но отдельные вспомогательные пакеты могут нарушать загрузку, если localhost недоступен.

Спасибо всем за участие.


"Блокировка lo в фаерволле ломает запуск DE в Debian 12"
Отправлено 1 , 11-Май-25 14:37 
блокировать 127.0.0.1 плохая идея. проблемы будут вылезать всяческие.