Aller au contenu

Messages recommandés

Posté(e)

Je ne pense pas que cela vient du revers proxy.

Car j'y accède bien sans règle pare-feu du syno.

C'est une règle qui me manque lorsque j'essaye d'accéder à mon bitwaren ...

J'y arrive en ouvrant le flux du réseau de mon docker.

 

Je ne pense pas que cela puisse avoir un impacte sur mon vlan du NAS ni sur mon docker, mais j'ai quand même un /24 ouvert à tout ...

Posté(e) (modifié)

Dans ton pare-feu, tu autorises l'accès aux adresses 172.28.0.1 à 172.28.0.254, es-tu sûr que le container bitwarden de l'interface a cette adresse-là ?
Remplace cette règle par 172.16.0.0/255.240.0.0
Ça autorisera tous les containers créés en mode bridge à discuter avec ton NAS.

Et dans ta règle, tu n'as pas besoin de passer deux fois par du HTTPS, dans destination tu mets HTTP / 127.0.0.1 (ou localhost) / 81 (si tu as bien renseigné le mapping du port 81 lors du script d'installation de Bitwarden).
Ensuite si tu n'as pas d'ouverture vers le réseau local sur le port 81, crée une règle pour ce port, et teste si ça marche.

Pour moi c'est ta règle de pare-feu qui n'est pas bonne.

Modifié par shadowking
Posté(e)
il y a 6 minutes, unPixel a dit :

C'est voulu le Bitwaren sans le d ?

non c'est une faute de ma part

Pourquoi n'est-ce pas localhost ?

cela ne revient-il pas au même ?

 

il y a 11 minutes, shadowking a dit :

Dans ton pare-feu, tu autorises l'accès aux adresses 172.28.0.1 à 172.28.0.254, es-tu sûr que le container bitwarden de l'interface a cette adresse-là ?

oui j'y accède depuis l’extérieur en mettant cette adresse la dans ma règle de pare-feu.


Remplace cette règle par 172.16.0.0/255.240.0.0
Ça autorisera tous les containers créés en mode bridge à discuter avec ton NAS.

OK

Et dans ta règle, tu n'as pas besoin de passer deux fois par du HTTPS, dans destination tu mets HTTP / 127.0.0.1 (ou localhost) / 81 (si tu as bien renseigné le mapping du port 81 lors du script d'installation de Bitwarden).

oui j'ai essayé cela et ca marche dans les deux cas (HTTPS 81 et HTTPS 444)
Ensuite si tu n'as pas d'ouverture vers le réseau local sur le port 81, crée une règle pour ce port, et teste si ça marche.

Pour moi c'est ta règle de pare-feu qui n'est pas bonne.

C'est ce que je constate. mais j'ai résolu cela en ouvrant la plage du docker 172.28.0.0/24

 

Posté(e)

Est-ce que 127.0.0.1 est l'adresse privée de ton NAS ? Car logiquement, Bitwarden prend l'IP privée de ton NAS. Et c'est pour ça que je te disais de mettre localhost.

Posté(e)
il y a 2 minutes, unPixel a dit :

Est-ce que 127.0.0.1 est l'adresse privée de ton NAS ? Car logiquement, Bitwarden prend l'IP privée de ton NAS. Et c'est pour ça que je te disais de mettre localhost.

le 127.0.0.1 représente l'adresse IP du localhost, un genre de loopback

Cela revient au même me semble t il ...

Posté(e)

127.0.0.1 c'est localhost c'est pareil.

Ça permet que s'il change son IP locale, il n'y ait pas d'impact.

Ok pour 172.28.0.0/24, par contre t'es parti pour faire une règle de pare-feu pour chaque container avec lequel tu dois communiquer, ça me semble fastidieux.

Tu chiffres deux fois, une fois pour arriver à ton proxy inversé, là c'est bien, et une fois entre ton proxy inversé et ton container, là il n'y a aucun intérêt.

Le HTTPS est utile si tu dois directement accéder à Bitwarden de manière sécurisée sans passer par un proxy inversé.

Posté(e)
il y a 1 minute, shadowking a dit :

127.0.0.1 c'est localhost c'est pareil.

Ça permet que s'il change son IP locale, il n'y ait pas d'impact.

Ok pour 172.28.0.0/24, par contre t'es parti pour faire une règle de pare-feu pour chaque container avec lequel tu dois communiquer, ça me semble fastidieux.

oui je vois la contrainte... Je vais modifier cela...

Tu chiffres deux fois, une fois pour arriver à ton proxy inversé, là c'est bien, et une fois entre ton proxy inversé et ton container, là il n'y a aucun intérêt.

Je comprends ... Je vais également modifier cela ...

Le HTTPS est utile si tu dois directement accéder à Bitwarden de manière sécurisée sans passer par un proxy inversé.

Merci encore de votre aide !

Posté(e)

Hello, depuis la dernière mise à jour IOS 13 mon certificat auto signée ne semble plus fonctionner correctement. J'utilise mon adresse publique et ça fonctionnais bien avant la MAJ en IOS 13. Apparement il y'a eu des changements : https://support.apple.com/en-us/HT210176 , j'ai régénérè mon certificat pour respecter ça mais toujours pareil. Avec l'application IOS j'ai un " There is a problem connecting to the server", avec safari ça semble fonctionner une fois sur deux (super bizarre). En revanche, tous mes autres devices j'ai aucune soucis (Windows, Linux ...). Je pense vraiment à un soucis avec mon certificat sous IOS mais je ne vois pas comment m'en sortir. Si vous avez des idées je suis preneur à fond 😉

  • 4 semaines après...
Posté(e)
Le 03/10/2019 à 16:54, snakefox666 a dit :

Hello, depuis la dernière mise à jour IOS 13 mon certificat auto signée ne semble plus fonctionner correctement. J'utilise mon adresse publique et ça fonctionnais bien avant la MAJ en IOS 13. Apparement il y'a eu des changements : https://support.apple.com/en-us/HT210176 , j'ai régénérè mon certificat pour respecter ça mais toujours pareil. Avec l'application IOS j'ai un " There is a problem connecting to the server", avec safari ça semble fonctionner une fois sur deux (super bizarre). En revanche, tous mes autres devices j'ai aucune soucis (Windows, Linux ...). Je pense vraiment à un soucis avec mon certificat sous IOS mais je ne vois pas comment m'en sortir. Si vous avez des idées je suis preneur à fond 😉

Salut,

Pourquoi ne pas utiliser un certificat lets encrypt avec ton Synology.me ou carrément avec un domaine plutôt qu'un auto signé ?

Possible qu'Apple bloque par défaut les certificats qui ne sont pas de confiance.

  • 3 semaines après...
Posté(e)

Bonjour,

 

Après 1Password qui est passé à l'abonnement, j'étais passé à Enpass via le Webdav du Syno.

Mais Enpass passe aussi à l'abonnement, donc j'ai installé Bitwarden et ça fonctionne plutôt bien.

Je note quand même que c'est assez gourmand en ressources, j'ai une petite base pourtant, mais ça bouffe quasi 2 Go de mémoire et ça tire pas mal sur le petit Celeron du DS218+ avec ses 10 instances Docker qui tournent en parallèle.

C'est quand même un peu la grosse artillerie juste pour garder ses données chez soi 😞

 

Capture d’écran 2019-11-16 à 18.20.20.png

  • 2 semaines après...
Posté(e) (modifié)

Salut,

Je regarde pour migrer d'Enpass à Bitwarden (via le container bitwarden_rs), mais je rencontre deux problèmes:

- Mail: j'obtiens ceci dans les logs: [2019-11-25 20:43:07][bitwarden_rs::api::identity][ERROR] Error sending new device email: Error sending email. 5.2.0 Spam message rejected

en utilisant mon compte infomaniak. J'ai essayé aussi avec mon compte OVH, les mails partent bien mais vont directement en spam

- Reverse proxy: Pas de redirection https sur le reverse proxy du synology... comment faire du coup?

Une idée?

Modifié par xianghua
Posté(e)

Juste pour info, les utilisateurs ayant payant une licence Pro n’auront (et n’ont pas) à payer quoique ce soit en plus.

Pour continuer à utiliser l’app, il suffit de s’enregistrer chez eux via un compte mail qui sera à utiliser sur tous les supports (e-mail pour réception d’un code pour activation sur chaque support).

Perso c’est ce que j’ai fait ce week-end et tout c’est bien passé (iMac, iPhone (x2), iPad).

Après pour combien de temps... ça reste à voir ^^

No, the users who had earlier purchased Enpass won’t have to pay again for the subscription and can continue to use the Pro version at no extra cost. Instead, you’ll get a complimentary subscription, and on registering, you will be able to use Enpass on all the devices for free.
To activate the complimentary subscription, please register your purchase with us using an email ID and use the same ID while registering Enpass on other devices.

Posté(e)
Il y a 7 heures, xianghua a dit :

- Mail: j'obtiens ceci dans les logs: [2019-11-25 20:43:07][bitwarden_rs::api::identity][ERROR] Error sending new device email: Error sending email. 5.2.0 Spam message rejected

en utilisant mon compte infomaniak. J'ai essayé aussi avec mon compte OVH, les mails partent bien mais vont directement en spam

https://www.infomaniak.com/fr/support/faq/316/erreur-spam-message-rejected-ou-570-av-message-is-rejected-by-headers-rule-filter-554-please-check-the-message-and-try-again

infomaniak préconise de prendre contact avec eux en cas d'erreur non justifié.

 

Il y a 7 heures, xianghua a dit :

- Reverse proxy: Pas de redirection https sur le reverse proxy du synology... comment faire du coup?

Si il est possible en https

Posté(e)
Il y a 5 heures, alan.dub a dit :

Juste pour info, les utilisateurs ayant payant une licence Pro n’auront (et n’ont pas) à payer quoique ce soit en plus.

Pour continuer à utiliser l’app, il suffit de s’enregistrer chez eux via un compte mail qui sera à utiliser sur tous les supports (e-mail pour réception d’un code pour activation sur chaque support).

Perso c’est ce que j’ai fait ce week-end et tout c’est bien passé (iMac, iPhone (x2), iPad).

Après pour combien de temps... ça reste à voir ^^

No, the users who had earlier purchased Enpass won’t have to pay again for the subscription and can continue to use the Pro version at no extra cost. Instead, you’ll get a complimentary subscription, and on registering, you will be able to use Enpass on all the devices for free.
To activate the complimentary subscription, please register your purchase with us using an email ID and use the same ID while registering Enpass on other devices.

Oui, mais dans le doute, je préfère prendre les devants personnellement.

il y a 21 minutes, EVOTk a dit :

https://www.infomaniak.com/fr/support/faq/316/erreur-spam-message-rejected-ou-570-av-message-is-rejected-by-headers-rule-filter-554-please-check-the-message-and-try-again

infomaniak préconise de prendre contact avec eux en cas d'erreur non justifié.

 

Si il est possible en https

Pas bête pour infomaniak, merci pour l'idée.

Concernant le reverse proxy, je voulais dire une redirection http --> https

Par exemple si je tape bitwarden.mydomain.fr, que le reverse du NAS fasse une redirection 301 http vers https://bitwarden.mydomain.fr

Posté(e) (modifié)

Salut,

D'accord je comprend mieux.

Je suppose qu'avec un .htaccess de ce genre cela devrait fonctionner :

Citation

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://bitwarden.ndd.fr/$1 [R,L]

ou bitwarden est un sous domaine, et ndd.fr ton nom de domaine.

Par contre, je n'utilse pas cette technique, en faite dans mon reverse proxy je ne redirige que :

https://bitwarden.ndd.fr vers https://localhost:8282

D'office quand je tape "bitwarden.ndd.fr" le navigateur prend la connexion https

Si je force le navigateur a prendre http, donc en renseignant l'adresse complete "http://bitwarden.ndd.fr" la redirection ne se fait pas, puisque non déclaré dans le proxy inversé, et cela affiche la page "ndd.fr".

Modifié par Invité
Posté(e) (modifié)

C'est dommage que Synology ne permet pas les redirections http vers https, vu que HAproxy, Nginx et Apache le font simplement.

Après il est vrai que l'historique du navigateur permet de s'en affranchir.

Sinon Bitwarden c'est pas mal, en espérant que Bitwarden_rs suit les mises à jours de Bitwarden. (La version classique en SQL Server et architecture micro service est carrément abusé pour un particulier)

Modifié par xianghua
  • 1 mois après...
Posté(e)

Hello,
Après une petite upgrade de RAM de mon 415+ j'ai voulu me lancer dans ce tuto.
Une fois arrivé à la validation des id, je reçois l'erreur suivante:
"Unable to validate installation id. Problem contacting Bitwarden server."

Les ports sont ouverts en sortie, par contre la configuration "bridge" de docker ne me semble pas correcte.
Elle utilise un subnet en 172.17.0.0/16 qui n'existe pas, de plus le NAS est en 172.18.0.0/16.
Il existe par contre un réseau en 172.17.1.0/24 qui n'est pas utilisé.

En cherchant un peu sur Google, j'ai lu qu'il fallait installer Open vSwitch mais je ne vois pas le rapport.
De plus, j'ai un message d'avertissement concernant mon aggrégation de lien et je ne sais pas ce qu'il faut choisir...
image.thumb.png.ebf5e96b0d4da975e31d57b8ba2d4210.png

Quelqu'un aurait il une idée?
Merci !

 

 

Posté(e)

Salut,

Les adresses IP privées en 172 vont de 172.16.0.0 à 172.31.255.255
Donc en quoi ça ne serait pas correct ?

Il y a 7 heures, Spi a dit :

de plus le NAS est en 172.18.0.0/16

Ce n'est pas une adresse IP ça, c'est un IP range.

En dernier lieu,

Il y a 7 heures, Spi a dit :

"Unable to validate installation id. Problem contacting Bitwarden server."

Je ne vois pas comment tu arrives à la conclusion d'un problème de bridge à cause de cette erreur.
Il y a visiblement quelque chose qui cloche au niveau de la création du numéro d'ID Bitwarden, il se peut (très fortement) que le script bitwarden.sh ait évolué entre la rédaction du tutoriel et maintenant.
Reprend les différentes étapes à tête reposée, tu peux fournir des impressions d'écran si tu hésites sur certaines questions.

Posté(e) (modifié)

Hello @.Shad. ,

Je me suis mal exprimé apparemment. Les LAN que j'utilisent sont 172.16.1.0/24, 172.17.1.0/24 et 172.18.0.0/16.
Je ne connais pas Docker, mais j'imagine qu'il utilise une interface réseau virtuelle comme le fait Hyper-V ou VMware où n'importe quel programme du genre, c'est en tout cas ce que j'ai trouvé en faisant des recherches sur l'erreur avec Synology en mot clé.

Vu que dans la config Docker, je vois qu'il y a un bridge configuré sur un réseau 172.17.0.0/16 et que ce dernier n'est pas configuré dans mes équipements, j'ai pensé qu'il était possible que la requête de validation s'effectue à l'intérieur d'un conteneur qui aurait été créé par le script. Si ce conteneur s'était retrouvé en 172.17.x.x/16 sans gateway par exemple, il n'aurait pas pu sortir et faire sa requête.

Pour finir "Problem contacting Bitwarden server." laisse songer à un paramètre réseau.
Ainsi que ces recherches Github et, Github

PS: Je sais faire la différence entre une ip, un (sous-)réseau et même un masque. 😉

Modifié par Spi
Ajout d'infos
Posté(e)

Une simple question, si je dois me connecter à un de mes comptes par exemple gmail, sur un device qui ne m'appartient pas !

Comment procéder ? si nos passwords sont stockés sur un password vault comme bitwarden ?

Posté(e)
il y a 8 minutes, Dimebag Darrell a dit :

Une simple question, si je dois me connecter à un de mes comptes par exemple gmail, sur un device qui ne m'appartient pas !

Comment procéder ? si nos passwords sont stockés sur un password vault comme bitwarden ?

Hello,
Tu te connectes sur l'interface web et tu fais un copier coller via le bouton.
Comme ça pas besoin d'installer un client lourd ou une extension de navigateur.

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

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