Entry tags:
О нюансах работы SMB
SMB, он же CIFS, он же "Майкрософт нетворкинг". Короче сетевые шары и файлы по майкрософтовской сети.
Оказывается, с ним есть следующие грабли.
Положим у нас есть два конца VPN туннеля сделанного, допустим, на OpenVPN. С OpenVPN (но не только) иногда бывает в винде такая штука -- при назначении адреса интерфейсу VPN невозможно почему-то очистить предыдущий адрес из диапазона APIPA. И этот интерфейс остаётся с апиповским адресом, и ещё одним, тем, который был назначен VPN демоном/службой.
Как правило, большинство служб через такой двухадресный интерфейс нормально работают, но не SMB. Я убил на это несколько часов. Проверял проходимость портов и так далее и тому подобное. Потом обратил внимание, что в выводе nbtstat -A ipaddress указана только привязка к адресу 169.254-бла-бла.
Т.е., судя по всему, SMB умеет работать только через первый адрес интерфейса. На остальные забивает болт.
Как я решил: в конфиге OpenVPN прописал ip-win32 manual, VPN-интерфейсу назначил статический айпишник и проблема исчезла.
Оказывается, с ним есть следующие грабли.
Положим у нас есть два конца VPN туннеля сделанного, допустим, на OpenVPN. С OpenVPN (но не только) иногда бывает в винде такая штука -- при назначении адреса интерфейсу VPN невозможно почему-то очистить предыдущий адрес из диапазона APIPA. И этот интерфейс остаётся с апиповским адресом, и ещё одним, тем, который был назначен VPN демоном/службой.
Как правило, большинство служб через такой двухадресный интерфейс нормально работают, но не SMB. Я убил на это несколько часов. Проверял проходимость портов и так далее и тому подобное. Потом обратил внимание, что в выводе nbtstat -A ipaddress указана только привязка к адресу 169.254-бла-бла.
Т.е., судя по всему, SMB умеет работать только через первый адрес интерфейса. На остальные забивает болт.
Как я решил: в конфиге OpenVPN прописал ip-win32 manual, VPN-интерфейсу назначил статический айпишник и проблема исчезла.