Anomalie #6481
ferméProblème de résolution de nom via le VPN, impossibilité pour Elsa d'envoyer un courriel
0%
Description
Elsa a commencé lundi son télétravail à Lyon ce matin, le VPN a démarré automatiquement.
Elle s'est rendu compte qu'elle pouvait récupérer ses courriels avec Thunderbird mais pas possible d'envoyer un courriel.
Après investigation, je me suis rendu compte que depuis son laptop pour smtp.april.org l'adresse était 172.16.0.4 qui est donc l'adresse locale de la VM dans le SI April, et non pas l'adresse publique. Même chose pour mail.april.org.
Par contre, imap.april.org renvoie bien la bonne IP 176.9.141.91.
Ce qui explique qu'elle peut recevoir des courriels mais pas en envoyer.
Je lui ai dit de remplacer smtp.april.org par imap.april.org dans Thunderbird. Elle peut de nouveau envoyer des courriels.
Mais ce serait bien de comprendre pourquoi smtp.april.org et mail.april.org renvoient l'IP de la VM quand le VPN est démarré sur un laptop. Il y a le même comportement sur Guarana.
Theo me dit :
[07/22/24 16:31] <theocrite> Dans la zone interne (/etc/bind/zones/masters/april.org-int) smtp est un CNAME vers mail et dans la zone publique mail et smtp sont des CNAMES vers vip. Il faut voir si c'est ce que l'on veut.
Mis à jour par Frédéric Couchet il y a 4 mois
J'ai demandé à Etienne de faire la même modification sur son courielleur (Evolution).
Mis à jour par Frédéric Couchet il y a 4 mois
Etienne a eu de nouveau un problème avec Evolution mais pour les courriels entrants. Il était chez lui, avec le VPN démarré automatiquement. Dans la configuration d'Evolution pour le serveur entrant c'était mail.april.org. Il a modifié en imap.april.org ce qui a résolu le souci.
J'ai tout de même désactivé le démarrage automatique du VPN :
~# systemctl list-dependencies --reverse openvpn@april-vpn.service openvpn@april-vpn.service ● ├─openvpn.service ● └─multi-user.target ● └─graphical.target ~# systemctl is-enabled openvpn@april-vpn.service enabled ~# systemctl is-enabled openvpn.service enabled ~# systemctl disable openvpn.service Synchronizing state of openvpn.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable openvpn insserv: warning: current start runlevel(s) (empty) of script `openvpn' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `openvpn' overrides LSB defaults (0 1 6). Removed "/etc/systemd/system/multi-user.target.wants/openvpn.service". root@passiflora:~# systemctl disable openvpn.service Synchronizing state of openvpn.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable openvpn insserv: warning: current start runlevel(s) (empty) of script `openvpn' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `openvpn' overrides LSB defaults (0 1 6). insserv: warning: current start runlevel(s) (empty) of script `openvpn' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `openvpn' overrides LSB defaults (0 1 6). ~# systemctl disable openvpn@april-vpn.service Removed "/etc/systemd/system/multi-user.target.wants/openvpn@april-vpn.service". root@passiflora:~# systemctl is-enabled openvpn.service disabled ~# systemctl is-enabled openvpn.service disabled ~# systemctl is-enabled openvpn@april-vpn.service enabled-runtime
On a testé qu'Etienne peut démarrer le VPN manuellement.
Mis à jour par Frédéric Couchet il y a 3 mois
Même modification faite sur le laptop d'Isabella.
Mis à jour par Frédéric Couchet il y a 3 mois
- Statut changé de Nouveau à Résolu
- Version cible changé de Backlog à Été 2024