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...

 

Euh.. j'ai ca dans les logs, ca parle a qqun?

Citation

account admin has password changed in future

 

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...

Apparemment, je ne suis pas le seul :

https://forum.synology.com/enu/viewtopic.php?f=19&t=116384&p=435967#p435967

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...

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.

Petit ajout : y'a pas que ipkg qui empeche VPNCenter de fonctionner.

Y'a SABnzbd aussi... :-/

 

Il y a 3 heures, lndiana a dit :

Et comme Fenrir semblait y tenir aussi... :)

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...

 

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

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...

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à.

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.

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. :)

Bonne nouvelle, je serais aussi curieux de connaitre le détail

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.

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...

 

c'est une bonne explication, merci pour le retour