bud77 Posté(e) le 19 avril 2012 Auteur Partager Posté(e) le 19 avril 2012 Bon, j'ai a moitié résolu mon pb de certif, grace à ce post :http://code.google.com/p/shellinabox/issues/detail?id=59 J'ai donc regénéré, et je peux maintenant me connecter en httpS sur le 4200, Mais la redirection marche plus sur le /shell , (j'ai pas touché au vhost) et marche si je désactive le SSL ... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PatrickH Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 C'est vrai que c'est sympatique d'avoir un shell dans un environnement DSM. Personnellement je préfère une approche VPN qui me permet d'accéder à toutes mes ressources réseau depuis l'extérieur et j'utilise les outils natifs de l'autre coté. C'est à mon avis beaucoup plus transparent et plus facile à mettre en oeuvre! non ? Patrick 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) Bon, j'ai a moitié résolu mon pb de certif, grace à ce post :http://code.google.c...es/detail?id=59 J'ai donc regénéré, et je peux maintenant me connecter en httpS sur le 4200, Mais la redirection marche plus sur le /shell , (j'ai pas touché au vhost) et marche si je désactive le SSL ... Quelle tache que je suis: je viens de m'apercevoir que j'avais laissé ssl désactivé pour mes tests! Et d'ailleurs en fait, avec le proxy on peut rester comme cela. Lorsque l'on se connecte en https avec l'url "https://<adddresse syno>/shell", le traffic entre le monde extérieur et le syno est bien crypté SSL. Ce n'est que le traffic local (sur localhost) qui est en clair donc pas vraiment de probleme. J'ai pu vérifier tout ca avec une capture de packet (tcpdump) C'est vrai que c'est sympatique d'avoir un shell dans un environnement DSM. Personnellement je préfère une approche VPN qui me permet d'accéder à toutes mes ressources réseau depuis l'extérieur et j'utilise les outils natifs de l'autre coté. C'est à mon avis beaucoup plus transparent et plus facile à mettre en oeuvre! non ? A mon avis c'est complémentaire, par exemple avec le shell dans le navigateur je pourrais me connecter de mon taf en shell sur mon syno (sous réserve d'avoir ajouté la ligne "allow from" qui va bien), alors que le VPN est hors de question, n'étant pas admin sur mon PC pro. [edit] et en VPN difficile de faire un /usr/syno/etc/rc.d/<service>.sh restart par exemple. [edit#2] de toutes façons admin ou pas, derrière un proxy, le VPN, hein .... Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PatrickH Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 A mon avis c'est complémentaire, par exemple avec le shell dans le navigateur je pourrais me connecter de mon taf en shell sur mon syno (sous réserve d'avoir ajouté la ligne "allow from" qui va bien), alors que le VPN est hors de question, n'étant pas admin sur mon PC pro. Je suis d'accord avec toi qu'il faut installer un client sur le PC... [edit] et en VPN difficile de faire un /usr/syno/etc/rc.d/<service>.sh restart par exemple. Si le VPN est fait sur le routeur je ne vois pas où est le problème ! [edit#2] de toutes façons admin ou pas, derrière un proxy, le VPN, hein .... Mon VPN passe parfaitement le proxy ! Patrick 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 Quelle tache que je suis: je viens de m'apercevoir que j'avais laissé ssl désactivé pour mes tests! Et d'ailleurs en fait, avec le proxy on peut rester comme cela. Lorsque l'on se connecte en https avec l'url "https://<adddresse syno>/shell", le traffic entre le monde extérieur et le syno est bien crypté SSL. Ce n'est que le traffic local (sur localhost) qui est en clair donc pas vraiment de probleme. J'ai pu vérifier tout ca avec une capture de packet (tcpdump) Mon souci c'est que justement, "httpS://..../shell" fonctionne pas et "httpS://IP:4200" fonctionne J'ai tenté d'activer les logs apache, mais rien d'anormal dedans 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 Mon souci c'est que justement, "httpS://..../shell" fonctionne pas et "httpS://IP:4200" fonctionne J'ai tenté d'activer les logs apache, mais rien d'anormal dedans C'est que la config proxy n'est pas prise en compte: Le fichier contenant les lignes: <Location /siab> ProxyPass http://localhost:4200 Order deny,allow deny from all allow from etc ... </Location> Doit être inclus directement ou indirectement par un des fichiers de conf apache. Pour ma part, à la fin de "/usr/syno/apache/conf/httpd.conf-user" j'ai ajouté une ligne "#include" du fichier ci dessus. Suffit de relancer apache pour que cela soit pris en compte: /usr/syno/etc/rc.d/S97apache-user.sh restart 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 J'ai mis ce Location dans le fichier apache-user directement (Ainsi que les if module) Je vais faire un fichier de conf a part et faire l'include alors Par contre, petite question sur le "allow from" : Vu que SIAB ne sera lancé en localhost-only , j'ai pas besoin de spécifier de deny / allow du coup ? (je voulais le limiter en "allow from localhost") 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) Mon VPN passe parfaitement le proxy ! Je ne bénéficie pas de cette fonctionnalité : notre proxy est configuré pour supporter uniquement HTTP et FTP (et encore de façon limitée). En outre, comme je ne suis pas admin réseau à ma boite, la config du proxy ne dépend pas de moi (et même si c'était le cas nous avons des règles de sécurité qui m'empècheraient de faire tout ce que l'on veux). Cela dit, va falloir que je vérifie aussi que shellinabox fonctionne à travers notre proxy (qui n'est pas de la première jeunesse en outre) J'ai mis ce Location dans le fichier apache-user directement (Ainsi que les if module) Je vais faire un fichier de conf a part et faire l'include alors Dans ce cas, ça ne devrait pas faire de différence, le probleme est ailleurs alors. Tu as bien relancé apache au moins? Par contre, petite question sur le "allow from" : Vu que SIAB ne sera lancé en localhost-only , j'ai pas besoin de spécifier de deny / allow du coup ? (je voulais le limiter en "allow from localhost") Ah non pas du tout, la restriction d'ip se fait *en amont* du proxy, c'est l'ip externe qui est validée [edit] je pense a un truc d'un coup: suivant comment ta box fait les redirections de port, lorsque tu te connectes sur place en utilisant l'ip externe il est possible que ca coince. Dans le cas d'une freebox, ça fonctionne et la connexion va sembler provenir de la freebox (a prendre en compte dans le "allow from" Essaie pour voir avec l'ip *interne* du syno: https://<ip_interne>/shell Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 Tout mes tests sont pour l'instant fait qu'en réseau local (je procède par étapes ) Du coup, je n'ai tenté que avec httpS://ip.local/shell (si je tente en http, il me redirige vers le httpS puis erreur) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) Tout mes tests sont pour l'instant fait qu'en réseau local (je procède par étapes ) Du coup, je n'ai tenté que avec httpS://ip.local/shell (si je tente en http, il me redirige vers le httpS puis erreur) As-tu bien activé le ssl sur webstation? (panneau de configuration->services web->service http->activer https?) Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 As-tu bien activé le ssl sur webstation? (panneau de configuration->services web->service http->activer https?) Bien vu !!!! Et je vais te dire le pire : je n'avais pas activé web station jusqu'à ce matin (donc après mes tests) et çà fonctionnait (a moitié, certes) Le vhost marche beaucoup mieux maintenant (local et externe) Par contre, le proxy du boulot ne veux rien savoir : Je pointe mon navigateur sur http://mon.dyndns/shell la redirection se passe bien vers le httpS, puis "SSL connection error" (La même manip depuis mon tel en 3G fonctionne) Autre question, plus ou moins lié : Comment avoir l'interface DSM sur le port (au lieu de la redir vers le 5000) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Nounours44 Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 salut bud, je travaille effectivement sur une idée similaire mais sur la base de gateone. L'idée est de pouvoir ouvrir un shell dans le DSM depuis un navigateur du travail ; seuls les ports (HTTP) et 443 (HTTPS) sont ouverts. Pour éviter de voir passer des identifiants en clair, il est primordial d'accéder au DSM en HTTPS. Voici l'architecture que j'imagine (et qui fonctionne à quelques détails prêts) : - depuis le navigateur du travail, je me connecte à https://dsm.domaine.synology.me/ - le flux arrive sur mon routeur ADSL à la maison - le port 443 est redirigé vers le port 30443 géré par haproxy (reverse proxy qui travail sur le nom du serveur appelé pour rediriger vers le bon service à l'intérieur de mon réseau) - haproxy reconnaît dsm.domaine.synology.me dans l'adresse appelée. il redirige vers mon syno, sur le port 5001 - le DSM apparaît en retour sur le navigateur de mon travail - dans le DSM, demande d'ouverture de gateone sur l'url https://gateone.domaine.synology.me/ - même natage vers haproxy sur mon routeur - haproxy reconnaît gateone.domaine.synology.me comme nom du serveur appelé, il redirige la requête vers le port 20443 qui correspond à gateone - gateone apparaît en retour dans le navigateur du travail Cela fonctionne grâce aux principes suivants, pré-requis indispensables : - routage de l'ensemble des requêtes HTTPS vers haproxy, c'est cet outil qui a la charge de ventiler les requêtes vers le bon serveur TCP - haproxy reconnaît sans problème le sni dans le flux HTTPS, ce qui lui permet d'orienter les requêtes en fonction du nom du serveur appelé (l'URL après le nom du serveur est chiffrée en HTTPS, on ne peut donc pas se baser sur cela) - haproxy gère très bien les websockets, indispensable pour un bon fonctionnement de gateone qui fonctionne en HTML5 A noter que cette architecture permet également d'ouvrir un flux ssh au travers de haproxy, il suffit alors à haproxy de rediriger sur le port 22 du syno dans le cas où le protocole d'appel n'est pas du HTTPS. Maintenant les bonnes nouvelles : haproxy et gateone devraient pouvoir être proposés sur le repo SynoCommunity, le temps de faire tout cela proprement... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 Merci pour l'info Nours ! Diaoul m'avait bien prévenu, mais je me disais, vu que tu avais l'air plutôt occupé, j'aurais ptet réussi à faire marcher tout çà (SIAB) avant que tu ai fini le package A voir tout ce que je dois encore réaliser pour arriver à mes fins (ce que ton package gère directement) ben j'en ai encore pour 1 mois XD En attendant le package, je vais quand même essayer de trouver (et d'apprendre surtout) pour ma culture personnelle 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 En attendant, j'ai réussi l'intégration dans le DSM Bien évidemment, tout marche qu'en local pour l'instant 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) Comment avoir l'interface DSM sur le port (au lieu de la redir vers le 5000) virtualhost! (cf le tuto de PatrickH) Dans le fichier ou tu as defini le block "location" pour SIAB (ou un autre si tu veux), tu met ceci: (remplacer dans la suite "MONDOMAINE" par le nom DNS externe, par exemple: "monnasamoi.myds.me" si enregistré ainsi en dynamique chez synology) #+ # Les "loadmodules" semblent faire double emploi avec ceux de la conf SIAB # mais on s'en br^h^hfout grase au IfModule #- <IfModule !proxy_module> LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so </IfModule> NameVirtualHost *: <VirtualHost *:> ServerName webman.MONDOMAINE ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> # # SSL # NameVirtualHost *:443 <VirtualHost *:443> ServerName webman.MONDOMAINE SSLCipherSuite HIGH:MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key SSLEngine on SSLProxyEngine on ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / https://localhost:5001/ ProxyPassReverse / https://localhost:5001/ </VirtualHost> Et voila, tu peux te connecter maintenant sur l'interface DSM avec l'url http://webman.MONDOMAINE et https://webman.MONDOMAINE en ssl. PS: en général faire comme ici des virtualhosts basés sur le nom en SSL n'est pas préconisé. Si tu veux gérer strictement le certificat de site ça va poser des problemes. Mais si l'objectif est uniquement de chiffrer le traffic c'est suffisant. Bien entendu on peut choisir ce qu'on veut comme nom de sous-domaine à la place de "webman". Il est possible de procéder de façon similaire pour filestation, downloadstation, audiostation. Cela dit, en installant haproxy je pense que l'on pourra se passer du proxy apache, ce qui rend tout cela obsolète. A suivre donc Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Nounours44 Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 Attention, depuis DSM 4.0, paramétrer des vhosts en reverseproxy casse les sauvegardes rsync. En plus, le fait de bricoler des fichiers de configuration du DSM pour induire des effets de bords non maîtrisés lors d'un changement d'une mise à jour du système. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 J'étais justement en train de regarder ce tuto sur le site de PH, mais il indique en prérequis "nom de domaine" Moi, je n'ai qu'un domaine dynamique (dyndns.org) Attention, depuis DSM 4.0, paramétrer des vhosts en reverseproxy casse les sauvegardes rsync. En plus, le fait de bricoler des fichiers de configuration du DSM pour induire des effets de bords non maîtrisés lors d'un changement d'une mise à jour du système. J'en suis pleinement conscient, et je suis encore en 3.2 au moins jusqu'a la sortie de la 4.1 Dans tout les cas, je conserver toujours les originaux de mes fichiers, au cas ou ^^ 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 Attention, depuis DSM 4.0, paramétrer des vhosts en reverseproxy casse les sauvegardes rsync. Savais pas, Suis étonné en plus: comment les sauvegardes rsync peuvent dépendre de conf apache ? En plus, le fait de bricoler des fichiers de configuration du DSM pour induire des effets de bords non maîtrisés lors d'un changement d'une mise à jour du système. Oh, Il s'agit d'une toute petite modif de rien du tout: ajout d'une simple ligne dans "/usr/syno/apache/conf/httpd.conf-user": include <dossier perso dans /volume1/conf.d/*.conf[/CODE] Si la MAJ écrase la modif, suffit de la rajouter. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 J'étais justement en train de regarder ce tuto sur le site de PH, mais il indique en prérequis "nom de domaine" Moi, je n'ai qu'un domaine dynamique (dyndns.org) Etant donné que ça marche avec les nom de domaines dynamiques fourni par syno ("myds.me" par exemple). Pas de raison que ce soit différent avec dyndns. je viens de vérifier: 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Nounours44 Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 Savais pas, Suis étonné en plus: comment les sauvegardes rsync peuvent dépendre de conf apache ? Oh, Il s'agit d'une toute petite modif de rien du tout: ajout d'une simple ligne dans "/usr/syno/apache/conf/httpd.conf-user": include <dossier perso dans /volume1/conf.d/*.conf[/CODE] Si la MAJ écrase la modif, suffit de la rajouter. regarde là : 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) regarde là : http://www.nas-forum...o-apres-dsm-40/ Bien sur que je connais: j'ai posté dans ce fil! (et dans un autre auquel il fait référence) En effet, depuis la DSM 4, il fait éviter de trifouiller les fichiers /usr/syno/etc/httpd-ssl-vhost.conf-user et /usr/syno/etc/httpd-vhost.conf-user c'est pourquoi depuis je préconise de se contenter du "include" dans "/usr/syno/apache/conf/httpd.conf-user" Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 Bon, j'ai utilisé tes préconisations Raoul J'ai donc crée un /volume1/apache.conf/ et j'y dépose mes différents fichiers, et j'ai juste rajouté un Include dans le apache user (en retirant ce que j'ai mis hier) J'ai donc 2 fichiers, 1 pour la location /shell, et 1 pour le vhost Dans ce fichier de vhost, j'ai donc modifié le ServerName pour y mettre "dsm.domaine.dyndns.org" (en et 443) J'ai relancé l'apache, et là ... L'url http://dsm.domaine.dyndns.org n'existe pas , mais par contre, l'url http://domaine.dyndns.org me renvoi bien sur la page de login ... Bon, çà me dérange pas, mais je comprends pas trop pourquoi (J'ai pas pu tester le 443 car je ne l'ai pas encore ouvert sur ma bobox) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 (modifié) L'url http://dsm.domaine.dyndns.org n'existe pas , mais par contre, l'url http://domaine.dyndns.org me renvoi bien sur la page de login ... Bon, çà me dérange pas, mais je comprends pas trop pourquoi (J'ai pas pu tester le 443 car je ne l'ai pas encore ouvert sur ma bobox) Essaie la commande "nslookup dsm.domaine.dyndns.org" (ou n'importe quoi a la place de "dsm") si ca ne te donne pas ton ip externe, c'est que dyndns ne gère pas le "catchall" pour les sous domaines, ce qui est bien ennuyeux pour toi. Avec myds.me, une fois que l'on a enregistré son nom (monsyno.myds.me) *toutes* les requetes en <nimportequoi>.monsyno.myds.me sont résolues avec l'ip de base. On dispose donc d'un nombre de sous domaines infini. Modifié le 20 avril 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bud77 Posté(e) le 20 avril 2012 Auteur Partager Posté(e) le 20 avril 2012 Essaie la commande "nslookup dsm.domaine.dyndns.org" (ou n'importe quoi a la place de "dsm") si ca ne te donne pas ton ip externe, c'est que dyndns ne gère pas le "catchall" pour les sous domaines, ce qui est bien ennuyeux pour toi. C'est bien çà, pas de "catchall" pour moi 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 20 avril 2012 Partager Posté(e) le 20 avril 2012 C'est bien çà, pas de "catchall" pour moi Tu peux peut-etre basculer la gestion DDNS du syno vers synology tout en conservant ton nom chez dyndns. Si tu a en plus une IP fixe, pas besoin d'avoir de mise a jour auto chez dyndns et tu beneficiera des deux noms (.dyndns.org et .myds.me) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.