Tu es sur une machine A, tu as un compte ssh (toto@labas) sur une machine B qui peut interroger une machine C sur le port 445, tu peux «transporter ce service sur la machine A sur le port 1445 en faisant depuis A
Voilà, c’est tout
Le problème est que les pc clients à connecter au samba son des windows.
Il suffit à ces machines d’interroger la machine A (rien n’interdit d’ailleurs de mettre un port à 445 si ce n’est qu’il faut être root dans ce cas).
donc sur la machine A (windows) je fait “\ipDeLaMachineB\Partage” et àa va rediriger ver le serveur SMB via le port 1445 ?
Non la machine A’ interroge A qui transmet à B qui interroge C et retour
Donc, “ssh -N -L 1445:C:445 toto@labas” est à réaliser sur le poste Windows ? 
Non, la commande
exécutée sur une machine serveurlocal ouvre un port p1 sur la machine locale qui est déportée sur le port p2 de la machine serveurdistant visible depuis la machine intermédiaire. serveurdistant et intermediaire sont loin (mettons au Pérou), intermediaire contient un serveur ssh et connait la machine serveurdistant. serveurlocal est chez toi et ta machine windows interroge serveurlocal. Tu peux également «déporter» les UDP
Rien ne fonctionne, me gave grave cette box, le pire c’est que je ne sais même pas passer sur free car il n’y à pas de débit dans ma zone, seul numericable passe…
Y à quand même bien moyen de ce connecter sur un samba distant malgré le blocage du port 445 !!!
Si seulement dans windows on pouvais changer le port de sortie…
Ce que tu veux faire est classique, il y a 3 solutions indiquées ici, celle que tu proposais incluse
Le transfert de port par SSH me semble contraignant : fonctionne uniquement pour TCP et pas UDP (or certaines fonctions de Netbios/SMB utilisent UDP), doit être lancé par une commande ssh, nécessite les droits root pour les ports < 1024… Si besoin de chiffrement, un VPN de type openvpn entre les deux firewalls me semble plus appropriée. On peut même faire un VPN ponté pour faire comme si les deux côtés étaient dans le même domaine de diffusion. Si pas besoin de chiffrement, un simple tunnel d’encapsulation IPIP ou GRE entre les deux firewalls suffit (man ip, commande tunnel).
Pour en revenir à la solution à base de NAT,
L’adresse IP interne de quoi ?
“WAN” pour une adresse interne, c’est vachement logique comme nommage…
Tu ne veux pas plutôt dire l’adresse externe du firewall client, sur l’interface connectée à la box ?
Le but est de translater tous les ports interdits en d’autres ports lorsque les paquets sortent à l’extérieur, et l’inverse lorsque les paquets entrent. Par exemple pour le port TCP 445, ceci devrait suffire.
- Sur le firewall côté client :
iptables -t nat -A OUTPUT -o $if_ext -p tcp --dport 445 -j DNAT --to :1445
iptables -t nat -A POSTROUTING -o $if_ext -p tcp --sport 445 -j SNAT --to $ip_ext:1445
où if_ext est l’interface du firewall connectée à la box et ip_ext son adresse IP.
- Sur le firewall côté serveur :
iptables -t nat -A PREROUTING -i $if_ext -d $ip_ext -p tcp --dport 1445 -j DNAT --to $ip_serveur:445
où if_ext est l’interface extérieure du firewall, ip_ext son adresse IP et ip_serveur l’adresse IP interne du serveur SMB.
Il me semblait qu’on pouvait le faire avec des tubes (mkfifo) redirigés par nc, mais c’est sûr que c’est plus compliqué qu’un VPN qui rgèlerait ses soucis.
edit: voilà la solution à laquelle je pensais pour le trafic UDP (ou qque chose d’approchant en tout cas)
Merci pour toutes vos réponses, retour des testes,
[quote=“PascalHambourg”]
- Sur le firewall côté client :
iptables -t nat -A OUTPUT -o $if_ext -p tcp --dport 445 -j DNAT --to :1445
iptables -t nat -A POSTROUTING -o $if_ext -p tcp --sport 445 -j SNAT --to $ip_ext:1445
où if_ext est l’interface du firewall connectée à la box et ip_ext son adresse IP.
- Sur le firewall côté serveur :
iptables -t nat -A PREROUTING -i $if_ext -d $ip_ext -p tcp --dport 1445 -j DNAT --to $ip_serveur:445
où if_ext est l’interface extérieure du firewall, ip_ext son adresse IP et ip_serveur l’adresse IP interne du serveur SMB.[/quote]
Ne fonctionne pas sur une box numericable, du coup, j’ai testé le firewall avec une box free et la ça fonctionne, j’en conclu que avec numericable on ne sais pas dérouter smb. 
Je suis donc bien coincé, la solution VPN n’est pas viable pour déployer sur plusieurs sites. 
Seul solution, déménager dans une zone ou il y à free avec un bon débit. 
Hein ?
Bien sur que si …
[quote=“CreatAddict”]Merci pour toutes vos réponses, retour des testes,
[…]
Ne fonctionne pas sur une box numericable, du coup, j’ai testé le firewall avec une box free et la ça fonctionne, j’en conclu que avec numericable on ne sais pas dérouter smb.
[/quote]Ou peut être tu crois que ça marche et que tu adresses directement le serveur sans utiliser les règles.
As tu testé tes règles bêtement avec tcpdump et des telnet sur les ports concernés? Tu devrais voir là où ça coince.
Je vais jsute le faire Vendredi 
Quand je dit “pas viable…” c’est pas quelque personne à connecter sur une VM, mais plusieurs personnes sur plusieurs VM…
Une VM est une machine virtuel ou il y à samaba installé
Cela ne pose strictement aucun problème. Un VPN peut se comporter comme un réseau physique.
Pour tes règles, il te faut faire du DNAT et non SNAT dans ton parefeu. Le POSTROUTING ne peut que modifier la source. Il est doncnécessaire de faire la translation sur les chaines entrantes. Ce serait donc
iptables -t nat -A OUTPUT -o $if_ext -p tcp --dport 445 -j DNAT --to :1445
iptables -t nat -A PREROUTING -i $if_int -p tcp --dport 445 -j DNAT --to $ip_ext:1445
et
iptables -t nat -A PREROUTING -i $if_ext -d $ip_ext -p tcp --dport 1445 -j DNAT --to $ip_serveur:445Fonctionne parfaitement chez moi en bloquant le port 445
Et avec la box Free sans les règles de NAT, ça fonctionne aussi ?
Attention : j’ai écrit “par exemple pour le port 445”, mais si ton client SMB utilise d’autres ports et/ou protocoles (137, 139…, en TCP et UDP) il faut aussi des règles pour chaque combinaison de port/protocole.
Si tous les ports Netbios/SMB/CIFS sont modifiés avant de partir à l’extérieur, le firewall de Numericable ne peut identifier ce type de trafic que s’il analyse le contenu des paquets par DPI (Deep Packet Inspection) indépendamment des ports. Dans ce cas le VPN chiffré risque d’être la seule solution.
Côté client, il faut aussi faire du SNAT dans POSTROUTING au cas où le poste client utilise un port source identique au port destination (déjà constaté sur des machines Windows). Ta règle DNAT dans PREROUTING qui redirige vers l’adresse externe du firewall n’a pas de sens, il ne faut pas modifier l’adresse destination des connexions sortantes mais seulement le port. En revanche j’ai mis la règle DNAT dans la mauvaise chaîne (OUTPUT) qui serait valable pour des connexions émises par le firewall lui-même. Il faut la mettre dans la chaîne PREROUTING :
où if_int est l’interface du firewall connectée au poste client et ip_int son adresse IP.
[quote=“PascalHambourg”]
Côté client, il faut aussi faire du SNAT dans POSTROUTING au cas où le poste client utilise un port source identique au port destination (déjà constaté sur des machines Windows). Ta règle DNAT dans PREROUTING qui redirige vers l’adresse externe du firewall n’a pas de sens, il ne faut pas modifier l’adresse destination des connexions sortantes mais seulement le port. [/quote]
J’ai fait les lignes et les tests avec ip_ext = IP de la machine distante (tests à coup de telnet et tcpdump pour vérifier), je précise effectivement tout à chaque fois dans les règles pour avoir une vision claire, là du cela n’avait pas de sens effectivement.
Par contre pour le SNAT, je n’ai pas compris ta remarque, puisque coté client il voit un serveur avec le port 445 donc dans ce cas il utilisera le port 445, et le serveur lui recevra une connexion arrivant sur le port 445 donc s’attendant dans ce cas à une connexion venant du port 445 ce qui ne sera jamais le cas vu de toute façon la translation d’adresse à la sortie de la box numericable
Là c’est moi qui ne comprends pas ta remarque.
Il arrive que le client se connecte au serveur SMB depuis un port source identique au port destination (bloqué par le FAI). Si on se contente de modifier le port destination, les paquets sortants risquent d’être bloqués par le FAI à cause du port source (ou les paquets de réponse entrants à cause du port destination). Le NAT de la box ne modifie pas forcément le port source des connexions sortantes ; les cibles SNAT ou MASQUERADE d’iptables ne le modifient que si c’est nécessaire pour éviter une collision avec une autre connexion. Exemple : deux postes internes font une connexion au même port du même serveur externe depuis le même port source.
En y repensant, cette situation pourrait se produire dans le cas présent et une règle SNAT imposant un port unique pourrait empêcher plus d’une connexion. Il serait plus sage de prévoir une plage de ports de taille supérieure ou égale au nombre de postes plutôt qu’un port unique.