Sommaire
Bonjour,
j'ai un petit soucis, j'essaie d'installer un serveur openvpn sur une machine A, et je veux me connecter avec une autre machine B. Toutes les deux pour le moment se situe dans le même réseaux LAN.
J'ai configuré openvpn serveur sur la machine A, et donné les cert et key au clients pour qui puisse se connecter, mais je me retrouve toujours avec ça côté client (B):
# openvpn client.conf
Tue Sep 9 16:24:09 2014 OpenVPN 2.2.1 i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 13 2014
Tue Sep 9 16:24:09 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Sep 9 16:24:09 2014 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Tue Sep 9 16:24:09 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Sep 9 16:24:09 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Sep 9 16:24:09 2014 LZO compression initialized
Tue Sep 9 16:24:09 2014 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Sep 9 16:24:09 2014 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Sep 9 16:24:09 2014 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Sep 9 16:24:09 2014 Local Options hash (VER=V4): '504e774e'
Tue Sep 9 16:24:09 2014 Expected Remote Options hash (VER=V4): '14168603'
Tue Sep 9 16:24:09 2014 UDPv4 link local: [undef]
Tue Sep 9 16:24:09 2014 UDPv4 link remote: [AF_INET]machineA:1194
Tue Sep 9 16:24:09 2014 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
...
^C
J'utilise ufw comme firewall sur A.
J'essaie de me connecter sur A par UDP sur le port 1194 et en TUN.
machineA:
# ufw status
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
1194 ALLOW Anywhere
22 ALLOW Anywhere (v6)
1194 ALLOW Anywhere (v6)
# nmap 127.0.0.1
Starting Nmap 5.21 ( http://nmap.org ) at 2014-09-09 16:36 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000045s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
443/tcp open https
# nmap -sU 127.0.0.1
Starting Nmap 5.21 ( http://nmap.org ) at 2014-09-09 16:37 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000044s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
68/udp open|filtered dhcpc
5353/udp open|filtered zeroconf
# netstat -lapuent | grep 1194
udp 0 0 127.0.0.1:1194 0.0.0.0:* 0 9748 1105/openvpn
Déjà je comprends pas trop la différence entre le fait que openvpn tourne bien sur 1194 et le résultat de nmap -sU.sh
# service openvpn stop
# openvpn /etc/openvpn/server.conf
Tue Sep 9 16:39:43 2014 OpenVPN 2.2.1 i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 13 2014
Tue Sep 9 16:39:43 2014 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.
Tue Sep 9 16:39:43 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
...
Tue Sep 9 16:39:44 2014 UDPv4 link local (bound): [AF_INET]127.0.0.1:1194
Tue Sep 9 16:39:44 2014 UDPv4 link remote: [undef]
Tue Sep 9 16:39:44 2014 MULTI: multi_init called, r=256 v=256
Tue Sep 9 16:39:44 2014 IFCONFIG POOL: base=xxx.xxx.xxx.xxx size=62, ipv6=0
Tue Sep 9 16:39:44 2014 IFCONFIG POOL LIST
Tue Sep 9 16:39:44 2014 Initialization Sequence Completed
Et si j'essaie de me connecter côté B, j'ai aucune réponse de A - comme s'il n'y avait aucune demande.
# ls /etc/openvpn/
ca.crt clean-all dh1024.pem easy-rsa ipp.txt jail keys server.crt server.key openvpn-status.log server.conf ta.key vars
machine B:
# nmap machineA
Starting Nmap 5.21 ( http://nmap.org ) at 2014-09-09 16:44 CEST
Nmap scan report for machineA (192.168.1.68)
Host is up (0.0037s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: *****
Nmap done: 1 IP address (1 host up) scanned in 4.92 seconds
# nmap -sU machineA
Starting Nmap 5.21 ( http://nmap.org ) at 2014-09-09 16:45 CEST
Nmap scan report for machineA (192.168.1.68)
Host is up (0.0042s latency).
Not shown: 999 open|filtered ports
PORT STATE SERVICE
22/udp closed ssh
MAC Address:******
Nmap done: 1 IP address (1 host up) scanned in 15.62 seconds
Ufw fait son travail, mais pourquoi toujours pas de 1194 ouvert?
# ls /etc/openvpn
ca.crt client.conf client.crt client.key ta.key
Je pense sincérement que c'est une histoire de bloquage de port du côté de machineA. Mais j'arrive pas à démeler ça. J'ai même pensé qui fallait changer le user du côté serveur et ne pas mettre nobody à cause du port, mais j'ai le même résultat.
Je vois pas trop ce qui merde. À mes chaques tentatives d'installation de openvpn je coince, et j'abandonne. J'aimerai que ça marche merci d'avance.
edit : ce qui confirme mes dires, c'est que même si je ne lance pas le serveur sur la machine A (donc openvpn ne tourne pas), j'ai les mêmes réponses d'erreurs sur la machine B.
Je dois mieux configurer ma table ip - avec ufw ça devrait pouvoir marcher (pourtant…), donc avec iptables? - bon j'essaierai quand je pourrai. Ça m'étonne ces histoires de port. Ufw est mauvais, ou je ne sais pas l'utilisé?
# Interface de loopback
Posté par jben . Évalué à 4.
Es-tu sûr que ton daemon openvpn écoute sur une autre interface que celle de loopback ?
[^] # Re: Interface de loopback
Posté par dafp . Évalué à 2.
En effet, j'avais mis l'option 'local machineA' en pensant que machineA serait l'adresse ip LAN, mais finalement, ça prenait l'adresse local loop 127.0.0.1. Honte à moi - merci. J'ai mis en commentaire l'option local et c'est bon, ça marche.
En tout cas si quelqu'un peut m'expliquer le fait que je ne vois toujours pas le port 1194 ouvert à partir de nmap, car j'ai toujours les mêmes résultats.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.