Re: Monitorer la connectivité WAN en vue du re-routage
Le 25 août 2023 Olivier a écrit : > 1. Connaissez-vous un document qui justifie techniquement ces > "questions de sécurité" ? La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent au ping. Si tu fais un traceroute tu le vois bien. > Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser > le HTTP et lire les réponses retournées pour estimer l'état de la > connectivité Internet". J'imagine que plusieurs gros acteurs > d'Internet ont mis en place ce genre de moyens. Oui une requête http vers www.google.com qui t'indique que c'est bon et aussi le temps de réponse donc la qualité "réelle" du réseau. Mais par contre ça ne t'indiquera pas les machines intermédiaires qui seraient HS. > 2. Quelles machines et quels outils (installables sur Debian) peut-on > librement utiliser pour estimer l'état de la connectivité Internet" ? nagios fait ça très bien mais c'est un peu long à configurer donc ça dépend de l'investissement que tu es prêt à mettre sinon tu fais un traceroute et tu analyses le résultat pour un truc comme ça j'utilise le paquet mtr-tiny mtr -c 1 -r www.google.com
Re: Serveur OpenVPN
Trouvé. C'est l'option comp-lzo qui met le bazar. Je l'avais sur les deux machines clientes (l'une est sur un accès Wanadoo-Santé de 512 kbps, si, si, ça existe /encore/), l'autre sur un accès GPRS. Je n'avais pas cette option côté serveur. Visiblement, jusqu'à la dernière version d'OpenVPN, le chiffrement asymétrique était autorisé. Là, même en l'autorisant explicitement, ça ne fonctionnait pas. Donc suppression des deux comp-lzo sur les clients et ça fonctionne à nouveau. JKB
Serveur OpenVPN
Bonjour à tous, J'ai un petit souci avec un serveur OpenVPN (qui fonctionnait parfaitement jusqu'ici). Les clients se connectent bien sur le serveur mais rien ne passe sur l'interface tap0. Je n'ai rien de particulier dans les sorties d'OpenVPN (même avec verb=10). Le serveur est sur une machine régulièrement mise à jour. Les clients vivent leur vie et sont mis à jour nettement moins souvent (ça ne dépend pas de moi). Lorsque je lance le serveur, je trouve ceci : 2023-08-25 16:58:39 86.212.205.101:58146 TLS: Initial packet from [AF_INET]86.212.205.101:58146, sid=b28dac4a 65656374 2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=1, C=FR, ST=FR, L=Paris, O=Systella, CN=Systella CA, emailAddress=joel.bertr...@systella.fr 2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=0, C=FR, ST=FR, L=Paris, O=Systella, CN=cervantes, emailAddress=joel.bertr...@systella.fr 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_VER=2.4.6 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PLAT=linux 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PROTO=2 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_NCP=2 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4v2=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZO=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUB=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUBv2=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_TCPNL=1 2023-08-25 16:58:40 86.212.205.101:58146 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1 2023-08-25 16:58:40 86.212.205.101:58146 TLS: tls_multi_process: initial untrusted session promoted to trusted 2023-08-25 16:58:40 86.212.205.101:58146 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA1 2023-08-25 16:58:40 86.212.205.101:58146 [cervantes] Peer Connection Initiated with [AF_INET]86.212.205.101:58146 2023-08-25 16:58:40 cervantes/86.212.205.101:58146 MULTI_sva: pool returned IPv4=192.168.2.2, IPv6=(Not enabled) 2023-08-25 16:58:40 cervantes/86.212.205.101:58146 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/cervantes 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Data Channel: cipher 'AES-256-GCM', peer-id: 0 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Timers: ping 10, ping-restart 240 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 PUSH: Received control message: 'PUSH_REQUEST' 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 SENT CONTROL [cervantes]: 'PUSH_REPLY,route-gateway 192.168.2.1,ping 10,ping-restart 120,ifconfig 192.168.2.5 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1) 2023-08-25 16:58:51 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:58:56 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:00 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:06 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:10 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:17 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:21 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:26 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:31 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:36 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:41 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:46 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:50 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:57 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:00 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 17:00:07 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:11 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 17:00:17 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:21 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0
Re: Monitorer la connectivité WAN en vue du re-routage
Bonjour, J'ai plusieurs installations qui bénéficient de plusieurs liens vers Internet. J'aimerai savoir détecter à peu près en continu (détecter et basculer en 5 minutes) les pannes et rétablissements de ces liens. Une première méthode très simple consiste à envoyer un ping au routeur fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS. S'il répond à nouveau, on considère que le lien (re-)fonctionne. Malheureusement, cette méthode laisse passer les cas (assez fréquents) où c'est le lien en amont du routeur de l'ISP qui est HS (ce routeur est sur site). J'observe que mon ISP invoque des "questions de sécurité" pour que par défaut, son routeur ne réponde jamais au ping. En le suppliant, il a déjà accepté de changer ce réglage mais pour combien de temps ? 1. Connaissez-vous un document qui justifie techniquement ces "questions de sécurité" ? Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser le HTTP et lire les réponses retournées pour estimer l'état de la connectivité Internet". J'imagine que plusieurs gros acteurs d'Internet ont mis en place ce genre de moyens. 2. Quelles machines et quels outils (installables sur Debian) peut-on librement utiliser pour estimer l'état de la connectivité Internet" ? Slts Le ven. 25 août 2023 à 16:32, Olivier a écrit : > > Désolé, le message précédent est parti sans être terminé. Le bon va > bientôt suivre. > > Le ven. 25 août 2023 à 16:31, Olivier a écrit : > > > > Bonjour, > > > > J'ai plusieurs installations qui bénéficient de plusieurs liens en > > fibre vers Internet. > > J'aimerai savoir détecter à peu près en continu les pannes et > > rétablissements de ces liens. > > > > Une première méthode très simple consiste à envoyer un ping au routeur > > fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS. > > S'il répond à nouveau, on considère que le lien fonctionne. > > Malheureusement, cette méthode laisse passer (assez fréquents) ou > > c'est le lien en amont du routeur de l'ISP qui est HS. > > > > J'observe que mon ISP invoque des "questions de sécurité" pour que par > > défaut, son routeur ne réponde jamais les réponses au ping. En le > > suppliant, il accepte de changer ce réglage mais pour combien de temps > > ? > > > > Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser > > le HTTP pour questionner des machines sur l'état de leur > > connectivité". > > > > > > 1. Connaissez-vous un document qui justifie techniquement ces > > "questions de sécurité" ? > > > > 2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le > > HTTP pour questionner l'état des machines sur
Re: Monitorer la connectivité WAN en vue du re-routage
Désolé, le message précédent est parti sans être terminé. Le bon va bientôt suivre. Le ven. 25 août 2023 à 16:31, Olivier a écrit : > > Bonjour, > > J'ai plusieurs installations qui bénéficient de plusieurs liens en > fibre vers Internet. > J'aimerai savoir détecter à peu près en continu les pannes et > rétablissements de ces liens. > > Une première méthode très simple consiste à envoyer un ping au routeur > fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS. > S'il répond à nouveau, on considère que le lien fonctionne. > Malheureusement, cette méthode laisse passer (assez fréquents) ou > c'est le lien en amont du routeur de l'ISP qui est HS. > > J'observe que mon ISP invoque des "questions de sécurité" pour que par > défaut, son routeur ne réponde jamais les réponses au ping. En le > suppliant, il accepte de changer ce réglage mais pour combien de temps > ? > > Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser > le HTTP pour questionner des machines sur l'état de leur > connectivité". > > > 1. Connaissez-vous un document qui justifie techniquement ces > "questions de sécurité" ? > > 2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le > HTTP pour questionner l'état des machines sur
Monitorer la connectivité WAN en vue du re-routage
Bonjour, J'ai plusieurs installations qui bénéficient de plusieurs liens en fibre vers Internet. J'aimerai savoir détecter à peu près en continu les pannes et rétablissements de ces liens. Une première méthode très simple consiste à envoyer un ping au routeur fourni par l'ISP: s'il ne répond pas, on considère que le lien est HS. S'il répond à nouveau, on considère que le lien fonctionne. Malheureusement, cette méthode laisse passer (assez fréquents) ou c'est le lien en amont du routeur de l'ISP qui est HS. J'observe que mon ISP invoque des "questions de sécurité" pour que par défaut, son routeur ne réponde jamais les réponses au ping. En le suppliant, il accepte de changer ce réglage mais pour combien de temps ? Par ailleurs, il me semble avoir déjà lu qu'il "valait mieux utiliser le HTTP pour questionner des machines sur l'état de leur connectivité". 1. Connaissez-vous un document qui justifie techniquement ces "questions de sécurité" ? 2. Plutôt que le ping, j'ai compris qu'il valait mieux utiliser le HTTP pour questionner l'état des machines sur
