Комментарии 13
Тема поднята важная, но в тексте сумбур и колхоз.
- Многие шаги не автоматизированы, не руками же чинить при каждом подключении?
- Если DHCP сломан, это надо править на сервере, а не бороться локально.
- mDNS (Bonjour & co) и .local могут работать вместе, если правильно настроен /etc/nsswitch.conf.
- В итоге контейнеры в отдельных сетях так и не могут разрешать домены в .local. Насколько я знаю, решается либо /etc/hosts (с очевидными недостатками), либо через socat, как описано (но у меня в нем регулярно виснут соединения, приходится перезапускать), либо через
--add-host
/extra_hosts
для контейнер (не лучше /etc/hosts).
По 3ему пункту можете поделиться знаниями?
https://github.com/lathiat/nss-mdns
nss-mdns will check SOA before every request to resolve .local names, meaning that neither nss-mdns nor Avahi need to be disabled to allow .local queries to be served from unicast DNS.
Вот старая статья, которая, к сожалению, не рассказывает, почему надо такие настройки делать.
Вот здесь описание работы библиотек/и для nsswitch.
Вот здесь описание файла настроек nsswitch.
В кратце, строка в конфиге должна выглядеть так:
hosts: files mdns4_minimal dns mdns
Почему так:
1. Мы проверяем сначала файлы hosts.
2. Потом проверяем адреса 169.254.0.0/16 и домены X.local и Y.local. (только второй уровень днс).
3. Потом делаем поиск в днс серверах.
4. И только после этого проверяем все адреса ip стеков 4 и 6, а так же все домены перечисленные в файле /etc/mdns.allow
- А зачем руками чинить при каждом подключении? Один раз это настраивается. Нечего там автоматизировать, настройки соединения менеджер помнит.
- Кому из админов это надо, рисковать менять поисковый домен. Фиг знает, что на него завязано у клиентов. Проще самому починить.
- Так как это мне ненужно, проще удалить и не настраивать.
- Решение описано, но мне не нужно. Даже два. Сокат рвет соединение, сделай багу, поступи правильно! :)
В общем претензии непонятны :)
О каком сумбуре речь вообще неясно, можно команды прям по очереди выполнить и все причины описаны. Это уж вообще странное заявление :) Все это похоже на высосанный из пальца комент :)
- Поверю вам, не особо знаю NetworkManager.
- Админам деньги платят, чтобы настроили все правильно. По-вашему, лучше каждому клиенту приседать?
- Тогда должна быть оговорка. Иначе получается инструкция, которая ломает смежную функциональность.
- Достаточно оказалось открыть man socat и прочитать про -T :)
команды прям по очереди выполнить и все причины описаны
Претензия как раз к тому, что вы останавливаетесь на удобном вам решении, но не всегда упоминаете его проблемы (вовсе необязательная поломка mDNS, итоговое решение для Docker не связано с VPN).
P. S. Минусы не от меня.
Ну тут да, это инструкция по решению конкретной проблемы, а не ман, соглашусь, удобно для меня.
Минусов два, а в закладках заметка у семерых. Ценители минусов могут расслабиться ;)
Похоже эта issue https://github.com/systemd/systemd/issues/6076
Спасибо.
nmcli connection modify yourConnectionName ipv4.dns-search «local» прямо помогло, а главное — я понял почему у меня DNS VPN-а не работали.
Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved