Aller au contenu

Yoloyolo

Membres
  • Compteur de contenus

    9
  • Inscription

  • Dernière visite

À propos de Yoloyolo

Yoloyolo's Achievements

Newbie

Newbie (1/14)

0

Réputation sur la communauté

  1. Ca fonctionne en LAN sans soucis, merci Balooforever pour l'aide ! Mais ca a soulevé un autre problème, en VPN ça ne fonctionne toujours pas... Je suis connecté au serveur VPN sur mon syno tout le traffic est redirigé, ma config VPN me donne accès au LAN. Mais quand je fais une requête, nginx me voit avec une ip client qui correspond à celle que j'utilise pour me connecter en VPN mais comme l'ip que le serveur VPN m'octroie. Je trouve pas comment régler ça, je comprends pas si ça vient du fait que j'utilise la même instance pour le serveur VPN et pour nginx. Je vais continuer à chercher mais je manque un peu de mots-clefs...
  2. 😮 " By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN. " Ca annule complétement mon protocole de test ! et en regardant les logs de nginx je vois tous les blocages, avec l'adresse ip de ma connexion wan pas celle du VPN. Je vais tenter ce soir de changer la config VPN pour faire passer tout mon traffic dessus et on verra. Mais je crois que comme souvent le problème ce situe entre le clavier et la chaise 😅
  3. Je sais pas non plus, je vais tenter de voir si dans les logs du reverse proxy je vois quelque chose mais je sais pas vraiment ou regarder. Et ce weekend je pourrais être en local donc je vais voir si en local ca bloque aussi mais j'ai peu d'espoir à ce niveau là... Sinon pour résoudre un site seulement en local je peux toujours faire un dns local avec une adresse qui pointe vers mon wiki. Mais je trouve ça moins élégant, snif snif. On croise les doigts, je tiens au courant le forum de la suite !
  4. Hello Balooforever Oui je me connecte directement au syno en openvpn. Mon protocole de test, vu que je peux pas être en local, pour être sûr que je suis bien connecté en VPN, c'est que je joins d'abord le service par son ip local (192.168.1.4:3500) une fois que ça est bon, dans le meme onglet je regarde si je peux le joindre par son adresse.ndd.fr. J'ai fait plus de tests mais toujours pas de solutions: Les configs qui ne me donnent pas accès quand je suis connecté en LAN ou WAN sont (ip de mon ordi en VPN = 10.8.0.6) N=1 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Refuser N=2 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Refuser 10.8.0.6 Autoriser N=3 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Refuser 10.8.0.6 Autoriser N=4 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Refuser Tous Autoriser N=5 10.0.0.0/8 Autoriser Tous Refuser N=6 10.8.0.6/32 Autoriser Tous Refuser Les configs qui donnent accès à la page en WAN et LAN sont : N=7 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Autoriser N=8 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser N=9 192.168.0.0/24 Autoriser 10.0.0.0/8 Autoriser 127.0.0.0/8 Autoriser 127.16.0.0/12 Autoriser Tous Autoriser Tous Refuser N=10 Aucune règle dans le profile Mes conclusions sont donc d'après N=10 que tout est autorisé par défaut, que l'ordre semble compter quand tu compares N=9 et N=4 avec le haut de la liste qui passe d'abord. Mais après je comprends pas bien pourquoi quand je mets mon IP directement ou un CIDR 10.0.0.0/8 ca passe pas... Si t'as des idées ?
  5. Hello tout le monde ! J'ai un ensemble de containers docker qui tournent avec des services associés à des ports. Pour avoir accès à ces services j’ai un reverse proxy en place qui lie uneadressse.monndd.fr à un port de mon syno. Je souhaiterai que certains services (un wiki) ne soient pas accessible du wan mais seulement du lan. Pour cela, j'ai mis en place un profile d’accès lan en me basant sur un tuto sur les dns de fenrir pour les plages d’ip à renseigner, sur la page de syno assez sommaire sur le reverse proxy et sur ce post Reddit qui semble indiqué que l’orde des règles est important. Malheureusement je ne serai pas là si ça avait fonctionné 😓 J’ai essayé différents ordres de règles etc mais rien y fait quand je me connecte en VPN avec une adresse 10.8.0.6 le service avec le controle ' accès est bloqué. Je vous mets la config avec laquelle j'ai commencé et en laquelle je croyais mais qui n'est pas bonne à priori : Je ne comprends pas ce que je fais mal. Est ce que quelqu’un a déjà rencontré ce même genre de problèmes ou à une configuration similaire qui fonctionne ? Ou même une idée de vers où chercher une solution ? Merci d’avance de votre aide !
  6. Ah ok je vais relire dans ce cas là sur les reverse proxy et le reverse ssh. Est ce que tu peux me dire les contraintes qui te viennent à l'esprit pour que je puisse lire des trucs avec des mots clés en tête. Merci en tout cas de tes réponses !
  7. Ok merci de ta réponse. Et sinon en lisant un peu à droite à gauche j'ai vu qu'on pouvait faire des reverses SSH. Si j'ai bien compris ça permet d'établir un tunnel SSH avec une machine distante en passant par un port (peu importe lequel) ouvert du routeur. Ca me semble assez similaire à un reverse proxy d'où le nom j'imagine ^^. Bref tout ça pour dire est ce qu'établir un reverse SSH avec rsync est aussi une autre solution (j'ai pas trouvé de lecture à ce sujet donc je doute) ? Si oui quels seraient les avantages et inconvénients?
  8. Bonjour ! En ce moment j'ai comme projet de mettre en place une sauvegarde mon ordi sur mon syno via rsync et j'aurais besoin de petits conseils sur l'architecture de cette manœuvre. Donc comme je te le disais je veux faire une sauvegarde quotidienne de mon ordi perso sur mon syno via rsync et le tout par internet pour les fois ou je suis en déplacement. La manière dont je vois ça, c'est de faire un tunnel VPN jusqu'à mon réseau local et ensuite d'envoyer mes sauvegardes encapsulées dans du ssh via rsync et coupler ça une un commande cron sur mon ordi pour le coté quotidien de la tâche. Mais quand je dis ça ne sonne pas très juste, j'ai l'impression de crypter mes données 2 fois via vpn et via ssh ? Evidemment pour avoir déjà ouvert le port ssh vers internet de mon syno je sais qu'il faut pas le faire haha donc je sais pas trop je suis un peu perdu face à ce montage qui ne me semble pas très propre et j'ai pas envie de faire n'importe quoi vu que ce sont mes données perso... Si quelqu'un à un avis sur la démarche à suivre ou une indication de truc à lire (j'ai déjà parcouru plusieurs pages mais sans me convaincre de ma solution) ce serait super. Merci d'avance ! V
  9. Bonjour, J’ai décidé de mettre en place un rsync avec du ssh pour faire mes back up sur mon synology (DS 1815+, DSM 6.0.2-8451) et je voudrais mettre en place un commande automatisée avec cron. Le problème est que je bloque à l’étape de mise en place de clés ssh pour un autre compte que le compte admin. Je tiens à préciser que je suis assez novice dans le domaine mais j’ai passé beaucoup de temps à lire des forums et à tester des solutions sans succès c’est pour ça que je m’adresse à vous directement. L’état de la situation au moment où je vous écris. J’ai réussi à mettre en place une connection avec des clés pour le compte admin et ça fonctionne, en revanche j’ai un autre compte (qui est dans le groupe administrateur sur le syno) pour lequel je n’arrive pas à établir de connexion avec les clés mais je peux connecter avec MDP dessus sans problème. Parmi les choses que j’ai faite mais dont je ne suis pas sûr: - C’est que j’ai utilisé 2 sets de clés différents pour chaque compte une paire pour le compte admin et une autre paire pour l’autre compte, sachant que je me conncte à partir du même ordi. Je ne sais pas si c’est la procédure normale ou si c’est idiot de faire ça et qu’il faudrait utiliser seulement une seule paire de clés ? - Dans le fichier sshd_config je n’ai pas décommenté la ligne AuthorizedKeysFile .ssh/authorized_keys puisqu’il y a écrit au dessus que de base ca cherche dans ce fichier et dans un autre. J’ai vu dans des tutos que certaines personnes décommentées cette ligne. Et voici les logs de ma tentative de connexion: OpenSSH_6.9p1, LibreSSL 2.1.8 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to IP_NAS [178.203.35.1] port 22. debug1: Connection established. debug1: identity file /Users/user_admin_group/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/user_admin_group/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6 debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to IP_NAS:22 as 'user_admin_group' debug3: hostkeys_foreach: reading file "/Users/user_admin_group/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /Users/user_admin_group/.ssh/known_hosts:3 debug3: load_hostkeys: loaded 1 keys from IP_NAS debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com debug2: kex_parse_kexinit: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:7yFb7ds2gPKz5MUFNlbI2OYNOQNeEIGjt77PnOjcCVw debug3: hostkeys_foreach: reading file "/Users/user_admin_group/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /Users/user_admin_group/.ssh/known_hosts:3 debug3: load_hostkeys: loaded 1 keys from IP_NAS debug3: hostkeys_foreach: reading file "/Users/user_admin_group/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /Users/user_admin_group/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 178.203.35.1 debug1: Host 'IP_NAS' is known and matches the ECDSA host key. debug1: Found key in /Users/user_admin_group/.ssh/known_hosts:3 debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/user_admin_group/.ssh/id_rsa (0x7fce98f044e0), debug2: key: (0x7fce98f14590), debug2: key: /Users/user_admin_group/.ssh/id_dsa (0x0), debug2: key: /Users/user_admin_group/.ssh/id_ecdsa (0x0), debug2: key: /Users/user_admin_group/.ssh/id_ed25519 (0x0), debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/user_admin_group/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Offering RSA public key: debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp SHA256:BUGsn3DLgNd4FdtHB/mjU1iTZ/INe+Rek4Y6n8MctkE debug3: sign_and_send_pubkey: RSA SHA256:BUGsn3DLgNd4FdtHB/mjU1iTZ/INe+Rek4Y6n8MctkE Connection closed by 178.203.35.1 Si vous avez une idée je suis preneur. Merci d'avance !
×
×
  • 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.