Openvpn
Problème sur ./build-ca
Logiciels / Logiciels Internet
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Reprise du message précédent
J'ai créé le fichier sysctl.conf avec la ligne net.ipv4.ip_forward = 1J'ai déroulé la suite, mais la log openvpn n'est pas tout à fait celle du tutoriel et je ne sais pas ce qu'il en est. Je joins le fichier dessous:
8-var-log-openvpn-log.txt
J'ai quand même continué, l'interface tun0 est présente sur le serveur mais ensuite au lancement du client vpn, ça plante ...
Caché :
[root@localhost openvpn]# openvpn --config /etc/openvpn/clientmga.ovpn
2021-01-30 01:26:05 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Options error: Unrecognized option or missing or extra parameter(s) in /etc/openvpn/clientmga.ovpn:15: mute (2.5.0)
Use --help for more information.
[root@localhost openvpn]#
2021-01-30 01:26:05 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Options error: Unrecognized option or missing or extra parameter(s) in /etc/openvpn/clientmga.ovpn:15: mute (2.5.0)
Use --help for more information.
[root@localhost openvpn]#
Je joins ci-dessous le fichier /etc/openvpn/clientmga.ovpn
clientmga.ovpn.txt
Je précise que chez moi le nom du serveur mga qui s'appelle serveurmga dans le tutoriel s'appelle chez moi serveurmga-porpompa mais j'ai remplacé à chaque fois que j'ai trouvé serveurmga par serveurmga-porpompa.
Voilà, pour le moment je vais aller dans les bras de morphée ...
pour votre aide. 
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Visiblement le serveur semble se lancer avec cependant quelques avertissements concernant le paramètre topology ( net30 au lieu de subnet ( mais net30 semble être toujours le défaut puisque non spécifié explicitement dans le fichier de configuration) et l' encryption ( AES-128-CBC qui ne serait pas disponible ( visiblement sur la version 2.5, le chiffrement par défaut est le AES-256-CBC, on pourrait donc remplacer dans le fichier de conf, la ligne cipher AES-128-CBC par AES-256-CBC, surtout s' il n' y a pas de vieux client openvpn qui devraient se connecter à ce serveur), mais cela n' irait probablement pas puisque la --data-cipher contient uniquement AES-256-GCM:AES-128-GCM, il faudrait donc mettre plutôt une de ces deux valeurs .
Sans avoir regarder la syntaxe d' un fichier openvpn client, je pense que qu' il manque un retour à la ligne au niveau du "mute 20script-security 2", je verrais plus
mute 20
script-security 2
Si dans le fichier de configuration du serveur on change le cipher, il faut également mettre le même dans la configuration du client sinon client et serveur ne pourront pas communiquer ( pas d' algorithme de chiffrement commun).
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
nic80 :
mute 20
script-security 2
script-security 2
Bon ça j'ai modifié et passé comme ceci sur 2 lignes car effectivement ce n'était que sur une ligne, mais je n'ai rien touché d'autre.
Sur le client je lance openvpn et là ça semble déjà mieux, mais, car il y a un mais ...
bon on peut plaisanter un peu aussi ...Donc openvpn lancé le voici ci-dessous:
Caché :
openvpn --config /etc/openvpn/clientmga.ovpn
2021-01-30 12:15:41 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-01-30 12:15:41 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-30 12:15:41 OpenVPN 2.5.0 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 9 2020
2021-01-30 12:15:41 library versions: OpenSSL 1.1.1i 8 Dec 2020, LZO 2.10
2021-01-30 12:15:41 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
2021-01-30 12:15:41 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Enter Private Key Password: ******************
2021-01-30 12:15:54 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-01-30 12:15:54 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.64:1194
2021-01-30 12:15:54 UDP link local: (not bound)
2021-01-30 12:15:54 UDP link remote: [AF_INET]192.168.1.64:1194
2021-01-30 12:15:55 [serveurmga-porpompa] Peer Connection Initiated with [AF_INET]192.168.1.64:1194
2021-01-30 12:15:55 TUN/TAP device tun0 opened
2021-01-30 12:15:55 net_iface_mtu_set: mtu 1500 for tun0
2021-01-30 12:15:55 net_iface_up: set tun0 up
2021-01-30 12:15:55 net_addr_ptp_v4_add: 10.8.0.10 peer 10.8.0.9 dev tun0
2021-01-30 12:15:55 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.8.0.10 10.8.0.9 init
dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220
2021-01-30 12:15:55 Initialization Sequence Completed
2021-01-30 12:15:41 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-01-30 12:15:41 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-30 12:15:41 OpenVPN 2.5.0 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 9 2020
2021-01-30 12:15:41 library versions: OpenSSL 1.1.1i 8 Dec 2020, LZO 2.10
2021-01-30 12:15:41 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
2021-01-30 12:15:41 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Enter Private Key Password: ******************
2021-01-30 12:15:54 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-01-30 12:15:54 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.64:1194
2021-01-30 12:15:54 UDP link local: (not bound)
2021-01-30 12:15:54 UDP link remote: [AF_INET]192.168.1.64:1194
2021-01-30 12:15:55 [serveurmga-porpompa] Peer Connection Initiated with [AF_INET]192.168.1.64:1194
2021-01-30 12:15:55 TUN/TAP device tun0 opened
2021-01-30 12:15:55 net_iface_mtu_set: mtu 1500 for tun0
2021-01-30 12:15:55 net_iface_up: set tun0 up
2021-01-30 12:15:55 net_addr_ptp_v4_add: 10.8.0.10 peer 10.8.0.9 dev tun0
2021-01-30 12:15:55 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.8.0.10 10.8.0.9 init
dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220
2021-01-30 12:15:55 Initialization Sequence Completed
Bon ça ressemble pas mal au tutoriel avec quelques différences, mais il ne rend pas la main !!! je ne sais pas si c'est normal ?!!
Je suis donc obligé de lancer une autre console sur le client pour faire un ifconfig -a qui me montre bien l'interface tun0
Donc ça ça à l'air bon.
Ensuite dans le tutoriel il est dit:
"Sur le serveur, on voit la connexion s'établir :"
Perso je ne vois rien mais peut-être qu'il faudrait passer une commande ?!!!
Ensuite voici ce que donne traceroute:
Caché :
root@allinone-mageia8-beta2 robert]# traceroute www.mageialinux-online.org
traceroute to www.mageialinux-online.org (80.247.225.3), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 2.883 ms 3.087 ms 3.482 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@allinone-mageia8-beta2 robert]#
traceroute to www.mageialinux-online.org (80.247.225.3), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 2.883 ms 3.087 ms 3.482 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@allinone-mageia8-beta2 robert]#
Puis nslookup:
Caché :
[root@allinone-mageia8-beta2 robert]# nslookup mageialinux-online.org
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: mageialinux-online.org
Address: 80.247.225.3
[root@allinone-mageia8-beta2 robert]#
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: mageialinux-online.org
Address: 80.247.225.3
[root@allinone-mageia8-beta2 robert]#
Donc là tout ne doit pas être bon ... mais quand j'ai voulu valider ce message ça a mouliné terrible et partout où je voulais aller sur internet ça moulinait je n'avais rien, j'ai dû arrêter openvpn pour envoyer le message ce qui voudrait dire que je vais bien vers mon serveur openvpn mais ça marche poooos !!!! ...
En tous cas merci pour ton aide, je vais essayer de voir pourquoi ça ne marche pas.
Visiteur
Dans son message du 25/01/2021 à 19h03 "nic80" a bien supputé le problème, je pense :
nic80 :
Or chez moi openssl retourne
usr/bin/openssl version
OpenSSL 1.1.0l 10 Sep 2019
Donc c' est forcément un openssl.cnf qui est retourné. Mais celui ci n' existe pas !
usr/bin/openssl version
OpenSSL 1.1.0l 10 Sep 2019
Donc c' est forcément un openssl.cnf qui est retourné. Mais celui ci n' existe pas !
...et ce n'est donc qu'une question de pure spéculation de ma part : Ne s'agirait-il pas du même problème que "GoogleEarth" et "megasync" sur la Mageai8 ?
Il semblerait que "libssl" et/ou "libcrypto" et/ou "lib64curl4", dans leur version présente sur la M8, ne laissent pas fonctionner certains programmes.
Dans le bug que j'ai déclaré pour GoogleEarth, il est fait mention par les devs de la version de "libssl" sur cette M8 !
A+
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Nulix :
...et ce n'est donc qu'une question de pure spéculation de ma part : Ne s'agirait-il pas du même problème que "GoogleEarth" et "megasync" sur la Mageai8 ?
Il semblerait que "libssl" et/ou "libcrypto" et/ou "lib64curl4", dans leur version présente sur la M8, ne laissent pas fonctionner certains programmes.
Il semblerait que "libssl" et/ou "libcrypto" et/ou "lib64curl4", dans leur version présente sur la M8, ne laissent pas fonctionner certains programmes.
Ah ... !!! je ne sais pas, tu as peut-être raison ... cependant
nic80 :
Donc c' est forcément un openssl.cnf qui est retourné. Mais celui ci n' existe pas !
pour ceci, nic80 m'avait indiqué de créer le lien symbolique suivant:
Caché :
ln -s openssl-1.0.0.cnf openssl.cnf
Après ça, l'étape suivante avait fonctionné, donc j'ai continué sur la lancée à suivre le tutoriel en question et j'en suis arrivé à lancer openvpn client, et là il y a les trucs que je décris dans mon message précédent qui ne marchent pas. Voilà, je ne peux pas en dire plus ...
pour votre aide.
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Pour la non libération, je dirais que c' est normal... Il faut bien un programme pour gérer la connexion vpn ( il y a peut être une option pour le faire fonctionner en arrière plan).
J' ai l' impression qu' openvpn crée une nouvelle route par défaut, d'où le 10.8.0.1 en tant que premier saut mais qu' ensuite il ne sait plus où aller.
Est ce que quand le tunnel est établi, on peut pinguer le serveur ?
Si oui, c' est probablement que le serveur vpn ne trouve pas le saut suivant.
Le ip forwarding est bien actif sur le serveur ?
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
nic80 :
Est ce que quand le tunnel est établi, on peut pinguer le serveur ?
Voici le résultat du ping:
Caché :
[root@allinone-mageia8-beta2 robert]# ping 192.168.1.64
PING 192.168.1.64 (192.168.1.64) 56(84) octets de données.
PING 192.168.1.64 (192.168.1.64) 56(84) octets de données.
nic80 :
Le ip forwarding est bien actif sur le serveur ?
Sur le serveur la commande:
cat /proc/sys/net/ipv4/ip_forward
m'a renvoyé 0 donc j'ai fait:
echo 1 > /proc/sys/net/ipv4/ip_forward ensuite la commande cat /proc/sys/net/ipv4/ip_forward m'a renvoyé 1
J'ai fait pareil au niveau du fichier /etc/sysctl.conf,
[root@porpompa-mageia8-beta2 robert]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
J'ai mis 1 dedans
root@porpompa-mageia8-beta2 robert]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
J'avoue que je ne sais pas très bien ce qui compte si c'est le fichier /etc/sysctl.conf ou /proc/sys/net/ipv4/ip_forward
J'ai pris cette doc:
Bref j'ai mis 1 dans les 2 fichiers, j'ai relancé mais c'est pareil ...
Je précise que mon routeur (portable mageia8 bêta 2) est à côté de moi mais je travaille dessus depuis mon ordi de bureau car j'avais établi une connection ssh depuis des lustres sur ce protable. J'espère que ça ne met pas la grouille !! donc au bénéfice du doute, j'ai fait tomber cette liaison ssh et j'ai relancé mais c'est pareil.
Bon, s'il faut je peux reprendre toute la configuration depuis le début, si j'ai bien compris un coup de source vars réinitialise toutes les clés et c'est reparti, bon je vais voir, avant je vais essayer de débugger ma configuration.
pour toutes ces infos. Édité par zatox Le 30/01/2021 à 18h53
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je ne pense pas que le serveur openvpn ait une adresse en 192.168.x.x ... En effet, l' échange entre les deux protagoniste devraient se faire sur le réseau 10.8.0.x.
En effet le tunnel vpn se fait au dessus des adresses de cartes physique, les deux réseaux distants pouvant avoir des sous réseaux différents (ce qui est pŕeférable il me semble...)
Je pense qu' à l' établissement de la connexion vpn une route supplémentaire est ajoutée permettant de passer du trafic sur le réseau 10.8.0.x et forcément si le tunnel est monté les deux hôtes doivent pouvoir se pinguer sur l' adresse ip de leur interface tun respective.
Il faudra que je teste si ce que j' écris est juste ou non
Edit: sysctl au travers de ses fichiers .conf permet de changer l' ip forward, il me semble.
Édité par nic80 Le 30/01/2021 à 19h51
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
nic80 :
Je ne pense pas que le serveur openvpn ait une adresse en 192.168.x.x ... En effet, l' échange entre les deux protagoniste devraient se faire sur le réseau 10.8.0.x.
Est-ce que tu veux dire qu'il faudrait que je ping l'adrese 10.8.0.x du destinataire ?
nic80 :
Il faudra que je teste si ce que j' écris est juste ou non
Si je peux faire un test pas de problème mais faudrait que tu me dises quoi exactement car je ne suis pas au top question réseau, mais ça m'intéresse d'arriver à faire marcher ce vpn.
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je soupçonne un problème de parefeu sur la machine qui héberge le serveur Openvpn ( d' après mes tests)...
Que ce passe t' il si on désactive le parfeu complétement de façon à ce que la commande iptables -L ( lancée en root sur le serveur) retourne ceci:
Code BASH :
[root@Mageia8 easy-rsa]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@Mageia8 easy-rsa]#
Et lorsque c' est dans cet état on lance la commande qui gère la table nat ( où l'on prend soin de modifier l' interface wl0 je crois dans notre cas :
Citation :
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp0s3 -j MASQUERADE
le ping ou le tracert depuis le client fonctionne ?
Après je ne connais pas suffisament iptables pour comprendre pourquoi cela se comporte de la sorte.
Édité par nic80 Le 31/01/2021 à 00h02
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
nic80 :
Je soupçonne un problème de parefeu sur la machine qui héberge le serveur Openvpn ( d' après mes tests)...
C'est possible, je vais voir ça, j'ai cru que j'avais résolu le problème en changeant la connexion de mon serveur. Il était connecté en wifi à ma box, je l'ai connecté en filaire mais en faisant ça j'ai changé l'adresse IP locale !!! donc oopenvpn peut très bien être lancé sur le client et tourner, mais les requêtes internet depuis le client ne doivent plus passer par openvpn ... bon je revois ça demain ou pet-être après-demain.
Pour le moment bonne nuit tout le monde et encore
.
Édité par zatox Le 31/01/2021 à 02h07
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
J'ai désactivé le pare feu du serveur, et j'ai bien:
Caché :
[root@porpompa-mga8-beta2 robert]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@porpompa-mga8-beta2 robert]#
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@porpompa-mga8-beta2 robert]#
Vu que mon serveur est connecté en wifi sur ma box, l'interface réseau ne s'appelle pas enp.. quelque chose mais wlo1 donc je dois bien passer la commande iptables sur wlo1 ?
Donc j'ai passé la commande suivante sur le serveur:
Caché :
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o wlo1 -j MASQUERADE
Ensuite, l'interface tun0 sur le serveur donne ceci:
Caché :
un0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.255 destination 10.8.0.2
inet6 fe80::c7c3:c3f6:58e4:756b prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 841 bytes 52416 (51.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 480 (480.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
inet 10.8.0.1 netmask 255.255.255.255 destination 10.8.0.2
inet6 fe80::c7c3:c3f6:58e4:756b prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 841 bytes 52416 (51.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 480 (480.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
nic80 :
le ping ou le tracert depuis le client fonctionne ?
Sachant que mon serveur a comme adresse locale: 192.168.1.64
sur quelle adresse dois-je passer le ping ? sur 192.168.1.64 ou sur 10.8.0.1 ou 10.8.0.2 ?!!!!
Question subsidiaire: le serveur est-ce qu'il vaut mieux qu'il soit connecté en filaire sur la box ?
pour vos réponsesÉdité par zatox Le 31/01/2021 à 14h53
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Citation :
sur quelle adresse dois-je passer le ping ? sur 192.168.1.64 ou sur 10.8.0.1 ou 10.8.0.2 ?!!!!
Je dirais 10.8.0.1
Mais en principe on devrait pouvoir essayer de faire le traceroute depuis le client si le parfeu est désactivé sur le serveur et que la commande iptables a été lancée.
En principe sur le client, on devrait voir que les serveurs dns sont ceux envoyés par le serveur VPN ( lancement de la commande nslookup, puis server.
wl0 est une interface sans fil, pour une utilisation en tant que serveur, je préconiserais l' utilisation filaire.
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Caché :
[root@allinone-mga8-beta2 robert]# traceroute www.mageialinux-online.org
traceroute to www.mageialinux-online.org (80.247.225.3), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@allinone-mga8-beta2 robert]#
traceroute to www.mageialinux-online.org (80.247.225.3), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@allinone-mga8-beta2 robert]#
A mon avis, je ne vois pas que l'on transite vers le serveur VPN car si je me réfère au tutoriel, je devrais voir qu'on transite vers le 10.8.0.x ce qui n'est pas le cas.
De plus la commande nslookup donne ceci:
Caché :
root@allinone-mga8-beta2 robert]# nslookup mageialinux-online.org
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: mageialinux-online.org
Address: 80.247.225.3
[root@allinone-mga8-beta2 robert]#
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: mageialinux-online.org
Address: 80.247.225.3
[root@allinone-mga8-beta2 robert]#
Et toujours par référence au tutoriel, je peux voir qu'on n'utilise pas les DNS du serveur vpn.
Déjà dans la log d'openvpn j'ai ceci:
Caché :
[root@porpompa-mga8-beta2 robert]# cat /var/log/openvpn.log
2021-01-31 15:46:18 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
2021-01-31 15:46:18 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-31 15:46:18 OpenVPN 2.5.0 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 9 2020
2021-01-31 15:46:18 library versions: OpenSSL 1.1.1i 8 Dec 2020, LZO 2.10
2021-01-31 15:46:18 net_route_v4_best_gw query: dst 0.0.0.0
2021-01-31 15:46:18 net_route_v4_best_gw result: via 192.168.1.1 dev wlo1
2021-01-31 15:46:18 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
2021-01-31 15:46:18 Diffie-Hellman initialized with 2048 bit key
2021-01-31 15:46:18 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:46:18 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:46:18 net_route_v4_best_gw query: dst 0.0.0.0
2021-01-31 15:46:18 net_route_v4_best_gw result: via 192.168.1.1 dev wlo1
2021-01-31 15:46:18 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlo1 HWADDR=a4:17:31:31:48:47
2021-01-31 15:46:18 TUN/TAP device tun0 opened
2021-01-31 15:46:18 net_iface_mtu_set: mtu 1500 for tun0
2021-01-31 15:46:18 net_iface_up: set tun0 up
2021-01-31 15:46:18 net_addr_ptp_v4_add: 10.8.0.1 peer 10.8.0.2 dev tun0
2021-01-31 15:46:18 net_route_v4_add: 10.8.0.0/24 via 10.8.0.2 dev [NULL] table 0 metric -1
2021-01-31 15:46:18 Could not determine IPv4/IPv6 protocol. Using AF_INET
2021-01-31 15:46:18 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-01-31 15:46:18 UDPv4 link local (bound): [AF_INET]192.168.1.64:1194
2021-01-31 15:46:18 UDPv4 link remote: [AF_UNSPEC]
2021-01-31 15:46:18 GID set to nogroup
2021-01-31 15:46:18 UID set to nobody
2021-01-31 15:46:18 MULTI: multi_init called, r=256 v=256
2021-01-31 15:46:18 IFCONFIG POOL IPv4: base=10.8.0.4 size=62
2021-01-31 15:46:18 Initialization Sequence Completed
2021-01-31 15:54:36 192.168.1.22:60086 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:54:36 192.168.1.22:60086 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:54:36 192.168.1.22:60086 TLS: Initial packet from [AF_INET]192.168.1.22:60086, sid=86b55d2e 33ae3f6e
2021-01-31 15:54:36 192.168.1.22:60086 VERIFY OK: depth=1, C=FR, ST=FRANCE, L=Limoges, O=zatox.fr, OU=changeme, CN=serveurmga-porpompa, name=zatox, emailAddress=mail@host.domain
2021-01-31 15:54:36 192.168.1.22:60086 VERIFY OK: depth=0, C=FR, ST=FRANCE, L=Limoges, O=zatox.fr, OU=changeme, CN=clientmga, name=zatox, emailAddress=mail@host.domain
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_VER=2.5.0
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_PLAT=linux
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_PROTO=6
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_NCP=2
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-128-CBC
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZ4=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZ4v2=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZO=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_COMP_STUB=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_COMP_STUBv2=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_TCPNL=1
2021-01-31 15:54:36 192.168.1.22:60086 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2021-01-31 15:54:36 192.168.1.22:60086 [clientmga] Peer Connection Initiated with [AF_INET]192.168.1.22:60086
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI: Learn: 10.8.0.6 -> clientmga/192.168.1.22:60086
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI: primary virtual IP for clientmga/192.168.1.22:60086: 10.8.0.6
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 SENT CONTROL [clientmga]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
[root@porpompa-mga8-beta2 robert]#
2021-01-31 15:46:18 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
2021-01-31 15:46:18 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2021-01-31 15:46:18 OpenVPN 2.5.0 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 9 2020
2021-01-31 15:46:18 library versions: OpenSSL 1.1.1i 8 Dec 2020, LZO 2.10
2021-01-31 15:46:18 net_route_v4_best_gw query: dst 0.0.0.0
2021-01-31 15:46:18 net_route_v4_best_gw result: via 192.168.1.1 dev wlo1
2021-01-31 15:46:18 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
2021-01-31 15:46:18 Diffie-Hellman initialized with 2048 bit key
2021-01-31 15:46:18 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:46:18 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:46:18 net_route_v4_best_gw query: dst 0.0.0.0
2021-01-31 15:46:18 net_route_v4_best_gw result: via 192.168.1.1 dev wlo1
2021-01-31 15:46:18 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlo1 HWADDR=a4:17:31:31:48:47
2021-01-31 15:46:18 TUN/TAP device tun0 opened
2021-01-31 15:46:18 net_iface_mtu_set: mtu 1500 for tun0
2021-01-31 15:46:18 net_iface_up: set tun0 up
2021-01-31 15:46:18 net_addr_ptp_v4_add: 10.8.0.1 peer 10.8.0.2 dev tun0
2021-01-31 15:46:18 net_route_v4_add: 10.8.0.0/24 via 10.8.0.2 dev [NULL] table 0 metric -1
2021-01-31 15:46:18 Could not determine IPv4/IPv6 protocol. Using AF_INET
2021-01-31 15:46:18 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-01-31 15:46:18 UDPv4 link local (bound): [AF_INET]192.168.1.64:1194
2021-01-31 15:46:18 UDPv4 link remote: [AF_UNSPEC]
2021-01-31 15:46:18 GID set to nogroup
2021-01-31 15:46:18 UID set to nobody
2021-01-31 15:46:18 MULTI: multi_init called, r=256 v=256
2021-01-31 15:46:18 IFCONFIG POOL IPv4: base=10.8.0.4 size=62
2021-01-31 15:46:18 Initialization Sequence Completed
2021-01-31 15:54:36 192.168.1.22:60086 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:54:36 192.168.1.22:60086 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-01-31 15:54:36 192.168.1.22:60086 TLS: Initial packet from [AF_INET]192.168.1.22:60086, sid=86b55d2e 33ae3f6e
2021-01-31 15:54:36 192.168.1.22:60086 VERIFY OK: depth=1, C=FR, ST=FRANCE, L=Limoges, O=zatox.fr, OU=changeme, CN=serveurmga-porpompa, name=zatox, emailAddress=mail@host.domain
2021-01-31 15:54:36 192.168.1.22:60086 VERIFY OK: depth=0, C=FR, ST=FRANCE, L=Limoges, O=zatox.fr, OU=changeme, CN=clientmga, name=zatox, emailAddress=mail@host.domain
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_VER=2.5.0
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_PLAT=linux
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_PROTO=6
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_NCP=2
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-128-CBC
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZ4=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZ4v2=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_LZO=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_COMP_STUB=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_COMP_STUBv2=1
2021-01-31 15:54:36 192.168.1.22:60086 peer info: IV_TCPNL=1
2021-01-31 15:54:36 192.168.1.22:60086 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2021-01-31 15:54:36 192.168.1.22:60086 [clientmga] Peer Connection Initiated with [AF_INET]192.168.1.22:60086
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI: Learn: 10.8.0.6 -> clientmga/192.168.1.22:60086
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 MULTI: primary virtual IP for clientmga/192.168.1.22:60086: 10.8.0.6
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-01-31 15:54:36 clientmga/192.168.1.22:60086 SENT CONTROL [clientmga]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
[root@porpompa-mga8-beta2 robert]#
Dès le début, nic80 tu m'avais bien fait remarqué les 5 ou 6 premières lignes et que ça risquait de poser problème, il est possible que tu avais raison ...
Bon si je n'arrive pas à résoudre ce problème je pense que je vais tout recommencer en connectant mon serveur par éthernet. Ensuite sur ce serveur j'ai donc mageia8 bêta 2, OS sur lequel j'ai monté openvpn mais j'ai également un OS mageia 7.1.
Est-ce que ça vaudrait le coup de tenter de monter le serveur vpn sur mageia 7.1 avant de recommencer sur mageia8 bêta 2 ?!!!!!
pour tes réponses. Édité par zatox Le 31/01/2021 à 16h13
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
C' est étrange, dans mes tests, j' ai une machine virtuelle en Mageia 8 ( en tant que serveur), et une Mageia 7.1 virtuelle en tant que client ( je n' ai pas d' autre machine en Mageia 8).
Il ne me semble pas que j' ai modifié les options proposées dans le tutoriel.
Sur le client, la mise à jour des routes et DNS se fait correctement ( taper /sbin/route avant ( la route classique doit s' afficher avec uniquement le 192.168.1.X) et après le lancement du client vpn ( une nouvelle route par défaut doit pointer vers 10.8.0.X) ?
Citation :
Sun Jan 31 16:43:48 2021 /usr/sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Sun Jan 31 16:43:48 2021 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.8.0.6 10.8.0.5 init
dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220
Sun Jan 31 16:43:48 2021 /etc/openvpn/update-resolv-conf tun0 1500 1553 10.8.0.6 10.8.0.5 init
dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220
Ici on ne voit que les logs du serveur, je pense qu' il faudrait regarder ce qui disent les logs du client.
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Pour ma part, les 2 machines client et serveur sont en mageia 8.
nic80 :
Il ne me semble pas que j' ai modifié les options proposées dans le tutoriel.
Tu veux parler de quelles options ?!
nic80 :
Sur le client, la mise à jour des routes et DNS se fait correctement ( taper /sbin/route avant ( la route classique doit s' afficher avec uniquement le 192.168.1.X) et après le lancement du client vpn ( une nouvelle route par défaut doit pointer vers 10.8.0.X) ?
Voici ce que j'ai sur le client avant lancement d'openvpn:
Caché :
[root@allinone-mga8-beta2 robert]# /sbin/route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default box 0.0.0.0 UG 0 0 0 enp3s0
link-local 0.0.0.0 255.255.0.0 U 1002 0 0 enp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
[root@allinone-mga8-beta2 robert]#
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default box 0.0.0.0 UG 0 0 0 enp3s0
link-local 0.0.0.0 255.255.0.0 U 1002 0 0 enp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
[root@allinone-mga8-beta2 robert]#
Après lancement d'openvpn (la réponse est beaucoup moins rapide):
Caché :
root@allinone-mga8-beta2 robert]# /sbin/route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
default box 0.0.0.0 UG 0 0 0 enp3s0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 1002 0 0 enp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.1.64 box 255.255.255.255 UGH 0 0 0 enp3s0
[root@allinone-mga8-beta2 robert]#
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
default box 0.0.0.0 UG 0 0 0 enp3s0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 1002 0 0 enp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.1.64 box 255.255.255.255 UGH 0 0 0 enp3s0
[root@allinone-mga8-beta2 robert]#
Je cherche où je peux trouver la log d'openvpn du clent et si je trouve je l'envoie.
Édité par zatox Le 31/01/2021 à 17h36
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie