Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

polinux · Le 03/01/2024, à 23:19

Bonjour à tous,
pour ma société j'utilise Laurux pour la comptabilité et pour que ma fille puisse faire du télétravail j'ai donc mis en place un serveur VPN pour qu'elle puisse se connecter en sécurité sur mon pc qui est le serveur.
Elle n'arrive pas à faire partir les emails de facturation depuis son pc distant.
Est ce le serveur VPN qui peut bloquer l'envoi ?
Merci d'avance pour votre aide.

Paul

Dernière modification par polinux (Le 11/01/2024, à 13:59)

NicoApi73 · Le 05/01/2024, à 21:26

Bonjour,

Donne les retours pour le serveur de :

cat /etc/sysctl.conf | grep ip_forward
ip a
ip route
iptables -L -t nat
cat /etc/openvpn/server/server.conf | grep ^push
cat /etc/openvpn/server/server.conf | grep ^server

Donne les retours pour le client de :

ip route

Quel est le fournisseur de la messagerie (gmail, orange...)?
Quel est le client de messagerie utilisé?
Est ce que la navigation sur internet fonctionne?

polinux · Le 09/01/2024, à 09:16

facon-piscine@facon-piscine:~$ cat /etc/sysctl.conf | grep ip_forward
#net.ipv4.ip_forward=1
facon-piscine@facon-piscine:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d4:5d:64:b9:8e:b2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.30/24 brd 192.168.0.255 scope global dynamic noprefixroute enp5s0
       valid_lft 40380sec preferred_lft 40380sec
    inet6 2a01:e0a:5db:5270:b8c4:657e:a993:57b9/64 scope global temporary dynamic 
       valid_lft 86062sec preferred_lft 83081sec
    inet6 2a01:e0a:5db:5270:4226:c94a:d40e:28e9/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86062sec preferred_lft 86062sec
    inet6 fe80::9e94:7216:8a7d:2a4b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::ac61:3766:e9f8:383c/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
4: enxaaabb51ae7a0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether aa:ab:b5:1a:e7:a0 brd ff:ff:ff:ff:ff:ff
facon-piscine@facon-piscine:~$ ip route
default via 192.168.0.254 dev enp5s0 proto dhcp metric 100 
10.8.0.0/24 via 10.8.0.2 dev tun0 
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 
169.254.0.0/16 dev enp5s0 scope link metric 1000 
192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.30 metric 100 
facon-piscine@facon-piscine:~$ iptables -L -t nat
iptables v1.8.7 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root)

facon-piscine@facon-piscine:~$ cat /etc/openvpn/server/server.conf | grep ^push
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
facon-piscine@facon-piscine:~$ cat /etc/openvpn/server/server.conf | grep ^server
server 10.8.0.0 255.255.255.0
facon-piscine@facon-piscine:~$

polinux · Le 09/01/2024, à 09:21

Bonjour et merci pour ton aide,
alors le fournisseur de messagerie est OVH ce sont les emails de mon domaine.
le client messagerie est thunderbird
la navigation internet fonctionne.
Pour le retour de "ip route" sur le client faut il qu'il soit connecté par VPN ?

NicoApi73 · Le 09/01/2024, à 10:06

Bonjour,

Pour les manip sur le client, oui, il faut qu'il soit connecté au VPN.

Sur le serveur, donne le retour de :

cat /etc/sysctl.conf | grep forward
sudo iptables -L -t nat

matrix-bx · Le 09/01/2024, à 14:04

Salut NicoApi73,

[hors sujet]
l'avantage de jouer parfois avec un MacBookAir sous Ubuntu, c'est que n'ayant pas de touche "|" (faut faire "Shift + Alt droit + L" et j'ai bien du mal à m'en souvenir), je retrouve très vite l'habitude de faire:

grep forward /etc/sysctl.conf

[/hors sujet]

NicoApi73 · Le 09/01/2024, à 14:27

@matrix-bx,

bonjour,

J'ai pris la (mauvaise) habitude de faire 2 commandes en utilisant cat, nany m'a déjà pointé cette possibilité et mon habitude est revenue au galop

Je vais essayer d'utiliser plus efficacement grep

polinux · Le 10/01/2024, à 00:20

facon-piscine@facon-piscine:~$ cat /etc/sysctl.conf | grep forward
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
#net.ipv6.conf.all.forwarding=1
facon-piscine@facon-piscine:~$ sudo iptables -L -t nat
[sudo] Mot de passe de facon-piscine : 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.8.0.0/24          anywhere            
facon-piscine@facon-piscine:~$ grep forward /etc/sysctl.conf 
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
#net.ipv6.conf.all.forwarding=1
facon-piscine@facon-piscine:~$

polinux · Le 10/01/2024, à 00:31

facon3@facon3-Inspiron-15-3511:~$ ip route
default via 10.8.0.5 dev tun0 proto static metric 50 
default via 192.168.1.1 dev wlp1s0 proto dhcp metric 600 
10.8.0.1 via 10.8.0.5 dev tun0 proto static metric 50 
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 metric 50 
*.*.*.* via 192.168.1.1 dev wlp1s0 proto static metric 50 
169.254.0.0/16 dev wlp1s0 scope link metric 1000 
192.168.0.0/24 via 10.8.0.5 dev tun0 proto static metric 50 
192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.xxxxxxxxx metric 600 
192.168.1.1 dev wlp1s0 proto static scope link metric 50 
facon3@facon3-Inspiron-15-3511:~$

(IP publique masquée)

Dernière modification par polinux (Le 10/01/2024, à 22:33)

polinux · Le 10/01/2024, à 00:38

voila c'est fait, par curiosité j'ai fais les 2 commandes et il y a le même résultat

par contre coté client ma fille à du déconnecter le VPN pour naviguer car elle n'avait pas de connexion, préparer la commande sur le terminal
puis se connecter au VPN pour lancer la commande puis de déconnecter à nouveau pour poster le résultat sur le forum.
pour info lorsqu'elle travail sur la compta avec le VPN c'est vraiment très très lent.

NicoApi73 · Le 10/01/2024, à 08:06

Bonjour,

Dans le #9 apparaît ton adresse IP extérieure, remplace la par xx.xx.xx.xx, je n'aime pas que ce genre d'information personnelle apparaisse en clair.

Le problème vient du fait que l'IP forwarding n'est pas activé côté serveur et que le tout trafic est poussé dans le tunnel (en fait dans ta configuration, seul le trafic IPV4 l'est).

Par conséquent, tu peux accéder depuis le client a tout ce qui est en IPV6, mais pas ce qui est en IPV4. Par exemple, tu arriveras à joindre www.google.com (qui est en IPV4 et IPV6), mais pas le forum ou ovh (qui ne sont qu'en IPV4).

Je te donne dans la journée les commandes pour corriger ça, n'étant pas familier de sed

Dernière modification par bruno (Le 10/01/2024, à 09:19)

NicoApi73 · Le 10/01/2024, à 09:49

Merci Bruno.

Voici les modifications à apporter côté server :

sudo sed -i "s/\#net.ipv4.ip_forward/net.ipv4.ip_forward/g;s/\#net.ipv6.conf.all.forward/net.ipv6.conf.all.forward/g" /etc/sysctl.conf
grep forward /etc/sysctl.conf
sudo sysctl -p
sudo sed -i "s/push \"redirect-gateway def1 bypass-dhcp/;push \"redirect-gateway def1 bypass-dhcp ipv6/g" /etc/openvpn/server/server.conf
grep redirect-gateway /etc/openvpn/server/server.conf
sudo systemctl restart openvpn-server@server.service

Ces modifications consistent en :
- activer l'ip forwarding (ce qui aurait dû être fait)
- ne plus demander aux clients de pousser tout le trafic dans le tunnel, ce n'est pas nécessaire dans ton cas.

Donne bien tous les retours.

Dernière modification par NicoApi73 (Le 10/01/2024, à 22:44)

polinux · Le 10/01/2024, à 22:32

acon-piscine@facon-piscine:~$ sudo sed -i "s/\#net.ipv4.ip_forward/net.ipv4.ip_forward/g;s/\#net.ipv6.conf.all.forward/net.ipv6.conf.all.forward/g" /etc/sysctl.conf
[sudo] Mot de passe de facon-piscine : 
facon-piscine@facon-piscine:~$ forward /etc/sysctl.conf
forward : commande introuvable
facon-piscine@facon-piscine:~$ sed -i "s/\#net.ipv4.ip_forward/net.ipv4.ip_forward/g;s/\#net.ipv6.conf.all.forward/net.ipv6.conf.all.forward/g" /etc/sysctl.conf 
grep forward /etc/sysctl.conf
sed: impossible d'ouvrir le fichier temporaire /etc/sedneKnlt: Permission non accordée
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1
facon-piscine@facon-piscine:~$ sysctl -p
sysctl: permission refusée sur la clé « net.ipv4.ip_forward »ignorée
sysctl: permission refusée sur la clé « net.ipv6.conf.all.forwarding »ignorée
facon-piscine@facon-piscine:~$ i "s/push \"redirect-gateway def1 bypass-dhcp/;push \"redirect-gateway def1 bypass-dhcp ipv6/g" /etc/openvpn/server/server.conf
i : commande introuvable
facon-piscine@facon-piscine:~$

Je fais déjà ces retours j'ai l'impression que je n'ai pas copié les commandes comme il faut

dans le #9 ai je bien masqué la bonne adresse ?

Dernière modification par polinux (Le 10/01/2024, à 22:34)

NicoApi73 · Le 10/01/2024, à 22:47

J'avais oublié un sudo sur une commande.

Copie les commandes une à une,

Reprends les commandes suivantes, la première semble avoir été passée :

grep forward /etc/sysctl.conf
sudo sysctl -p
sudo sed -i "s/push \"redirect-gateway def1 bypass-dhcp/;push \"redirect-gateway def1 bypass-dhcp ipv6/g" /etc/openvpn/server/server.conf
grep redirect-gateway /etc/openvpn/server/server.conf
sudo systemctl restart openvpn-server@server.service

polinux · Le 10/01/2024, à 23:05

facon-piscine@facon-piscine:~$ grep forward /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1
facon-piscine@facon-piscine:~$ sudo sysctl -p
[sudo] Mot de passe de facon-piscine : 
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
facon-piscine@facon-piscine:~$ sudo sed -i "s/push \"redirect-gateway def1 bypass-dhcp/;push \"redirect-gateway def1 bypass-dhcp ipv6/g" /etc/openvpn/server/server.conf
facon-piscine@facon-piscine:~$ grep redirect-gateway /etc/openvpn/server/server.conf
;push "redirect-gateway def1 bypass-dhcp ipv6"
facon-piscine@facon-piscine:~$ sudo systemctl restart openvpn-server@server.service
facon-piscine@facon-piscine:~$

c'est fait voici le retour

NicoApi73 · Le 10/01/2024, à 23:21

C'est bon, ta fille peut essayer maintenant. Elle devrait pouvoir continuer à joindre ton serveur et le trafic qui n'est pas à destination de ton réseau local ne passera pas par le tunnel VPN.

EDIT : Remarque : Ton VPN est configuré pour un réseau client sécurisé et pas pour une utilisation à partir d'un hotspot public. Dans ce dernier cas, il faut décommenter la ligne ";push "redirect-gateway def1 bypass-dhcp ipv6"" en retirant le ";" et redémarrer le serveur. De ce que j'ai compris, ça ne te concerne pas

Dernière modification par NicoApi73 (Le 11/01/2024, à 08:48)

polinux · Le 11/01/2024, à 13:56

Ok super je te remercie pour ton aide
Bonne année

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/01/2024, à 23:19

Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#2 Le 05/01/2024, à 21:26

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#3 Le 09/01/2024, à 09:16

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#4 Le 09/01/2024, à 09:21

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#5 Le 09/01/2024, à 10:06

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#6 Le 09/01/2024, à 14:04

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#7 Le 09/01/2024, à 14:27

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#8 Le 10/01/2024, à 00:20

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#9 Le 10/01/2024, à 00:31

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#10 Le 10/01/2024, à 00:38

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#11 Le 10/01/2024, à 08:06

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#12 Le 10/01/2024, à 09:49

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#13 Le 10/01/2024, à 22:32

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#14 Le 10/01/2024, à 22:47

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#15 Le 10/01/2024, à 23:05

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#16 Le 10/01/2024, à 23:21

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

#17 Le 11/01/2024, à 13:56

Re : Impossibilité d'envoyer 1 mail sur un poste distant via VPN [RESOLU]

Pied de page des forums