MilesTEG1

Hello par ici 🙂 Dites, depuis que j'ai fait la MAJ du paquet Docker DSM hier soir, j'ai plein de petits soucis... Ça a commencé par Tautulli qui ne pouvait plus se connecter à mon PMS... (je n'ai rien changé niveau réglages...)... Puis j'ai vu cette erreur dans DSM : System failed to get External IP. J'ai rebooté le NAS, et ce dernier s'est éteint (oui je ne me suis pas trompé de ligne pour le clic, j'ai bien choisi redémarrer ^^), et pas moyen de le rallumer au bouton... il a fallu que je débranche la prise d'alimentation du NAS et que je la rebranche pour qu'il se rallume. Bref, voilà pour la mise en situation... Et ce matin, je reçois cet email de Watchtower : Could not do a head request for "lissy93/dashy:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:42909->192.168.2.210:53: i/o timeout Unable to update container "/Dashy": Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Proceeding to next. Could not do a head request for "gitea/gitea:1", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:58762->192.168.2.210:53: i/o timeout Could not do a head request for "grafana/grafana:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:41298->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/tautulli:amd64-latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:34463->192.168.2.210:53: i/o timeout Could not do a head request for "vaultwarden/server:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:38384->192.168.2.210:53: i/o timeout Could not do a head request for "ttionya/vaultwarden-backup:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:39918->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/plex:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:49616->192.168.2.210:53: i/o timeout Found new ghcr.io/linuxserver/plex:latest image (b3c421db2d05) Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:55395->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:49073->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:52051->192.168.2.210:53: i/o timeout Could not do a head request for "influxdb:1.8", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:53334->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/calibre-web:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:48934->192.168.2.210:53: i/o timeout Could not do a head request for "portainer/portainer-ce:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:47582->192.168.2.210:53: i/o timeout Found new portainer/portainer-ce:latest image (a1c22f3d250f) Could not do a head request for "ghcr.io/crazy-max/fail2ban:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:40619->192.168.2.210:53: i/o timeout Could not do a head request for "adguard/adguardhome:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:37464->192.168.2.210:53: i/o timeout Stopping /portainer (439b51c93047) with SIGTERM Stopping /plex_PlexMediaServer (476f6d42f77f) with SIGTERM Creating /plex_PlexMediaServer Creating /portainer Removing image 6fd0acb4c97f Removing image bc46de77a3ff Et en copiant/collant ce log... je me rends compte que c'est probablement la résolution DNS qui n'a pas marché... Car 192.168.2.210 c'est mon serveur adguard... Hier j'avais modifié les IP DNS dans DSM pour mettre en 2ème IP celle du routeur, la première étant celle de AdGuard (macvlan). Et pour une raison que j'ignore, ce matin ça a merdé... J'ai tenté là, de mettre que l'IP de mon routeur : pas de soucis cette fois-ci J'ai tenté de repasser sans configurer manuellement le DNS, donc en prenant ce qui est fourni par le serveur DHCP du routeur (donc l'IP de mon AdGuard), et là aussi watchtower n'a pas remonté d'erreurs. (J'ai bien changé le cron pour ce dernier ^^) J'ai remis le DNS personnalisé avec l'IP du routeur. Bref, je ne sais pas ce qu'il s'est passé... je verrais demain. Je vais aller aussi poser ma question sur la dernière MAJ de docker dans le bon sujet ^^ @tout de suite sur l'autre topic. PS : la maj de docker a eu lieu hier soir à 19h30, en même temps que plein d'autres paquets 😉

Haa ok c’est via la page du pms directement 😅 je suppose que tu peux faire confiance mais d’abord tu as installé ton pms comment ? en installant le paquet fourni dans le centre de paquet de dsm ? ou en récupérant sur le site de Plex le spk pour ton nas ?

En ce qui me concerne, vu que suis avec une installation sous Docker, j'ai watchtower qui met à jour tout seul comme un grand l'image fournie par Linuxserver. Donc oui j'ai la version 1.24.4.5081. PS : je ne mets pas à jour avec une version beta 🙂 Tu as récupéré le spk sur quel site ?

Vu les NAS qu'il possède, ce serait probablement une meilleure idée de passer par Docker pour installer Plex 😄

Mon .ovh me coute dans les 3€ par an 😇

Oui tout à fait. Je procédais de la sorte il y a quelques mois. nas1.ndd.tld -> dynhost du nas1 nas2.ndd.tld -> dynhost du nas2 Tu peux même créer des blabla.nas1.ndd.tld

En fait j’utilise une autre méthode pour créer un certificat wildcard (voir tuto docker acme de ce forum ) pour mon nom de domaine ovh : ça passe par une validation dns donc pas besoin des ports 443 et 80. pour mon nom de domaine synology, même si je sais pas vraiment comment il fonctionne, le certificat est aussi renouvelé correctement dans erreurs. pour ton autre question sur le VPN : j’utilise le paquet VPN Plis Server de mon routeur synology. À l’époque où j’utilisais le paquet du nas je crois que je faisais passer par le reverse proxy mais pas sûr à 100%… +1

Peut-être parce que les tests se faisaient avec DoH et FDN n'a pas encore de DoH. Enfin il me semble ^^

Rien de tout ça. Rien n'arrive sur le port 80, donc je ne l'ouvre pas. Dans mon routeur je ne route que le port 443 (et le 6690 pour Drive Server). Je n'accède jamais à mes services en HTTP sur le port 80. Donc ce port n'est pas ouvert sur internet. Je l'ai cependant autorisé pour les IP de mon LAN et les IP FR dans le parefeu du NAS, mais normalement rien n'est censé y accéder. Sauf peut-être un script php que j'avais fait à une époque pour une application. Hmmm, je ne sais pas... ta demande de certificat LE est-elle faite depuis DSM ? Edit : à la reflexion, Free est en France, donc ça doit être normal ^^

Perso le port 80 n'est pas ouvert sur mon routeur. Je fais tout passer par le port 443 et le reverse proxy 🙂 Tu utilises un nom de domaine Synology ? Si oui c'est normal que ça fonctionne même si ton port 443 n'est pas ouvert au monde 🙂 Par contre, si tu utilises un nom de domaine tiers, ça ne devrait pas fonctionner, car LE a besoin d'accéder au port 443 depuis une IP étrangère...

Le port 6690 ce n'est que pour la partie synchronisation du Drive Serveur, donc utilisé avec les clients ordinateurs. Pour l'accès via les applications smartphone, c'est le port défini pour l'application dans DSM, et si tu passes par le reverse proxy, c'est le port externe défini dans le reverse proxy.

@oracle7 par habitude (depuis le DS212) j'ai changé systématiquement les ports des applications (sauf ceux qu'on ne peut pas changer et Plex) 🤪 À l'époque je ne savais pas tout ce que je sais maintenant, mais par la force de l'habitude je continue 😮 😅 Mais je suis d'accord que si tu n'ouvres rien sur le net, pas besoin de changer les ports... 😄

+1 avec @DaffY Il faut ouvrir le port 6690 sur ta box. Tu as bien un certificat LE valide pour ton nom de domaine ? Sur iOS tu as bien mis le nom de domaine et pas l'adresse IP LAN du NAS ?

Oui oui je sais bien 😉 Ce que je voulais dire c'est que depuis DSM 7, je n'avais pas vu ce paquet être mis à jour ^^

Sur mon DSM 7.0.1, j'ai eu ce matin la proposition de MAJ du paquet SMB. Je crois que c'est la première fois que je vois passer une MAJ pour SMB 🙂

Salut 🙂 La même pour moi 🤪

Ouah, tu gardes tous tes certificats 😄 Moi je laisse faire le NAS ou le routeur et ils se débrouillent 😛 Du coup je ne pourrais pas confirmer ou infirmer ce que tu dis précédemment...

Pour les certificats, peut-être que celui généré pour un nom de domaine Synology ne change pas alors que c'est le cas pour un nom de domaine autre ??

Mon certificat s’est renouvelé plusieurs fois depuis que j’ai mis en route OpenVPN sur le routeur et je n’ai pas eu besoin de récréer le fichier ovpn pour mon smartphone… comment ça se fait si le certificat change au renouvellement ?

En ce qui me concerne, c'est le certificat LE du routeur pour mon nom de domaine Synology.

Et pourtant, c'est vraiment léger ^^ 🤣 Économise un mois ou deux de plus ^^ C'est vrai qu'il impose en taille ce RT... j'ai du le mettre au mur, via une cale en bois car il ne pouvait pas rentrer dans mon petit caisson ikea ^^ (je crois que j'ai du mettre quelques photos ^^). Heureusement il est caché par mon canapé ^^

Je n'ai pas tout ça dans mon .ovpn pour iOS... J'ai exporté le fichier sur le RT2600AC et j'ai ajouté la dernière ligne. J'ai donc ceci : dev tun tls-client remote XXXXXXXXXX 1194 # The "float" tells OpenVPN to accept authenticated packets from any address, # not only the address which was specified in the --remote option. # This is useful when you are connecting to a peer which holds a dynamic address # such as a dial-in user or DHCP client. # (Please refer to the manual of OpenVPN for more information.) #float # If redirect-gateway is enabled, the client will redirect it's # default network gateway through the VPN. # It means the VPN connection will firstly connect to the VPN Server # and then to the internet. # (Please refer to the manual of OpenVPN for more information.) redirect-gateway def1 # dhcp-option DNS: To set primary domain name server address. # Repeat this option to set secondary DNS server addresses. #dhcp-option DNS DNS_IP_ADDRESS pull # If you want to connect by Server's IPv6 address, you should use # "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode proto udp script-security 2 reneg-sec 0 auth SHA512 cipher AES-256-CBC auth-user-pass key-direction 1 explicit-exit-notify <ca> -----BEGIN CERTIFICATE----- XXXXXXXXXX -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- XXXXXXXXXX -----END CERTIFICATE----- </ca> <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- XXXXXXXXXX -----END OpenVPN Static key V1----- </tls-auth> setenv CLIENT_CERT 0 Est-ce que l'export via le NAS serait différent ? (hormis ta modif de taille de paquet avec mssfix 1472.

Perso, je ne regrette pas mon choix du RT2600AC 🙂 J'ai suivi le tuto d' @oracle7 pour le mettre en place en conservant l'accès au décodeur TV (voir le lien dans ma signature ^^) via des switchs gérants les VLAN. J'ai pu y placer mon serveur VPN qui peut maintenant bénéficier de mon serveur AdGuard Home (qui fait donc office de serveur DNS). Et j'ai aussi gagné Threat Prevention. Mais surtout j'ai gagné une indépendance vis-à-vis de la livebox pour mon réseau local (wifi compris). Après, le RT est peut-être un peu surdimensionné, mais j'aime bien avoir le meilleur matos 🙂 (en restant chez synology ^^)

ha merde, je pensais que ce serait bon sur VMware workstation 16... mais apparemment ça ne va faire qu'un .OVF... Y a moyen de convertir en OVA après ?

C'est quoi ton "proxy" antpub ? Et où-est-il situé (Sur le NAS, Docker, autre machine réseau) ? Pour ton soucis de connexions simultanées au VPN à partir de deux iPhones, je ne sais pas, je n'ai jamais tenté la manoeuvre... Tu utilises deux comptes différents pour (ou tenter d') établir la connexion ?