Pourquoi Samba refuse les clients VPN qui atteignent pourtant le serveur

Un client VPN fait un ping au serveur de fichiers, résout son nom et ne peut toujours pas ouvrir un partage. La politique d’hôtes de Samba est l’une des quatre couches qui peuvent refuser cette connexion, et c’est celle que les gens modifient en dernier. La liste d’autorisation est évaluée contre l’adresse source que smbd reçoit réellement, qui n’est peut-être pas celle que le client croit avoir. Bien déterminer cette source transforme un problème d’autorisation flou en une modification de configuration d’une ligne.

Quatre couches qui échouent avec le même message

Un refus peut venir de la route, du pare-feu de l’hôte, de la politique d’hôtes de Samba ou de l’identité SMB. Chaque couche produit chez le client un message qui dit à peu près la même chose, c’est pourquoi les suppositions coûtent un après-midi. Ordonner les vérifications du réseau vers l’intérieur élimine la majeure partie des suppositions.

Commencez par le transport. Si le port 445 n’atteint jamais le serveur, aucun réglage de Samba n’importe, et une capture sur l’interface du serveur règle la question en quelques secondes. Vient ensuite le pare-feu de l’hôte sur le serveur lui-même, qui peut écarter une source autorisée avant même que smbd ne la voie. C’est seulement après ces deux couches que la liste d’autorisation devient candidate. L’authentification vient en dernier, car un échec de connexion et un refus d’hôte se lisent différemment dans le journal du serveur, même lorsque le client présente les deux comme un accès refusé. L’ordre compte plus que les outils, car chaque couche a une commande qui lui répond.

Trouvez l’adresse source que smbd voit réellement

En accès routé, le serveur voit généralement l’adresse du client issue du pool VPN. Avec une traduction de source sur la passerelle, il voit à la place l’adresse LAN de la passerelle, et chaque client derrière cette passerelle devient indifférenciable.

Cette différence décide si une entrée de la liste d’autorisation est une politique ou un trou. Autoriser une adresse de passerelle traduite admet tous ceux qui sont derrière, ce qu’une règle par client cherchait rarement à exprimer. Lisez la source sur le serveur et non dans l’idée que le client se fait de sa propre adresse. Une capture sur l’interface du serveur est le moyen le moins coûteux de la voir, et la même capture prouve si le paquet est arrivé. Limitez la capture avec un nombre de paquets et ajoutez un filtre d’hôte une fois que vous savez quel client vous suivez. La table des sessions de Samba est l’autre moitié de la réponse : dans smbstatus -b, la colonne client de chaque ligne de session est le pair que smbd a enregistré, et c’est la confirmation la plus rapide de l’adresse qui a réellement atteint le service.

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

Lisez la liste d’autorisation comme Samba la lit

Le paramètre hosts allow prend une liste d’adresses, de réseaux ou de noms, et peut apparaître globalement ou à l’intérieur d’un partage. Deux entrées qui vous semblent équivalentes peuvent ne pas l’être pour l’analyseur, donc la configuration effective est ce qu’il faut inspecter. Cela signifie la vue fusionnée et non le fichier que vous avez modifié par hasard.

Une paire illustrative de préfixes ressemble à la ligne ci-dessous, et c’est un exemple et non un remplacement des entrées déjà présentes. Conservez les clients administratifs et applicatifs qui se connectent légitimement aujourd’hui, et lisez toute liste de refus dans la même passe. Qu’un hôte soit admis dépend de la politique dans son ensemble, alors testez le client exact au lieu de raisonner sur la priorité. L’autorisation d’hôte ne dit rien non plus des autorisations de partage ni des modes du système de fichiers, qui sont des portes séparées. Un succès des outils de test signifie que la politique d’hôtes admet cette source, et rien de plus.

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

Modifiez le fichier qui survit à un redémarrage

Sur un hôte Linux ordinaire, le chemin de configuration est fixe et le service le relit au redémarrage. Sur un routeur ou un appareil, le smb.conf en cours est souvent généré au démarrage, et une modification manuelle disparaît au redémarrage suivant. Utilisez le mécanisme de personnalisation pris en charge de l’appareil, qui est généralement un fichier de configuration propre.

La tentation à ce stade est de flasher un firmware alternatif parce qu’un fil a rapporté que cela fonctionnait. C’est un changement important pour un petit problème de politique, et cela fait sortir l’appareil de son état pris en charge. Identifiez d’abord le contrôle pris en charge, car la plupart des appareils exposent la liste d’autorisation via leur propre interface. S’ils ne le font vraiment pas, cette limitation plaide pour un autre matériel et non pour une compilation non prise en charge.

Notez quel fichier vous avez modifié et ce qui le régénère, afin que la personne suivante ne répète pas le diagnostic.

Testez un client autorisé et un client exclu

Testez les deux résultats, pas seulement celui que vous vouliez. Un client autorisé qui se connecte prouve que le changement fonctionne ; un client exclu qui reste refusé prouve que la règle n’a pas simplement tout ouvert.

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

Quand la connexion n’atteint jamais smbd, la réponse se trouve dans le routage ou dans le pare-feu du serveur. Si l’hôte est admis et que la connexion échoue, le problème est l’identité et élargir la liste d’autorisation n’aidera pas. Gardez la sortie de diagnostic privée, car un journal Samba détaillé peut exposer des chemins de partage et des noms de comptes. Changez une couche par essai, sinon le résultat suivant ne vous apprendra rien.