lndiana Posté(e) le 20 mai 2016 Auteur Partager Posté(e) le 20 mai 2016 ok, mais ipkg etait installé sur DSM5, je n'ai rien touché dessus. J'ai juste essayé de le reactiver une fois en DSM6 en remettant les /opt/sbin et bin dans le PATH. Mais comme ca avait fait merdé sudo, je l'ai desactivé. Je vois pas comment ca aurait pu remplacer des libs syno.. Je n'ai pas de client ipsec pour le moment, mais je vais essayer... J'ai deja cherché dans tout ces logs... et j'ai lancé des tails dessus pendant l'install et la desinstall, sans succes... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 20 mai 2016 Auteur Partager Posté(e) le 20 mai 2016 Euh.. j'ai ca dans les logs, ca parle a qqun? Citation account admin has password changed in future 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 20 mai 2016 Auteur Partager Posté(e) le 20 mai 2016 Pas mieux avec les autres VPN : Citation May 20 22:35:49 SuperBoite pluto[8552]: packet from 192.168.1.24:500: received Vendor ID payload [XAUTH] May 20 22:35:49 SuperBoite pluto[8552]: packet from 192.168.1.24:500: received Vendor ID payload [Cisco-Unity] May 20 22:35:49 SuperBoite pluto[8552]: packet from 192.168.1.24:500: ignoring Vendor ID payload [FRAGMENTATION 80000000] May 20 22:35:49 SuperBoite pluto[8552]: packet from 192.168.1.24:500: received Vendor ID payload [Dead Peer Detection] May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: responding to Main Mode from unknown peer 192.168.1.24 May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD May 20 22:35:49 SuperBoite pluto: SYSTEM: Last message '"L2TP-PSK-NAT"[8] 19' repeated 12 times, suppressed by syslog-ng on SuperBoite May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM May 20 22:35:49 SuperBoite pluto: SYSTEM: Last message '"L2TP-PSK-NAT"[8] 19' repeated 1 times, suppressed by syslog-ng on SuperBoite May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: no acceptable Oakley Transform May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: sending notification NO_PROPOSAL_CHOSEN to 192.168.1.24:500 May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24 #8: deleting state #8 (STATE_MAIN_R0) May 20 22:35:49 SuperBoite pluto[8552]: "L2TP-PSK-NAT"[8] 192.168.1.24: deleting connection "L2TP-PSK-NAT" [whackfd=4294967295] instance with peer 192.168.1.24 {isakmp=#0/ipsec=#0} Citation May 20 22:39:15 SuperBoite synobackup: (17144) [debug] proc/subprocess.cpp:247 launch command: May 20 22:39:15 SuperBoite synobackup: (17144) [debug] proc/subprocess.cpp:250 arg[0] = [/var/packages/HyperBackup/target/bin/dsmbackup] May 20 22:39:15 SuperBoite synobackup: (17144) [debug] proc/subprocess.cpp:250 arg[1] = [--running-on-dev] May 20 22:39:15 SuperBoite synobackup: (17144) [debug] proc/subprocess.cpp:250 arg[2] = [sdg1] May 20 22:39:15 SuperBoite dsmbackup: (17144) [debug] command_client.cpp:63 connect to [/var/run/synobackupd.socket] May 20 22:39:15 SuperBoite accel-pppd: :: radius: server(1) not responding May 20 22:39:15 SuperBoite accel-pppd: :: radius: no available servers May 20 22:39:15 SuperBoite accel-pppd: :franck: franck: authentication failed May 20 22:39:15 SuperBoite accel-pppd: franck: authentication failed May 20 22:39:15 SuperBoite accel-pppd: :: disconnected May 20 22:39:28 SuperBoite synoscgi_SYNO.Core.SyslogClient.Status_1_latestlog_get[17207]: SYNO.Core.SyslogClient.Status.cpp:419 Bad Log format szLevel: J'ai bien un probleme de serveur radius... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 20 mai 2016 Auteur Partager Posté(e) le 20 mai 2016 Apparemment, je ne suis pas le seul : https://forum.synology.com/enu/viewtopic.php?f=19&t=116384&p=435967#p435967 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 23 mai 2016 Auteur Partager Posté(e) le 23 mai 2016 Ok. Mais dans ce cas-la, ce seraient des libs remplacée AVANT la mise à jour DSM6, et qui ne poseraient problème qu'APRES la MAJ en DSM6 et MAJ de VPNCenter... (Parce que je n'ai pas retouché a ipkg depuis...) J'ai essayé avec IPSec et L2TP : pareil. probleme de droits... Je sèche... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 23 mai 2016 Auteur Partager Posté(e) le 23 mai 2016 YESS!! Trouvé. (Enfin...) Le support Syno a continué d'investigué sur le problème (après grande insistance de ma part...), m'as fait désinstallé sslh et sab (soit), puis m'a demandé de désinstallé OptWare. Et en lui disant que Opt n'était plus dans le PATH, je me suis rendu compte qu'il y avait quand même encore le montage dans /etc/rc.local Et comme Fenrir semblait y tenir aussi... :) Je viens de commenter et rebooter, et le package VPN refonctionne bien. Merci à vous. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 23 mai 2016 Auteur Partager Posté(e) le 23 mai 2016 Petit ajout : y'a pas que ipkg qui empeche VPNCenter de fonctionner. Y'a SABnzbd aussi... :-/ 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 23 mai 2016 Partager Posté(e) le 23 mai 2016 Il y a 3 heures, lndiana a dit : Et comme Fenrir semblait y tenir aussi... :) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 23 mai 2016 Auteur Partager Posté(e) le 23 mai 2016 Y'aurait pas un probleme avec OpenSSL? Parce que même quand je lance sab depuis un container docker, ca fout la grouille avec VPNCenter... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 23 mai 2016 Partager Posté(e) le 23 mai 2016 il y a 16 minutes, lndiana a dit : Y'aurait pas un probleme avec OpenSSL? Parce que même quand je lance sab depuis un container docker, ca fout la grouille avec VPNCenter... Si tu utilises un conteneur, je ne vois pas de lien avec OpenSSL (le conteneur a sa propre version) et il ne devrait pas interagir avec OpenVPN. Avec un syno non modifié (aucune action effectuée en shell et aucun paquet tiers installé) Si le soucis apparait au lancement de n'importe quel conteneur (un conteneur debian de base par exemple) => c'est un bug Si le soucis apparait quand l'appli SABnzbd démarre => c'est que ton conteneur a trop de droits Avec un syno modifié ou avec des paquets tiers Tout est possible 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 23 mai 2016 Auteur Partager Posté(e) le 23 mai 2016 Je crois que je progresse : si je demarre sab vers package ou version container docker : ca plante le VPN Si je demarre un autre container avec un acces https (donc avec ssl) : ca plante le VPN du syno Si je desactive tout les containers : ca remarche. Et a la seconde ou un des serveur web (probablement incluant ssl, mais je ne m'en sers qu'en http) d'un des containers "avec privileges elevés" se lance : ca plante le VPN du syno! Et je n'ai pas le choix pour un d'entres eux, j'ai besoin des privileges elevés pour lire les ports usb... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 23 mai 2016 Partager Posté(e) le 23 mai 2016 Il y a 1 heure, lndiana a dit : si je demarre sab vers package ou version container docker : ca plante le VPN Regarde dans les différents logs ce qu'il se passe à ce moment-là. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 24 mai 2016 Auteur Partager Posté(e) le 24 mai 2016 Il y a 9 heures, Fenrir a dit : Regarde dans les différents logs ce qu'il se passe à ce moment-là. Rien, malheureusement... :( syslog, messages, auth et dmesg. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 26 mai 2016 Auteur Partager Posté(e) le 26 mai 2016 Hello, Petit retour sur mon probleme. Finalement, après plus d'une semaine d'investigation du support Synology de Taiwan et plus de 5 session d'acces a distance, ils ont fini par corrigé le probleme. Bon, leur explications ne sont pas très clair : je vais essayé d'en savoir plus sur la correction. Mais il y avait clairement un problème entre le package VPNServer et le serveur web (nginx) de jeedom hébergé dans un container Docker o_O Franchements, même si ils ont complètement planté le nas ce matin (et ma domotique avec, mais un soft reboot a tout réglé), ils ont assuré. Et leur persévérance fait plaisir. :) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 26 mai 2016 Partager Posté(e) le 26 mai 2016 Bonne nouvelle, je serais aussi curieux de connaitre le détail 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 26 mai 2016 Auteur Partager Posté(e) le 26 mai 2016 Pas autant que moi. Même si ca n'expliquera pas pourquoi ni comment ils ont fait pour planter le nas au point qu'il ne soit plus accessible du tout, même du LAN. Mais que jeedom, même inaccessible, tournait encore. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
lndiana Posté(e) le 28 mai 2016 Auteur Partager Posté(e) le 28 mai 2016 Hello, Bon, finalement, ils n'ont rien fait, mais chez eux ca marche (apparemment..) Mais de mon coté, j'ai réglé le problème en n'ouvrant plus le port 2001 sur mon container docker pour jeedom. Je l'ai remplacé par 20001 et VPN refonctionne... Le port 2001 est apparemment utilisé par PPTP, que je n'utilise pas, mais ca empeche le package de s'ouvrir, et de se desinstaller... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 28 mai 2016 Partager Posté(e) le 28 mai 2016 c'est une bonne explication, merci pour le retour 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.