Porque o Samba rejeita clientes VPN que chegam ao servidor

Um cliente VPN faz ping ao servidor de ficheiros, resolve o seu nome e mesmo assim não consegue abrir uma partilha. A política de anfitriões do Samba é uma das quatro camadas que podem rejeitar essa ligação, e é a que as pessoas editam por último. A lista de autorizados é avaliada contra o endereço de origem que o smbd recebe de facto, e pode não ser o endereço que o cliente pensa ter. Acertar nessa origem transforma um problema vago de permissões numa alteração de configuração de uma linha.

Quatro camadas que falham com a mesma mensagem

Uma rejeição pode vir da rota, da firewall do anfitrião, da política de anfitriões do Samba ou da identidade SMB. Cada camada produz no cliente uma mensagem que diz mais ou menos o mesmo, por isso adivinhar custa uma tarde. Ordenar as verificações da rede para dentro elimina a maior parte das suposições.

Comece pelo transporte. Se a porta 445 nunca chega ao servidor, nenhuma definição do Samba importa, e uma captura na interface do servidor resolve isso em segundos. Depois vem a firewall do anfitrião no próprio servidor, que pode descartar uma origem permitida antes de o smbd a ver. Só depois de essas duas passarem é que a lista de autorizados se torna candidata. A autenticação vem por último, porque uma falha de início de sessão e uma rejeição de anfitrião aparecem de forma diferente no registo do servidor, mesmo quando o cliente relata ambas como acesso negado. A ordem importa mais do que as ferramentas, porque cada camada tem um comando que lhe responde.

Encontre o endereço de origem que o smbd vê de facto

Com acesso encaminhado o servidor vê normalmente o endereço do cliente do conjunto VPN. Com tradução de origem na gateway vê, em vez disso, o endereço LAN da gateway, e cada cliente atrás dessa gateway torna-se indistinguível.

Essa diferença decide se uma entrada da lista de autorizados é política ou um buraco. Permitir um endereço de gateway traduzido admite todos os que estão atrás, o que uma regra por cliente raramente queria exprimir. Leia a origem no servidor e não na ideia que o cliente tem do seu próprio endereço. Uma captura na interface do servidor é a forma mais barata de a ver, e a mesma captura prova se o pacote chegou. Limite a captura com uma contagem de pacotes e acrescente um filtro de anfitrião quando souber que cliente está a seguir. A tabela de sessões do Samba é a outra metade da resposta: em smbstatus -b a coluna de cliente de cada linha de sessão é o par que o smbd registou, e é a confirmação mais rápida do endereço que chegou de facto ao serviço.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

Leia a lista de autorizados como o Samba a lê

A definição hosts allow aceita uma lista de endereços, redes ou nomes, e pode aparecer globalmente ou dentro de uma partilha. Duas entradas que lhe parecem equivalentes podem não o ser para o analisador, por isso a configuração efetiva é o que deve ser inspecionado. Isso significa a vista fundida e não o ficheiro que editou por acaso.

Um par ilustrativo de prefixos parece-se com a linha abaixo, e é um exemplo e não uma substituição das entradas que já existem. Mantenha os clientes administrativos e de aplicações que hoje se ligam legitimamente, e leia qualquer lista de bloqueio na mesma passagem. Que um anfitrião seja admitido depende da política no seu conjunto, por isso teste o cliente exato em vez de raciocinar sobre a precedência. A permissão de anfitrião também não diz nada sobre permissões de partilha ou modos do sistema de ficheiros, que são portas separadas. Um sucesso das ferramentas de teste significa que a política de anfitriões admite essa origem, e nada mais.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

Altere o ficheiro que sobrevive a um reinício

Num anfitrião Linux normal o caminho de configuração é fixo e o serviço volta a lê-lo ao reiniciar. Num router ou aparelho o smb.conf em execução é muitas vezes gerado no arranque, e uma edição manual desaparece no reinício seguinte. Use o mecanismo de personalização suportado do aparelho, que normalmente é um ficheiro de configuração próprio.

A tentação neste ponto é gravar um firmware alternativo porque um fio reportou que funcionava. É uma alteração grande para um problema pequeno de política, e retira o dispositivo do seu estado suportado. Identifique primeiro o controlo suportado, já que a maioria dos aparelhos expõe a lista de autorizados através da sua própria interface. Se realmente não o fazem, essa limitação é um argumento para outro hardware e não para uma compilação não suportada.

Anote que ficheiro alterou e o que o volta a gerar, para que a pessoa seguinte não repita o diagnóstico.

Teste um cliente permitido e um cliente excluído

Teste os dois resultados, não apenas o que queria. Um cliente permitido que se liga prova que a alteração funciona; um cliente excluído que continua rejeitado prova que a regra não abriu simplesmente tudo.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

Quando a ligação nunca chega ao smbd, a resposta está no encaminhamento ou na firewall do servidor. Se o anfitrião é admitido e o início de sessão falha, o problema é a identidade e alargar a lista de autorizados não ajudará. Mantenha a saída de diagnóstico privada, porque um registo detalhado do Samba pode expor caminhos de partilha e nomes de contas. Altere uma camada por tentativa, ou o resultado seguinte não lhe dirá nada.