Восстановить файл из diff

Мне наконец-то удалось это зафиксировать, но я пока точно не понимаю, зачем нужно вносить некоторые из этих изменений.

CentOS 7 всегда «просто работает» из-за своей старой кодовой базы. Все проблемы являются результатом изменений, которые были внесены с тех пор, как исходные пакеты стали доступны для CentOS. Это еще больше повышает доверие к мнению, что эти ОС серверного -класса и их соответствие более старым и известным -стабильным пакетам.

Разрешение имени NetBIOS

Проблема с ошибкой разрешения имен NetBIOS является результатом функции firewalld, называемой «автоматические помощники». Патч 2017 -02 -26 в ядре 4.9.13 изменил поведение службы брандмауэра по умолчанию.Хотя результатом firewall-cmd --get-automatic-helpersвсегда было system, фактическое значение определяется в ядре, и это то, что изменилось.

Чтобы принудительно использовать старое поведение, эта функция должна быть включена явно:

firewall-cmd --set-automatic-helpers=yes

Перезапуск smbи имена NetBIOS теперь должны работать с ping, nmblookupи т. д. Обратите внимание, что это уязвимость системы безопасности. См. раздел о безопасности , чтобы узнать больше об этом. Обратите внимание на настройку по умолчанию для вашей системы, прежде чем изменять ее с помощью firewall-cmd --get-automatic-helpers.

В качестве альтернативы вы можете попробовать временно отключить службу брандмауэра, чтобы проверить, имеет ли она вообще какое-либо значение.

Поделиться видимостью

Отлично! Теперь акции работают, верно? Ну, может быть .

Попробуйте просмотреть свои акции:

smbtree -b -N

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

ifconfig | grep -Po '^\w+'

Добавьте эти интерфейсы в /etc/samba/smb.conf; в моем случае:

interfaces = lo virbr0 wlo1
bind interfaces only = yes

Изначально я настроил Samba так, чтобы разрешались подключения только через префиксы IP 127.и 10.0.1. Но при просмотре журнала smbя заметил это сообщение:

Denied connection from 192.168.122.1 (192.168.122.1)

Это было заблокированное соединение с локальной виртуальной машиной, которой был назначен адрес 192.168.через NAT(virbr0). После добавления этого префикса в мою конфигурацию я теперь мог видеть общие ресурсы для этой машины, но не для моей сети 10.0.1. Затем я предположил, что, возможно, Sambaне привязан к этому интерфейсу(wlo1). Я добавил его в свой smb.confи вдруг все заработало. Я мог просматривать общие ресурсы и получать доступ к сетевым устройствам.

Интерфейс wlo1— это беспроводная карта, и я не знаю, почему она не привязана. У меня была такая же проблема с NetBIOS на другой машине в сети, которая подключена через Ethernet, и мне не нужно было указывать какие-либо интерфейсы.Вот почему я сказал, что ваши акции уже могут быть видны без внесения этого изменения.

Примечания по безопасности

Согласно списку рассылки ядра Linux , проблема сбоя разрешения NetBIOS является прямым результатом изменения функции «автоматического помощника» брандмауэра :

.

Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper assignment") is causing behavior regressions in firewalls, as traffic handled by conntrack helpers is now by default not passed through even though it was before due to missing CT targets (which were not necessary before this commit).

Изменение внесено из соображений безопасности:

The default had to be switched off due to security reasons and therefore should stay the way it is, but let's be friendly to firewall admins and issue a warning the first time we're in situation where packet would be likely passed through with the old default but we're likely going to drop it on the floor now.

См.:

• https://cansecwest.com/csw12/conntrack-attack.pdf
• https://home.regit.org/netfilter-en/secure-use-of-helpers/

Документация Arch Linux также содержит хорошее резюме:

And you are using a firewall (iptables) because you do not trust your local (school, university, hotel) network. This may be due to the following: When the smbclient is browsing the local network it sends out a broadcast request on udp port 137. The servers on the network then reply to your client but as the source address of this reply is different from the destination address iptables saw when sending the request for the listing out, iptables will not recognize the reply as being "ESTABLISHED" or "RELATED", and hence the packet is dropped.

И приводит возможное решение путем добавления явного помощника через iptablesвместо слишком широких автоматических помощников:

iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns

Дополнительные показания:

https://bugzilla.redhat.com/show_bug.cgi?id=1297235