Haproxy Et Log/blocage Des Ip Sur Dsm, Filestation..

[devildant]

https://myds.synology.com/support/support_form.php?lang=fre

il faut écrire en anglais par contre

Modifié le 25 octobre 2013 par devildant

[Thierry94]

Merci ... C'est fait

[devildant]

Bonjour,

je suis actuellement en relation avec synology pour le problème du reverse proxy et le WEBDAV (dsfile)

je vous tiendrais au courant du résultat final.

pour le problème avex dsphoto et le reverse proxy, j'ai fait un patch a photostation, je ferais un tuto dés que j'aurais plus de temps.

[Thierry94]

Cool

[devildant]

bonjour,

Bon alors concernant de webdav (dsfile), j'ai informé synology du bug, il mon dit qu'il allait étudier la question.

pour la partie photostation (ds photo) comme promis, voici mon petit tuto

(désoler j'ai mis un peu de temps avant de le rédiger )

Voilà, j'espère qu'il vous servira.

Bonnes fêtes.

Modifié le 24 décembre 2013 par devildant

[Moonface]

Bonjour,

Quelqu'un a du nouveau de la part de Synology concernant ce problème.

Merci à vous.

Fabien

[devildant]

j'ai relancé synology au sujet du webdav mais ce n'est pas gagné

[Sylar]

Bonjour à tous,

Désolé pour cette remontée de topic bien ancien, mais je me retrouve confronté exactement au même soucis que celui mentionné dans le post.

Je viens de mettre en place haproxy dans un conteneur docker, et tout marche parfaitement bien. Sauf que DSM persiste à bloquer l'IP du reverse proxy, au lieu de celle du client, malgré l'ajout de ce qu'il faut pour ajouter les bons headers dans la configuration. J'avais le sentiment que le soucis était résolu, mais il ne semblerait pas ?

Au cas où, je joins ma configuration de haproxy.

Merci de vote aide !

haproxy.cfg

[gaetan.cambier]

Pour moi c'est a cause de docker

En plus mettre un reverse proxy dans un conteneur avec du routage et du nat c'est pas le mieux

Pourquoi ne pas utiliser la paquet haproxy ?

[Sylar]

il y a 22 minutes, gaetan.cambier a déclaré:

 

Pour moi c'est a cause de docker

En plus mettre un reverse proxy dans un conteneur avec du routage et du nat c'est pas le mieux

Pourquoi ne pas utiliser la paquet haproxy ?

C'est probablement à cause de docker, oui. Enfin, j'imagine, mais conceptuellement le cas ne devrait pas être géré différemment : on a un serveur faisant office de reverse proxy, avec sa propre IP, et derrière le diskstation qui héberge une partie des backends. 

Quant à l'utilisation de docker, disons qu'il me permet de d'éditer facilement le fichier de conf, sans passer par le GUI du paquet qui ne permet pas de saisir l'ensemble des paramètres dont j'ai besoin. Mais s'il le faut je reviendrai vers le paquet haproxy.

A vrai dire, entre les 2 configurations (celle avec le paquet et celle avec docker), la seule différence concerne la déclaration des backends, spécifiés sur localhost contre l'IP du diskstation, respectivement. Comme localhost est exclu du blocage d'IP par défaut semble t'il, est il absolument certain que le blocage d'IP est bien actif dans le cas du paquet ?

Modifié le 14 décembre 2015 par Sylar

[Sylar]

Il y a 14 heures , Sylar a déclaré:

C'est probablement à cause de docker, oui. Enfin, j'imagine, mais conceptuellement le cas ne devrait pas être géré différemment : on a un serveur faisant office de reverse proxy, avec sa propre IP, et derrière le diskstation qui héberge une partie des backends. 

Quant à l'utilisation de docker, disons qu'il me permet de d'éditer facilement le fichier de conf, sans passer par le GUI du paquet qui ne permet pas de saisir l'ensemble des paramètres dont j'ai besoin. Mais s'il le faut je reviendrai vers le paquet haproxy.

A vrai dire, entre les 2 configurations (celle avec le paquet et celle avec docker), la seule différence concerne la déclaration des backends, spécifiés sur localhost contre l'IP du diskstation, respectivement. Comme localhost est exclu du blocage d'IP par défaut semble t'il, est il absolument certain que le blocage d'IP est bien actif dans le cas du paquet ?

Alors, après investigation, c'est clairement lié à Docker. Celui-ci crée une nouvelle passerelle réseau d'IP X.X.X.1, et le container a une adresse X.X.X.2. Et il se trouve que l'en tête X_FORWARDED_FOR ajoutée par haproxy, et qui capture normalement l'IP du client, est celle de la passerelle de docker (logique, du point de vue d'haproxy), et non celle du vrai client. D'où le blocage. Finalement, c'est donc comme si j'avais 2 serveurs à traverser avant d'atteindre les backends.

Bon, je vais regarder comment jouer avec les options réseau de docker pour comprendre comment modifier ça. Si c'est faisable ...

[Sylar]

Sur 15 décembre 2015 09:23:04 , Sylar a déclaré:

Alors, après investigation, c'est clairement lié à Docker. Celui-ci crée une nouvelle passerelle réseau d'IP X.X.X.1, et le container a une adresse X.X.X.2. Et il se trouve que l'en tête X_FORWARDED_FOR ajoutée par haproxy, et qui capture normalement l'IP du client, est celle de la passerelle de docker (logique, du point de vue d'haproxy), et non celle du vrai client. D'où le blocage. Finalement, c'est donc comme si j'avais 2 serveurs à traverser avant d'atteindre les backends.

Bon, je vais regarder comment jouer avec les options réseau de docker pour comprendre comment modifier ça. Si c'est faisable ...

Aller, promis, après j'arrête mon monologue ;)

J'ai lancé docker en mode "host", ce qui permet au container haproxy de partager la même pile réseau que le diskstation. De cette façon, les entête X_FORWARDED_FOR et X_CLIENT_IP sont correctement  attribuées et contiennent bien la vraie IP du client. Pour autant, le système de blocage d'IP continue de se bloquer lui-même ...

Au cas où, voici les infos que je trouve dans les requêtes HTTP envoyées depuis l'extérieur. L'IP locale du diskstation est 192.168.1.2, et le client depuis lequel je fais un wget qui me renvoie ceci a pour adresse 134.X.X.X

Array
(
    [USER] => http
    [HOME] => /var/services/web
    [FCGI_ROLE] => RESPONDER
    [REDIRECT_MOD_X_SENDFILE_ENABLED] => yes
    [REDIRECT_HANDLER] => php5-fastcgi
    [REDIRECT_STATUS] => 200
    [MOD_X_SENDFILE_ENABLED] => yes
    [HTTP_USER_AGENT] => Wget/1.17 (darwin15.0.0)
    [HTTP_ACCEPT] => */*
    [HTTP_ACCEPT_ENCODING] => identity
    [HTTP_HOST] => www.mondomaine.com
    [HTTP_X_CLIENT_IP] => 134.X.X.X
    [HTTP_X_FORWARDED_FOR] => 134.X.X.X
    [HTTP_CONNECTION] => close
    [PATH] => /bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin
    [SERVER_SIGNATURE] =>
    [SERVER_SOFTWARE] => Apache
    [SERVER_NAME] => www.mondomaine.com
    [SERVER_ADDR] => 192.168.1.2
    [SERVER_PORT] => 80
    [REMOTE_ADDR] => 192.168.1.2
    [DOCUMENT_ROOT] => /var/services/web
    [SERVER_ADMIN] => admin
    [SCRIPT_FILENAME] => /var/services/web/test.php
    [REMOTE_PORT] => 40132
    [REDIRECT_URL] => /test.php
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] =>
    [REQUEST_URI] => /test.php
    [SCRIPT_NAME] => /test.php
    [ORIG_SCRIPT_FILENAME] => /php-fpm-handler
    [ORIG_PATH_INFO] => /test.php
    [ORIG_PATH_TRANSLATED] => /var/services/web/test.php
    [ORIG_SCRIPT_NAME] => /php-fpm-handler.fcgi
    [PHP_SELF] => /test.php
    [REQUEST_TIME_FLOAT] => 1450273339.6406
    [REQUEST_TIME] => 1450273339
)

Donc même avec les bonnes options, il me semble que DSM persiste à bloquer autre chose que l'IP indiquée dans les entêtes ajoutées par haproxy ...

Je vais tenter avec le package et voir si le comportement est différent.

Merci de votre aide/commentaire/suggestion !

[gaetan.cambier]

Et oui docker est un reseau nattė je lai dis ...

[Sylar]

Il y a 7 heures , gaetan.cambier a déclaré:

Et oui docker est un reseau nattė je lai dis ...

Bon, en utilisant le paquet, la seule différence avec ce que j'ai indiqué précédemment est ici :

Pour le container docker (pour rappel 192.168.1.2 est l'IP du diskstation sur le réseau local), lancé avec l'option --net="host" :

    [SERVER_ADDR] => 192.168.1.2
    [REMOTE_ADDR] => 192.168.1.2

Pour le paquet :

    [SERVER_ADDR] => 127.0.0.1
    [REMOTE_ADDR] => 127.0.0.1

Mais cette fois, en cas de saisie erronée multiple, c'est bien la bonne adresse IP qui est bloquée : celle du client, et non 192.168.1.2.
Dans les 2 cas, X-FORWARDED-FOR contient bien l'adresse IP du client.

Je comprends bien la différence entre les 3 approches que j'ai testées (docker bridgé + NAT, docker hosté, et paquet "natif"), mais j'avoue ne pas saisir, compte tenu des en-têtes HTTP transmises pour les 2 derniers cas, comment fonctionne le système de blocage des IPs ...
Il y a certainement un truc moche, du type "si SERVER_ADDR différent de 127.0.0.1, alors bloque SERVER_ADDR, sinon bloque X-FORWARDED-FOR".

Modifié le 16 décembre 2015 par Sylar

[devildant]

Bonjour, cela fait un moment que je ne suis pas venu sur le forum :).

Concernant haproxy via docker j'ai mi en place se système il y a plusieurs mois de ça fonction bien avec l'option host.

depuis DSM 5.2 Synology a fait le nécessaire pour que les serveurs frontaux qui font du reverse proxy soient supporté, pour cela il suffi d'ajouter l'ip du serveur frontal dans la liste blanche, en faisant cela DSM bloquera la bonne ip lorsque la limite de connexion est atteinte.

Cependant docker attribue une ip en 172.... en mode nat ou bridge et il n'est pas possible de connaitre cette ip avant de lancer le container (il n'est pas possible actuellement de spécifier une ip au container sauf en bricolant mais je déconseille ce genre de chose sur un syno), c'est pour cela que le mode host fonction car la pile reseau étant partager avec le parent l'ip du container et celle du syno lui même (mais attention au port que vous exposé via le container) c'est pour cela que le processus de blocage se passe convenablement.

 

une solution alternative serai de trouver le fichier qui contient la liste le blanche et le mettre a jour a chaque lancement du container, mais je ne sais pas ou il se trouve( il y a fort a parier qu'il soit en bdd)

il semblerai que dans la version 1.8 de docker il soit possible de spécifier une ip

https://docs.docker.com/v1.8/articles/networking/#docker0

Le 16/12/2015 at 21:58, Sylar a dit :

Il y a certainement un truc moche, du type "si SERVER_ADDR différent de 127.0.0.1, alors bloque SERVER_ADDR, sinon bloque X-FORWARDED-FOR".

sur se point comme je l'ai dit la liste blanche est prise en compte, et dans tout les cas il y aura une condition de ce type 

Le 14/12/2015 at 18:56, gaetan.cambier a dit :

 

Pour moi c'est a cause de docker

En plus mettre un reverse proxy dans un conteneur avec du routage et du nat c'est pas le mieux

Pourquoi ne pas utiliser la paquet haproxy ?

sur ce point ci, je pense que c'est pour la même raison que moi, pouvoir avoir le support synology, a moins qu'il est re changé leurs politique, mais a mon dernier problème je n'ai pas eu d'assistance du moins ce n'est pas aller plus loin que le support français qui ma conseillé de faire un double reset pour ne plus avoir de package tiers et avoir le support complet.

dans le cas contraire je serai resté avec le package haproxy de diaoul, c'est toujours mieux avec une interface ^^

Modifié le 25 décembre 2015 par devildant

[gaetan.cambier]

Le support qui dis de faire un double reset a chaque fois que l'on a des package tier, c'est quand meme leur plus grosse connerie

Pour être honnête l'assistance synology elle sert pas a grand choses

Tu te retrouve avec des imb.... qui te font un copier coller sur le mail des procédure que on leur a donné

Et quand tu leur pose une question un peu technique, ils se plantent en beauté

Je me souvient leur avoir demandé si il existait une solution pour désactiver l'ipv6 dans le dyndns syno tout en gardant le support ipv6 sur le nas.

La réponse a été de désactiver l'ipv6 sur le nas ... pour une réponse pareille, valait mieux rien dire ...

[Sylar]

Je découvre à l'instant vos réponses. Mieux vaut tard que jamais ;)

Pour info, bien que mes premiers tests ne semblaient ne pas concluants, je me suis rendu compte qu'en effet l'option --network=host permettait enfin de faire fonctionner le blocage des IPs correctement.

Le 25 décembre 2015 at 23:36, devildant a dit :

il semblerai que dans la version 1.8 de docker il soit possible de spécifier une ip

https://docs.docker.com/v1.8/articles/networking/#docker0

Mais nous sommes toujours bloqué à la version 1.6, qui commence à dater vu l'activité des développeurs de docker. J'espère que Synology mettra à jour le paquet bientôt (peut être à l'occasion du DSM 6 ?)