Aller au contenu

darkneo

Membres
  • Compteur de contenus

    108
  • Inscription

  • Dernière visite

  • Jours gagnés

    2

darkneo a gagné pour la dernière fois le 4 novembre 2022

darkneo a eu le contenu le plus aimé !

À propos de darkneo

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

darkneo's Achievements

Contributor

Contributor (5/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done

Recent Badges

3

Réputation sur la communauté

  1. Suite au message de @Mic13710 sur un autre thread, j'ai finalement abandonné l'idée de remettre mon OpenVPN d'équerre avec mon certificat LE. J'ai donc : - Désactivé OpenVPN sur DSM - Généré un nouveau certificat autosigné avec Easy RSA - copié les fichier dans /volume1/... et modifié le .ovpn serveur pour lui indiquer les chemins des fichiers (je sais clairement pas si ca a servi a qqc) - Importé dans les certificat DSM (ca.crt, private key server et crt serveur) puis configurer VPN server pour utiliser ce nouveau certificat - Réactivé OpenVPN dans DSM Et hop, tout refonctionne (en ayant bien sur updaté la partie cliente pour utiliser les crt et key configuré pour le client). Je vous poste un lien qui m'a beaucoup orienté (car j'ai adapté quelques trucs mais les grandes lignes sont OK): https://tavenier.org/synology-nas-with-openvpn-with-client-certificate/
  2. Je pense que c'est ce que je vais faire, car je trouve en plus pas mal de forum (en anglais) qui semblent dire que les certificats LE sont incompatibles avec certaines fonctionnalités d'OpenVPN (j'ai pas tout bien compris...). Concernant l'édit du fichier de conf, le "problème" c'est que je n'ai pas les fichiers CRT, PEM, et KEY... Donc il faudrait que je les génère... Donc autant tout refaire au propre avec un autosigné via easy RSA, ce qui me permettra en plus de pouvoir faire des clés pour chaque client que je veux utiliser! Merci pour l'info 👍
  3. Hello à tous! Je viens poster ici car je pense qu'être passé sur la version Docker depuis l'ancien script basique a mis la pagaille dans ma config OpenVPN. J'ai posté un thread dédié ici: Pour faire court, j'ai l'impression qu'OpenVPN utilise encore l'ancienne version de mon certificat (qui a expiré) et j'aimerai m'assurer de pouvoir demander l'utilisation du nouveau certificat (mais du coup quels fichier utiliser?). Merci d'avance pour votre aide EDIT: A priori c'est confirmé, même en changeant le certificat dans l'interface Admin, le paquet VPN Server ne semble pas se mettre a jour correctement: https://serverfault.com/questions/1117955/how-to-use-public-certificates-with-openvpn-on-synology-dsm Du coup, obligé de passer par un easy RSA? ou de complètement désinstaller VPN Server pour le remettre?
  4. Hello! Personne n'aurait une idée? Car je continue d'essayer de résoudre le problème et je tiens peut etre une piste... Ce soucis est apparu quand j'utilisais l'ancien script de renouvellement ACME (en local sur le syno). Suite aux différentes évolutions de Let's Encrypt, je suis passé sur la version docker d'Acme pour le renouvellement du certificat. Et je me dis que le soucis vient très certaintement de là! Dans la config serveur l'openvpn, il utilise les fihciers suivants: dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key Sauf que je pense que ces fichiers sont ceux de l'ancien script Acme. Avec la version docker, les fichiers se trouvent dans /volume1/docker/Acme/DOMAIN Je suis pas sur de mon coup, et je vois pas du tout comment avancer maintenant... Car dans ce dossier (/volume1/docker/Acme/DOMAIN), je n'ai ni fichier crt, ni fichier key, je n'ai que des csr: Une idée de commencer remplacer les certificat sur le serveur par ceux du docker Acme?
  5. Hello à tous, Pour bien commencer l'année, je me prends la tête avec ma configuration VPN qui ne fonctionne plus... 😞 J'ai eu des soucis (voir sur un autre post) avec les certificats Let's Encrypt, donc j'ai tout refait, et tout reconfiguré (d'ailleurs pour info, ma demande de merge a été acceptée, donc le soucis LE pour le deploiement auto devrait être corrigé sous peu). Sauf que, depuis que j'ai mon nouveau certificat... Mon client VPN ne fonctionne plus 🤪 J'ai l'erreur suivante: Ce que j'ai tenté: - de base: export de la config VPN Server dans le zip, extraction, modification du fichier .ovpn pour y mettre mon DNS, même erreur - ajout des balises <cert> et <key> dans le fichier .ovpn, toujours la même erreur - comparaison du contenu de la balise <ca> avec mon chain.pem: il y a un bloc de plus dans le fichier .ovpn, mais si je le supprime, l'erreur change en me disant qu'il n'arrive pas à identifier le signataire du certificat Ce que j'ai vérifié: - le port est correctement ouvert dans le routeur. - J'ai vérifié le numéro de série du ca.cert, ce n'est pas le même que celui de l'erreur🤨 l'erreur me dit serial=1234567890 alors que dans le certificat j'ai un format hex (je pense, ca ressemble à un truc du genre 00912b09ef2394c) J'ai aussi essayé de récupérer directement les certificats depuis le dossier de mon docker via file station, même erreur... Autre point etrange: dans l'application VPN serveur, les connections sont bien affichées dans "Liste de connexion" avec mon ip, mais j'ai autant de session que mon paramètre max (5 en l'occurence) avec utilisateur à UNDEF Une idée de l'origine de ce blocage (je pense problème de certificat, mais pourquoi? et comment le changer?!) Merci d'avance pour votre aide! EDIT: J'ai oublié de préciser que les certificats téléchargés depuis l'app VPN server sont valides jusqu'en Sept 2025 (ca.crt et ca_bundle.crt) Par contre j'ai aussi l'impression que ce n'est pas le bon certificat qu'OpenVPN utilise, vu qu'il m'affiche ISRG Root X1 dans le certificat, alors que dans les logs il semble parler de DST Root CA X3.... c'est normal?
  6. Pas tout à fait... Le Device ID (dans la version actuelle) est récupéré dans une réponse HTML (ligne 138 du code actuel) response=$(_get "$_base_url/webapi/$api_path?api=SYNO.API.Auth&version=$api_version&method=login&format=sid&account=$encoded_username&passwd=$encoded_password&otp_code=$otp_code&enable_syno_token=yes&enable_device_token=yes&device_name=$SYNO_Device_Name") Or, dans ma réponse, je n'ai pas de champ 'did' ou 'device_id', donc la variable reste systématiquement vide... (soit dit en passant, en plus, elle est totalement inutile car elle n'est pas nécessaire dans les HTML suivantes!) id_property='device_id' [ "${api_version}" -gt '6' ] || id_property='did' SYNO_Device_ID=$(echo "$response" | grep "$id_property" | sed -n 's/.*"'$id_property'" *: *"\([^"]*\).*/\1/p') _secure_debug2 SYNO_Device_ID "$SYNO_Device_ID"
  7. Très certainement... Car en Septembre mon renew c'était fait sans soucis, et celui de Décembre était fail (et évidemment j'avais désactivé les notifications, donc je m'en suis aperçu car plus aucune service VPN, remote DSM etc ne fonctionnait). J'ai fait les propositions de modif dans le Github, on verra si elles sont acceptées, car pour le logout sur DSM 6, il faut utiliser auth.cgi (et non entry.cgi), et j'ai aussi rajouté le SID pour ne tuer que la connection initiée pour le renouvellement du certificat, ce qui me donne: [Fri Dec 22 13:57:37 UTC 2023] url='http://1.1.1.1:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=logout&_sid=4oM5l6ohX206YB3J4N01003' [Fri Dec 22 13:57:37 UTC 2023] timeout= [Fri Dec 22 13:57:37 UTC 2023] curl exists=0 [Fri Dec 22 13:57:37 UTC 2023] mktemp exists=0 [Fri Dec 22 13:57:38 UTC 2023] wget exists=0 [Fri Dec 22 13:57:38 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L --trace-ascii /tmp/tmp.iuYADzae9v -g ' [Fri Dec 22 13:57:38 UTC 2023] ret='0' [Fri Dec 22 13:57:38 UTC 2023] response='{"success":true}' [Fri Dec 22 13:57:38 UTC 2023] Success En attendant, j'ai aussi passé l'autoupdate à 0 pour éviter toute prochaine déconvenue tant que la modification n'est pas acceptée/commitée. Et pour info, sans forcément passer par un SSH distant, depuis DSM, on peut aller dans l'interface du container pour lancer une commande custom, taper /bin/sh, ce qui ouvre un terminal directement dans le container (/bin/bash ne fonctionne pas car non installé dans le container).
  8. Oui pas faux, mais entre mon NDD, les login/pwd et les ip parfois publiques... Bref.... Et non, je n'ai pas activé l'OTP sur mon NAS, mais a force de debug (et de recontruction d'URL), c'est la requpete qui est censée me retourner le Device ID qui ne le fait pas (dans la réponse, il n'y a pas le champ attendu). Certainement car je suis encore sur la version 6 de DSM (pour raison purement domotique, la version 7 et + ayant supprimer des drivers USB pour le RFXCom par exemple). EDIT: Je vais essayer de tester de plusieurs façon... Mais est ce que je peux techniquement changer un fichier dans un container sans passer par SSH... Car j'avoue ne jamais l'avoir fait (et je n'i qu'un accès remote à mon NAS, le remote SSH n'étant pas activé). EDIT2: Mon premier test a finalement été le bon.. Et le plus simple! J'ai rajouté un paramètre SAVED_SYNO_Device_ID dans le fichier de conf, et tout s'est déroulé... Presque sans encombre! A la fin, j'ai la fonction de logout qui ne fonctionne pas et me retourne un code 102... Je suppose que ce n'est pas aussi simple en DSM 6, il va falloir que je creuse
  9. J'ai mis localhost pour obfusquer les logs (c'est vrai que j'aurai pu mettre autre chose...) mais en vrai j'ai bien la bonne ip... Pour preuve le SessionID et le Syno Token sont bien renseignés (avec localhost, ils auraient été vides 😉 ) J'ai report sur Github le soucis qui, je pense, est du à un mauvais if: if [ -z "$SYNO_DID" ] && [ -z "$SYNO_Device_ID" ] || [ -z "$sid" ] || [ -z "$token" ]; then Dans mon cas SYNO_DID et SYNO_Device_ID sont tous les 2 vides, vu que je n'utilise pas le 2 authentication factor, donc je rentre toujours dans cette loop.... car la requete ligne 138 ne me retourne jamais de Device ID.... 😞
  10. Hello a tous, Ayant (encore) des problèmes avec mon renewal, j'ai décidé de franchir le pas de la version docker.. Mais je me retrouve avec exactement le même soucis: Impossible de se logguer pour enregistrer les certificats dans la dernière étape... Quand je lance la commande j'ai l'erreur: Le user n'a pas de Two factor authentication.... Et j'ai exactement la même erreur avec mon ancien script acme-renew.py.... Des hooks ont été changés pour le prendre que le two factor authent? Edit: En regardant un peu plus les logs... C'est étrange car il me trouve pourtant bien les sessionID & Compagnie, mais me dit qu'il n'arrive pas d'authentifier..... :0
  11. Hello et merci pour le retour, Je viens de vérifier et cette option n'est pas activée... Donc ce n'est pas ça. malheureusement... Pour un peu plus de détail, dans la fenêtre du panneau de configuration, c'est les infos de mises à jour de DSM qui sont affichées (si jamais...)
  12. Bonjour à tous, J'espère que vous allez tous bien depuis le temps? Une fois n'est pas coutume, je viens encore pour une question certainement très stupide: j'aimerai savoir comment désactiver l'ouverture de la fenêtre du panneau de configuration a chaque connexion? Car je me connecte souvent depuis des tablettes, etc et cette fenêtre, en plus de ne me servir a rien, n'est jamais correctement framé et ca me soule a chaque fois de devoir la fermer 😅 Merci d'avance pour votre aide!
  13. Hello, Etrange ton soucis, car personnellement je n'ai pas eu ce message d'erreur... Et j'ai bien les date au form avec le Z a la fin... Par contre je suis confronté à un blocage un peu différent... J'ai mon réseau internet qui était down (alors que la boucle locale était OK). le script de rnew a donc certainement été lancé et a du tomber en échec car impossible de joindre LE (car évidemment depuis le temps je ne garde plus les logs). Sauf que le script a mis à jour les date de renouvellement de certificat, et que maintenant je me retrouve avec: - Un certificat expiré - un script de renew qui me dit qu'il n'est pas nécessaire de renouveller le certificat... J'ai essayé de changer la date dans le fichier conf, mais cela ne fonctionne pas. J'ai essayé de forcer le renouvellement via -f dans le script de renew, mais ca ne fonctionne pas non plus... De mon côté cela plutôt etre l'url de renouvellement des certificat du synology qui ne fonctionne plus: Quand je tape l'url, j'ai un page JSON qui m'affiche juste EDIT: Je ne sais pas comment tu as démarré tes investigations, mais dans mon cas le soucis a déjà été identifié: https://github.com/acmesh-official/acme.sh/issues/4721 La question c'est maintenant... Comment je reviens à la version 3.0.6 et comment je desactive l'autoupdate... 🙂 EDIT2: Pour ceux qui auraient le soucis, il faut passer le autoupdate dans account.conf à 0
  14. Pohhh... Ben heureusement que tu me l'as dit... Clairement je n'étais pas du tout parti sur un package a arréter.. Un coup de stop, et effectivement, plus rien n'est visible! Merci beaucoup!!
  15. Hello à tous! Requête un peu particulière, vu que d'habitude on cherche plutôt à faire l'inverse... Mais je viens de brancher ma BOX TV et je me suis aperçu que le media center voyait tous les contenus de Music/Photos/Videos de mon DSM vu qu'ils sont tous deux connectés à mon réseaux local. Ca me plait moyen que ces fichiers (perso) trainent aussi facilement sur mon réseau local sans aucune demande d'authentification.. Du coup j'aimerai savoir comment les bloquer. J'ai testé de : - desactiver SMB, mais toujours présent. - désactiver NFS, mais toujours présent. - rajouter 2 options sur les dossiers partagés visibles (genre sur video), mais toujours présent... Je sais pas trop sur quelle autre option je pourrais faire la modif... Donc toute aide serait la bienvenue. Merci d'avance pour votre aide.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.