VPN Server: Paramètres généraux > Interface réseau et type de compte : menu déroulant vide !!!

[loli71]

Bonjour à toutes et tous,

Cela fait un petit moment que je n'étais pas venu demander de l'aide à notre belle communauté nas-forum ..

 

Je me retrouve confronté au problème suivant dans le VPN Server de Synology : Paramètres généraux > Interface réseau et type de compte : menu déroulant vide !!!

 

Je n'avais jamais eu ce problème avant, et j'utilise ce paquet depuis un petit moment, j'avais mis en place une conf openVPN en ma basant sur le tuto suivant

 

J'ai essayé de rebooter, de désinstaller entièrement le paquet et le reinstaller au propre sans conf spécifique .. rien ne change.

Est-ce que quelqu'un a déjà rencontré ce problème ?

 

[Taribam]

Bonjour,

 

Si tu as activé OpenVSwitch, c'est "normal" mais ça fonctionne quand même.

Ceci dit, une fois, j'ai dû aller dans le fichier "/usr/syno/etc/packages/VPNCenter/synovpn.conf" pour mettre la bonne interface à la ligne :

vpninterface=ovs_eth0

ovs_eth0 étant mon interface réseau utilisé pour le VPN car Openvswitch est activé...

[loli71]

Pas de OpenVSwitch d'activé sur mon synology, mais j'ai configuré un MacVlan dans mon docker .. je ne sais pas si cela à un rapport ou pas..

Et même si cela fonctionne quand même, mon souci est que je ne peux pas activer l'option "Accorder le privilège aux utilisateurs locaux nouvellement ajoutés" ou choisir sur laquelle des deux interfaces je veux activer le VPN.

Ticket ouvert chez synology .. pour voir ...

[.Shad.]

@loli71 Si tu supprimes temporairement le réseau macvlan, ça fonctionne ?

[loli71]

Il y a 23 heures, .Shad. a dit :

@loli71 Si tu supprimes temporairement le réseau macvlan, ça fonctionne ?

C'est ce que je voulais tester après que synology ait fini leurs investigations ... mais d'après les traces dans l'history du compte admin, ils aient supprimé l'interface virtuelle que j'avais ajouté (en suivant ce beau tuto .shad justement) qui correspond à la partie 5-B. Création de l'interface virtuelle.

et le VPN Server semble réagir comme il l devrait.

Par contre, ils n'ont pas touché à mon réseau macvlan créé dans le docker

J'attends que synology clôture mon ticket avec leurs explications et je vous tiens au courant ....)

 

Par contre, plus d'interface MacVlan sur mon docker => mon NAS est incapable de joindre AdGuardHome, donc sa résolution DNS n'est plus filtrée....

Modifié le 31 mai 2023 par loli71

[.Shad.]

@loli71 Ca me parle car à une époque je pense que j'avais eu ce souci, sauf que ça fait belle lurette que je n'utilise plus VPN Server...
Je vais voir si je trouve des infos à ce sujet.

[loli71]

Bon, la réponse de synology correspond bien à ce que j'avais vu dans l'history du compte:

Citation

Le problème est résolu, il émanait de l'interférence de certains de vos containers docker dans la configuration réseau du nas.
Des modifications ont été faites manuellement, surveillez si ces dernières ont un impact sur le fonctionnement de vos containers.

Mais du coup je ne sais pas si l'interférence venait du nom de l'interface virtuelle que j'avais créée manuellement ou du fait qu'elle existe tout simplement.

J'ai demandé plus d'explication à syno car leurs modifications on clairement un impact sur le fonctionnement du container AdGuardHome et son utilisation direct par le syno lui même.... mais je ne pense pas avoir de vrai réponse.

[loli71]

Complément d'informations que j'ai pu récupérer de chez synology:

Citation

We checked the interface problem by running the command:

synonet --show, and it seems that the issue is caused by a previously installed Docker container.

 

We have deleted all the files containing the keyword in the `/etc` directory and removed it from `ip link`.

System network interface list:

Host Name: XXXXX

Network interface: macvl0

Lastest SynoErr=[file_get_key_value.c:80]

synonet.c:295 SYNONetGetCard1 failed, synoerr=[0x2000]

 

L'interférence d'un service dockerisé avec les services système du nas n'entre pas dans le champ du support donc c'est probablement quelque chose pour lequel nous ne pouvons fournir une aide extensive.

Reste à voir si on peut créer une interface virtuelle qui ne plante pas le synonet --view ...

@.Shad. si tu retrouves des infos, je suis preneur 😉

Modifié le 1 juin 2023 par loli71

[Jeff777]

@loli71

Je vais regarder plus en profondeur  lorsque j'aurai un moment, mais pour info j'ai le même problème sur mon DS218+ mais pas sur le DS220+.

Sur les deux j'ai implémenté le tuto de @.Shad avec pi-hole.  A priori, la seule différence pour moi c'est que j'ai deux ports éthernet sur le DS220+ et un seul sur le DS218+.

Mais sur les deux j'ai aussi une interface avec des adapteurs USB 2.5Gbts.

Sur le 220+ il me propose (voir ta première copie d'écran) LAN1, LAN2, LAN3 et Mac0    rien sur le DS218+.

 

 

[loli71]

il y a 18 minutes, Jeff777 a dit :

Je vais regarder plus en profondeur  lorsque j'aurai un moment, mais pour info j'ai le même problème sur mon DS218+ mais pas sur le DS220+.

Sur le 220+ il me propose (voir ta première copie d'écran) LAN1, LAN2, LAN3 et Mac0    rien sur le DS218+.

 

@Jeff777Bizarrement c'est justement sur mon DS220+ que j'ai eu le souci 🤪

[.Shad.]

@loli71

Bon, voici mes conclusions de ce que j'ai pu tester : J'ai testé sur le NAS d'un ami (tjs planter le NAS d'un ami avant de planter le sien 😄), sa configuration :

- Un seul réseau bridge, créé via docker-compose en SSH.
- Deux conteneurs adjoints à ce réseau
- VPN Server installé avec OpenVPN

=> Même problème, impossible de sélectionner une interface, donc à ce stade-là, j'en conclus que ce n'est pas proprement lié au réseau macvlan, car il n'y en a jamais eu sur son NAS.

La commande :

synonet --show

m'a renvoyé la même erreur que toi.

System network interface list:

Host Name: GARRUS
Network interface: br_net-dsp
Lastest SynoErr=[file_get_key_value.c:80]
synonet.c:295 SYNONetGetCard1 failed, synoerr=[0x2000]

Je subodore que DSM réalise des ajustements supplémentaires quand il bridge ses interfaces (à l'installation de VMM par exemple avec OpenVSwitch, ou quand on crée un réseau bridge en dehors de l'interface => docker-compose ou cli). Plus probablement, il passe des options type :

...
-o "com.docker.network.bridge.host_binding_ipv4"="0.0.0.0" \
-o "com.docker.network.bridge.enable_icc"="true" \
-o "com.docker.network.driver.mtu"="1500" \
-o "com.docker.network.bridge.name"="lxcbr1" \
-o "com.docker.network.bridge.enable_ip_masquerade"="true" \
...

En revanche, ce que j'ai fait ensuite :

- J'ai arrêté les conteneurs
- J'ai supprimé le réseau bridge
- Je l'ai recréé via l'interface Docker de DSM
- J'ai relancé les conteneurs

Cette fois-ci, la commande synonet --show me renvoie :

System network interface list: 

Host Name: GARRUS
Network interface: eth0
DHCP 
IP: 192.168.0.50 
Mask: 255.255.255.0 
Gateway: 192.168.0.1 
DNS: 192.168.0.1 
MTU Setting: 1500 

Et les interfaces apparaissent dans les Paramètres généraux de VPN Server :

Solutions possibles au final :

- Trouver des logs qui décrivent ce que DSM fait quand il crée un réseau via l'UI, voir les options passées éventuellement pour assurer la compatibilité avec les autres services. Je n'ai malheureusement pas accès au dit-NAS en SSH pour vérifier si je trouve quelque chose dans les logs, peut-être peux-tu y jeter un oeil ? je ne sais pas où les logs de Docker se situent.

- Espérer que Container Manager de DSM 7.2 permette la création de réseau macvlan, mais ça m'étonnerait.

- Si tu n'utilises pas DNS Server sur ton NAS, il y a une solution facile, elle te fera juste perdre la page de blocage pour les pages en HTTP, qu'on ne trouve plus nulle part de toute façon :

• Tu utilises la variable WEB_PORT dans ton fichier compose :

• Tu peux donc passer le conteneur en mode host ou en mode bridge mais en pensant à faire la translation de ports pour les port 53 et 9880 (exemple de port pour WEB_PORT, à ta guise).

Modifié le 1 juin 2023 par .Shad.

[loli71]

Il y a 21 heures, .Shad. a dit :

Je n'ai malheureusement pas accès au dit-NAS en SSH pour vérifier si je trouve quelque chose dans les logs, peut-être peux-tu y jeter un oeil ? je ne sais pas où les logs de Docker se situent.

Merci @.Shad., je vais tester cela ce week-end et voir si je trouve les logs ...

Je vous tiens au courant 🙂

[Jeff777]

@loli71 @.Shad.

En reprenant le tuto suivant , le problème intervient lors de la création de l'interface virtuelle mac0 (la création du macvlan ne pose pas de problème).

synonet --show

Host Name: DS218
Network interface: mac0
Lastest SynoErr=[file_get_key_value.c:80]
synonet.c:322 SYNONetGetCard1 failed, synoerr=[0x2000]
 

J'avais trouvé un fichier log qui me donnait ça :

2023-06-02T11:59:31+02:00 DS218 if_link_down_hook_event[13584]: mac0
2023-06-02T11:59:33+02:00 DS218 ipv4_change_hook_event[14075]: mac0 none->192.168.1.115          IPvirt du DS218
2023-06-02T11:59:35+02:00 DS218 if_link_up_hook_event[14456]: mac0
2023-06-02T11:59:37+02:00 DS218 ipv6_add_hook_event[15036]: mac0 added { fe80::xxx:xxx:xxx:xxx/128 } from {  }          IPV6virt du DS218
2023-06-02T12:04:41+02:00 DS218 synonetd[5787]: net_ipv6_conf_set.c:121 Failed to send RS for mac0
2023-06-02T12:04:43+02:00 DS218 ipv6_add_hook_event[18791]: mac0 added { 2a01:yyy:yyy:yyy:xxx:xxx:xxx:xxx/128 } } from { fe80::xxx:xxx:xxx:xxx/128 }/128 }
 

J'ai essayé de reprendre le tuto sans faire intervenir l'IPV6 même résultat pour le synonet --show.....par contre je n'ai pas retrouver l'endroit où j'avais eu le log  🤡

Un peu ballot.

[MilesTEG1]

Ce souci m'intrigue beaucoup.
J'ai lancé la commande dans un terminal :

sudo synonet --show
Password:
System network interface list:

Host Name: Syno-DS920Plus
Network interface: eth1
DHCP
IP: 169.254.26.251
Mask: 255.255.0.0
Gateway: 192.168.2.1
DNS: 192.168.2.210
MTU Setting: 1500
65535, unknown duplex, active mtu 1500
RX bytes: 0
TX bytes: 0

Host Name: Syno-DS920Plus
Network interface: eth2
DHCP
IP: 192.168.2.201
Mask: 255.255.255.0
Gateway: 192.168.2.1
DNS: 192.168.2.210
MTU Setting: 1500
2500, full duplex, active mtu 1500
RX bytes: 969889074014
TX bytes: 87089911828

Host Name: Syno-DS920Plus
Network interface: macv0
Lastest SynoErr=[file_get_key_value.c:80]
synonet.c:322 SYNONetGetCard1 failed, synoerr=[0x2000]

J'ai réinstallé le paquet VPN Server, et j'ai le même souci que vous tous ici : rien dans la liste déroulante :

 

J'ai pas mal de réseaux bridge créés via les docker-compose.yml dans Portainer.
Un macvlan et une interfac virtuelle, le tout créé depuis la ligne de commande.

Bon ça ne me gêne pas vraiment car mon serveur VPN est sur mon routeur.

[Jeff777]

Il y a 23 heures, MilesTEG1 a dit :

Ce souci m'intrigue beaucoup.

Moi aussi...j'ai essayé des tas de trucs et toujours pareil 😒.

 

 

 

[loli71]

pareil ....  j'essaye de trouver où sont les logs de docker lors de la création d'une interface bridge par le webui ... mais je ne sais pas comment lire le fichier qui pourrait contenir des infos:

/var/packages/Docker/var/docker/network/files/local-kv.db

 

[loli71]

Le 01/06/2023 à 21:48, .Shad. a dit :

=> Même problème, impossible de sélectionner une interface, donc à ce stade-là, j'en conclus que ce n'est pas proprement lié au réseau macvlan, car il n'y en a jamais eu sur son NAS.

@.Shad.Je te confirme que le problème n'est pas propre à la création d'un réseau macvlan, mais à toute interface/réseau créé en ssh via docker-compose ou en CLI.

 

J'ai créé mon réseau Macvlan via portainer, ce réseau ne pose pas de souci, et le support synology ne me l'a pas supprimé

Ils m'ont supprimé que l'interface de bridge que j'ai crée en ssh par le script que tu avais mis dans ton tuto.

# Creation de l interface macvlan sur l hote
ip link add macvl0 link eth0 type macvlan mode bridge
ip addr add 192.168.1.175/32 dev macvl0
ip link set dev macvl0 address 5E:00:01:02:03:45
ip link set macvl0 up
ip route add 192.168.1.160/28 dev macvl0

 

 

Modifié le 5 juin 2023 par loli71

[.Shad.]

@loli71 Sur le NAS où j'ai fait le test il n'y avait pas d'interface virtuelle, il y en a même jamais eu, et j'avais le problème, le problème a disparu quand j'ai créé le réseau via DSM.

[MilesTEG1]

Donc verdict : il faut créer les réseaux docker via dsm .

ca va être contraignant 😅

je me suis habitué à laisser Portainer me créer les réseaux via les instructions dans les docker-compose.yml…

[loli71]

il y a une heure, .Shad. a dit :

@loli71 Sur le NAS où j'ai fait le test il n'y avait pas d'interface virtuelle, il y en a même jamais eu, et j'avais le problème, le problème a disparu quand j'ai créé le réseau via DSM.

oui, la création par ssh ou CLI docker pose problème quelque soit le réseau.

@MilesTEG1  Par le DSM ou par portainer pas de problème, que ce soit un réseau bridge ou un macvlan.

Portainer m'en a créé plusieurs sans problème via les instructions docker-compose.yml

 

Mon souci est apparu lorsque j'ai créé l'interface via ssh qui permet au syno d'utiliser l'adresse dans le macvlan ... je n'arrive pas à trouver comment créer cette interface macvl0 comme synology l'accepterait ...

Modifié le 5 juin 2023 par loli71

[Jeff777]

il y a 4 minutes, loli71 a dit :

le souci apparait lorsque j'ai créé l'interface via ssh qui permet au syno d'utiliser l'adresse dans le macvlan ... je n'arrive pas à trouver comment créer cette interface macvl0 comme synology l'accepterait ..

Idem

D'ailleurs on peut créer l'interface virtuelle en conservant les autres interfaces dans la case des paramètres généraux du VPN..... à condition d'omettre "up" dans le script. 

Le problème arrive lorsque l'on monte l'interface.

[MilesTEG1]

il y a 31 minutes, loli71 a dit :

@MilesTEG1  Par le DSM ou par portainer pas de problème, que ce soit un réseau bridge ou un macvlan.

Portainer m'en a créé plusieurs sans problème via les instructions docker-compose.yml

 

Mon souci est apparu lorsque j'ai créé l'interface via ssh qui permet au syno d'utiliser l'adresse dans le macvlan ... je n'arrive pas à trouver comment créer cette interface macvl0 comme synology l'accepterait ...

Ha ok ! J'ai cru que c'était toute création de réseau qui faisait le problème...
Mais en fait non.
Si on les crée via les docker-compose par portainer : RAS.
Même chose pour le macvlan ? Moi je l'ai créé via un script.

Par contre, la création de l'interface virtuelle elle, quand elle est montée, fait foirer les interfaces dispo dans le VPN...

Ai-je bon ?

 

Mais du coup, est-il possible de créer et lancer cette interface virtuelle autrement qu'avec un script ou une ligne de code ?
Car c'est quand même assez utile pour ne pas dire indispensable...

[Jeff777]

il y a une heure, MilesTEG1 a dit :

Par contre, la création de l'interface virtuelle elle, quand elle est montée, fait foirer les interfaces dispo dans le VPN...

Ai-je bon ?

Pas toujours ça fonctionne pour certains NAS sans que l'on sache pourquoi 

Modifié le 5 juin 2023 par Jeff777

[loli71]

Il y a 13 heures, MilesTEG1 a dit :

Même chose pour le macvlan ? Moi je l'ai créé via un script.

Non, de mon côté un réseau macvlan créé par script plante le VPN, mais le réseau macvlan que j'ai créé par portainer ne le plante pas par contre ...

[Jeff777]

Il y a 12 heures, Jeff777 a dit :

Pas toujours ça fonctionne pour certains NAS sans que l'on sache pourquoi 

Finalement c'est tombé en marche sur mon deuxième nas 😜. Mais je le sais pas pourquoi.....par contre je sais comment.....de la mauvaise manip nait l'innovation 😊

J'ai utilisé la fonction synonet --dhcp mac0  ce qui a mis une sacrée panique mais a dû décoincer un truc. Désolé de ne pas détailler plus, je vous laisse le soin de comprendre. Le résultat est là l'erreur n'est pas irrémédiable.

il y a 10 minutes, loli71 a dit :

Non, de mon côté un réseau macvlan créé par script plante le VPN,

ça je n'ai jamais eu et j'ai toujours créé le macvlan par script. C'est la création de l'interface virtuelle qui faisait planter  

et maintenant :