[OpenVPN] mauvaise attribution IP coté client

NuX_o · Février 21, 2016, 9:55pm

Bonjour,

Le lien se fait bien entre mon client et mon serveur, le soucis se passe lorsque je veux faire passer tout mon trafic via le VPN, mon client s’attribue une mauvaise IP privé, ce qui induit en erreur le serveur. Ce dernier doit renvoyer les paquets vers 10.9.8.2 (selon la conf que je lui ai mis) mais le client s’attribue une mauvaise IP :

Sep 13 11:02:01 debian-monclient ntpd[562]: Deleting interface #16 tun0, [b]10.9.8.6[/b]#123, interface stats: received=0, sent=4, dropped=0, active_time=19 secs
 ntpd[562]: 104.167.113.112 interface 10.9.8.6 -> (none)
 ntpd[562]: 104.167.113.95 interface 10.9.8.6 -> (none)
 ntpd[562]: 192.95.20.208 interface 10.9.8.6 -> (none)
 ntpd[562]: 64.235.98.66 interface 10.9.8.6 -> (none)
 ntpd[562]: peers refreshed

tail -f coté serveur (en bleu l’IP que j’ai configuré pour le serveur):

Sun Sep 13 11:02:00 2015 us=407252 TCP/UDP: Closing socket Sun Sep 13 11:02:00 2015 us=407383 /sbin/ip route del [b]10.9.8.1[/b]/32 RTNETLINK answers: Operation not permitted Sun Sep 13 11:02:00 2015 us=413021 ERROR: Linux route delete command failed: external program exited with error status: 2 Sun Sep 13 11:02:00 2015 us=413108 /sbin/ip route del a.b.c.d/32 RTNETLINK answers: Operation not permitted Sun Sep 13 11:02:00 2015 us=414797 ERROR: Linux route delete command failed: external program exited with error status: 2 Sun Sep 13 11:02:00 2015 us=414880 /sbin/ip route del 0.0.0.0/1 RTNETLINK answers: Operation not permitted Sun Sep 13 11:02:00 2015 us=416429 ERROR: Linux route delete command failed: external program exited with error status: 2 Sun Sep 13 11:02:00 2015 us=416500 /sbin/ip route del 128.0.0.0/1 RTNETLINK answers: Operation not permitted Sun Sep 13 11:02:00 2015 us=417928 ERROR: Linux route delete command failed: external program exited with error status: 2 Sun Sep 13 11:02:00 2015 us=417977 Closing TUN/TAP interface Sun Sep 13 11:02:00 2015 us=418015 /sbin/ip addr del dev tun0 local [b]10.9.8.6[/b] peer [color=#BF0000]10.9.8.5[/color] RTNETLINK answers: Operation not permitted

Je précise que je lance le client via un sudo.

J’ai un serveur VPN avec cette configuration :
(extrait
coté serveur :

/etc/openvpn/server.conf :

[code]dev tun

server 10.9.8.0 255.255.255.0

client-config-dir ccd
route 192.168.x.xx 255.255.255.0
[/code]

/etc/openvpn/tun0.conf :

dev tun0 ifconfig 10.9.8.1 10.9.8.2 secret /etc/openvpn/serveur.key

/etc/openvpn/ccd/monclient :

# cat /etc/openvpn/ccd/monclient iroute 10.9.8.2 255.255.255.0

coté client :

/etc/openvpn/client.conf :

[code]dev tun

ns-cert-type server[/code]

/etc/openvpn/tun0.conf :

remote serveur.org dev tun0 ifconfig 10.9.8.2 10.9.8.1 secret /etc/openvpn/client.key

Si quelqu’un a une idée

merci à vous

TrashHard · Février 21, 2016, 9:55pm

Hello,

Voilà la conf que j’ai de mon côté actuellement et qui fonctionne bien.

Côté serveur uniquement

Créer le rep et le fichier :
/etc/openvpn/staticclients/

/etc/openvpn/server.conf

[code]server 10.9.8.0 255.255.255.0

push "route " #On donne la route

client-config-dir /etc/openvpn/staticclients #On indique au serveur d’aller chercher les fichiers d’attribution d’IP
[/code]

Côté client pas besoin de préciser l’IP c’est le serveur qui lui attribue.

Tu peux aussi réserver l’IP pour qu’elle ne soit pas attribué sur le DHCP si tu veux :
/etc/openvpn/ipp.txt

/etc/openvpn/server.conf

Mais ça marche très bien sans

NuX_o · Février 21, 2016, 9:55pm

Merci pour ta réponse !

j’ai fais les modifications et effectivement mon client à désormais la bonne IP mais l’erreur perdure :

a.b.c.d -> ip public serveur

coté client :

Sun Sep 13 13:53:54 2015 Initialization Sequence Completed
^CSun Sep 13 13:54:08 2015 event_wait : Interrupted system call (code=4)
Sun Sep 13 13:54:08 2015 /sbin/ip route del 10.9.8.1/32
RTNETLINK answers: Operation not permitted
Sun Sep 13 13:54:08 2015 ERROR: Linux route delete command failed: external program exited with error status: 2
Sun Sep 13 13:54:08 2015 /sbin/ip route del a.b.c.d/32
RTNETLINK answers: Operation not permitted
Sun Sep 13 13:54:08 2015 ERROR: Linux route delete command failed: external program exited with error status: 2
Sun Sep 13 13:54:08 2015 /sbin/ip route del 0.0.0.0/1
RTNETLINK answers: Operation not permitted
Sun Sep 13 13:54:08 2015 ERROR: Linux route delete command failed: external program exited with error status: 2
Sun Sep 13 13:54:08 2015 /sbin/ip route del 128.0.0.0/1
RTNETLINK answers: Operation not permitted
Sun Sep 13 13:54:08 2015 ERROR: Linux route delete command failed: external program exited with error status: 2
Sun Sep 13 13:54:08 2015 Closing TUN/TAP interface
Sun Sep 13 13:54:08 2015 /sbin/ip addr del dev tun0 local 10.9.8.2 peer 255.255.255.0
RTNETLINK answers: Operation not permitted
Sun Sep 13 13:54:08 2015 Linux ip addr del failed: external program exited with error status: 2
Sun Sep 13 13:54:08 2015 SIGINT[hard,] received, process exiting

e.f.g.h -> ip publique client
coté serveur :

[code]Sep 13 14:03:09 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: Learn: 10.9.8.2 -> monclient/e.f.g.h:43173
Sep 13 14:03:09 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: primary virtual IP for monclient/e.f.g.h:43173: 10.9.8.2
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER READ [104] from [AF_INET]e.f.g.h:43173: P_CONTROL_V1 k
id=0 [ ] pid=39 DATA len=90
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 PUSH: Received control message: ‘PUSH_REQUEST’
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 send_push_reply(): safe_cap=940
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 SENT CONTROL [mayoux]: ‘PUSH_REPLY,route 192.168.x.xx 255.255.255.0,redi
rect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.9.8.1,topology net30,ping 10,ping-restart 1
20,ifconfig 10.9.8.2 255.255.255.0’ (status=1)
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER WRITE [22] to [AF_INET]e.f.g.h:43173: P_ACK_V1 kid=0 [
39 ]
Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER WRITE [114] to [AF_INET]e.f.g.h:43173: P_CONTROL_V1 ki
d=0 [ ] pid=42 DATA len=100

…

Sep 13 14:03:11 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: bad source address from client [192.168.x.xx], packet dropped
Sep 13 14:03:12 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER READ [93] from [AF_INET]e.f.g.h:43173: P_DATA_V1 kid=0
DATA len=92
Sep 13 14:03:12 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: bad source address from client [192.168.x.xx], packet dropped
Sep 13 14:03:12 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER READ [101] from [AF_INET]e.f.g.h:43173: P_DATA_V1 kid=
0 DATA len=100
Sep 13 14:03:12 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: bad source address from client [192.168.x.xx], packet dropped
Sep 13 14:03:13 serveurn ovpn-server[4587]: monclient/e.f.g.h:43173 TCPv4_SERVER READ [101] from [AF_INET]e.f.g.h:43173: P_DATA_V1 kid=
0 DATA len=100
Sep 13 14:03:13 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 MULTI: bad source address from client [192.168.x.xx], packet dropped
Sep 13 14:03:14 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 Connection reset, restarting [0]
Sep 13 14:03:14 serveur ovpn-server[4587]: monclient/e.f.g.h:43173 SIGUSR1[soft,connection-reset] received, client-instance restarting
Sep 13 14:03:14 serveur ovpn-server[4587]: TCP/UDP: Closing socket
[/code]

On voit bien que l’IP est correctement attribué au client…

confirmé par un ifconfig coté client :

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet adr:10.9.8.2 P-t-P:255.255.255.0 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:100 RX bytes:0 (0.0 B) TX bytes:168 (168.0 B)

AnonymousCoward · Février 21, 2016, 9:55pm

NuX_o,

Les commandes route et ifconfig sont complètement obsolètes. Elles ont été remplacées par la commande ip , introduite en janvier 1999.

Pour nous fournir la configuration réseau de ton serveur et de ton client, tu peux nous donner le résultat des commandes :

ip link show
ip -4 addr show
ip -4 route show
ip -4 rule show

Et il serait appréciable que tu fournisses la dernière version des fichiers de configuration de chaque extrémité de ton VPN lorsque tu apportes des changements.

Tu peux bien évidement censurer les adresses IP publiques. Par contre, par pitié, ne cache/censure pas les adresses IP privées telles que les 10.0.0.0/8 !

Merci.

–
AnonymousCoward

haleth · Février 21, 2016, 9:55pm

Tu lances ton openvpn en tant que root, n’est-ce pas ?

NuX_o · Février 21, 2016, 9:55pm

Bonjour,

1 - je lance mon openvpn en tant que sudo.
Je crois, en désespoir de cause avoir lancé le client en root et le problème était le même…

2 - voici les infos demandés :

pour le serveur :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100 link/none 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet a.b.c.d/26 brd a.b.c.f scope global eth0 valid_lft forever preferred_lft forever 13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 inet 10.9.8.1 peer 10.9.8.2/32 scope global tun0 valid_lft forever preferred_lft forever default via a.b.c.d dev eth0 10.9.8.0/24 via 10.9.8.2 dev tun0 10.9.8.2 dev tun0 proto kernel scope link src 10.9.8.1 a.b.c.d/26 dev eth0 proto kernel scope link src a.b.c.d 0: from all lookup local 32766: from all lookup main 32767: from all lookup default

pour le client (en connexion réussie ):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100 link/none 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 inet 10.9.8.2 peer 255.255.255.0/32 scope global tun0 valid_lft forever preferred_lft forever 0.0.0.0/1 via 255.255.255.0 dev tun0 default via 192.168.0.250 dev eth0 10.9.8.1 via 255.255.255.0 dev tun0 128.0.0.0/1 via 255.255.255.0 dev tun0 a.b.c.d via 192.168.0.250 dev eth0 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11 255.255.255.0 dev tun0 proto kernel scope link src 10.9.8.2 0: from all lookup local 32766: from all lookup main 32767: from all lookup default

Extrait de configuration de bout en bout :

serveur.conf :
ancienne nouvelle config (les lignes plus hauts ont été extraits suite à cette config.)

proto tcp dev tun server 10.9.8.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.0.11 255.255.255.0" client-config-dir /etc/openvpn/staticclients push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220" keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log
staticclients/monclient :

ifconfig-push 10.9.8.2 255.255.255.0

client.conf :

[code]# Specify that we are a client and that we

will be pulling certain config file directives

from the server.

client
dev tun
proto tcp
remote ippubliqueServeur port
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ns-cert-type server
comp-lzo
[/code]
-------------- j’ai remis ma conf serveur comme à l’originale :

proto tcp dev tun server 10.9.8.0 255.255.255.0 ;ifconfig-pool-persist ipp.txt ;push "route 192.168.0.11 255.255.255.0" client-config-dir ccd route 192.168.0.11 255.255.255.0 ;push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220" keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log

/etc/openvpn/ccd/monclientoto :

# cat /etc/openvpn/ccd/monclientoto iroute 10.9.8.2 255.255.255.0

tun0.conf :

dev tun0 ifconfig 10.9.8.1 10.9.8.2 secret /etc/openvpn/serveur.key

coté client :

tun0.conf :

remote monserveur.org dev tun0 ifconfig 10.9.8.2 10.9.8.1

après ces modifications et un restart coté client :
rebelotte, mêmes erreurs qu’au message initial.

voici les sorties des commandes demandés par AnonymousCoward :

coté client :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:26:9e:5d:ac:b8 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1e:64:21:49:cc brd ff:ff:ff:ff:ff:ff 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100 link/none 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 inet 10.9.8.6 peer 10.9.8.5/32 scope global tun0 valid_lft forever preferred_lft forever default via 192.168.0.250 dev eth0 10.9.8.1 via 10.9.8.5 dev tun0 10.9.8.5 dev tun0 proto kernel scope link src 10.9.8.6 a.b.c.d via 192.168.0.250 dev eth0 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11 0: from all lookup local 32766: from all lookup main 32767: from all lookup default

et PAF ! l’IP en 10.9.8.6 et 5 réapparait

coté serveur :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback ::::: brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ::::: brd ff:ff:ff:ff:ff:ff 14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100 link/none 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet a.b.c.d/26 brd a.b.c.f scope global eth0 valid_lft forever preferred_lft forever 14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 inet 10.9.8.1 peer 10.9.8.2/32 scope global tun0 valid_lft forever preferred_lft forever default via a.b.c.d dev eth0 10.9.8.0/24 via 10.9.8.2 dev tun0 10.9.8.2 dev tun0 proto kernel scope link src 10.9.8.1 a.b.c./26 dev eth0 proto kernel scope link src a.b.c.d 0: from all lookup local 32766: from all lookup main 32767: from all lookup default

Merci à vous pour votre patience et votre aide

AnonymousCoward · Février 21, 2016, 9:55pm

Bonsoir,

Il y a des petits trucs à corriger et je t’enverrais plus de détail demain, mardi.

–
AnonymousCoward

NuX_o · Février 21, 2016, 9:55pm

Merci pour ta réponse, j’ai fais le nécessaire concernant l’IP, serait-il possible de modifier ton message ? histoire de masquer le nom de l’hébergeur ? merci à toi !

AnonymousCoward · Février 21, 2016, 9:55pm

Alors, précisons un peu l’architecture du truc.

NuX_o, “client” fait partie d’un réseau en 192.168.0.0/24 avec 192.168.0.250 qui est le routeur pour aller sur Internet. Ce routeur fait probablement du SNAT.
Et sur ce réseau tu as “client” de raccordé, avec l’adresse IP 192.168.0.11 . Jusque-là, tout est correct ?

Et tu souhaites que “client” puisse aller sur Internet en passant par l’intermédiaire du VPN ou tu souhaites seulement accéder au dédié ?

Ensuite, tu souhaites que seul “client” bénéficie du VPN ou que toutes les machines en 192.168.0.0/24 l’utilisent aussi ?

Accessoirement, comment fais-tu pour redémarrer OpenVPN sur le serveur dédié après avoir changé le fichier de configuration ? Tu utilises une ligne de commande ? Laquelle ?

–
AnonymousCoward

NuX_o · Février 21, 2016, 9:55pm

[quote=“AnonymousCoward”]Alors, précisons un peu l’architecture du truc.

NuX_o, “client” fait partie d’un réseau en 192.168.0.0/24 avec 192.168.0.250 qui est le routeur pour aller sur Internet. Ce routeur fait probablement du SNAT.
Et sur ce réseau tu as “client” de raccordé, avec l’adresse IP 192.168.0.11 . Jusque-là, tout est correct ?[/quote]

oui

[quote=“AnonymousCoward”]
Et tu souhaites que “client” puisse aller sur Internet en passant par l’intermédiaire du VPN ou tu souhaites seulement accéder au dédié ?[/quote]

Je souhaite que tout mon trafic web transit via le VPN

[quote]
Ensuite, tu souhaites que seul “client” bénéficie du VPN ou que toutes les machines en 192.168.0.0/24 l’utilisent aussi ?[/quote]

Qu’il n y ait (pour le moment) que le 0.11 qui passe par le VPN par la suite j’y ajouterai certainement d’autres périphérique, une fois avoir bien compris toute l’affaire

[quote=“AnonymousCoward”]
Accessoirement, comment fais-tu pour redémarrer OpenVPN sur le serveur dédié après avoir changé le fichier de configuration ? Tu utilises une ligne de commande ? Laquelle ?

AnonymousCoward[/quote]

coté client : [mono]cd /etc/openvpn && sudo openvpn client.conf[/mono]

et via le serveur, openvpn se lance au démarrage du serveur. Si je change la conf je fais un [mono]sudo systemctl restart openvpn[/mono] et je relance la connexion client.

En espérant avoir correctement répondu à tes questions

Un grand merci à toi !

AnonymousCoward · Février 21, 2016, 9:55pm

Si tu souhaite que ton ton trafic Internet passe par le dédié, il te faudra :

Sur “client”, (ré)activer la directive de configuration [mono]redirect-gateway def1[/mono]. Tu peux la pousser depuis “server” mais c’est plus souple si c’est au niveau de la configuration de “client”.
Sur “serveur”, il faut s’assurer que le routage soit activé ( commandes [mono]cat /proc/sys/net/ipv4/ip_forward[/mono] et [mono]cat /proc/sys/net/ipv4/conf/eth0/forwarding[/mono] ) et que du SNAT (source NAT parfois indiqué masquerade) soit bien mis en place ( commande [mono]iptables --line-numbers -nvx -t nat -L POSTROUTING[/mono] ). Si un pare-feu est utilisé, il peut-être bien de vérifier qu’il autorise les paquets à passer dans la table [mono]filter[/mono] chaîne [mono]FORWARD[/mono], aussi.

Plus globalement, dans tes fichiers de configuration, je te suggère de consolider tous les fichiers de configuration en un seul, coté serveur et coté client. Au moins tant que le système n’est pas maîtrisé.
Et la directive de configuration [mono]server 10.9.8.0 255.255.255.0[/mono] sur le serveur suffit. Tu peux commenter (ou supprimer) toutes les autres lignes [mono]ifconfig[/mono], [mono]ifconfig-push[/mono], [mono]route[/mono], [mono]iroute[/mono] des fichiers de conf sur “client” et “serveur”. Mais pas touche à [mono]redirect-gateway def1[/mono], n’est-ce pas ?

Réessaye avec ces vérifications / modifications faites et dis-moi s’il y a du progrès. Que l’IP assignée à “client” par OpenVPN soit [mono]192.168.8.6[/mono] au lieu de [mono]192.168.8.2[/mono], par contre, je dirais que ce n’est pas vraiment critique.

–
AnonymousCoward

NuX_o · Février 21, 2016, 9:55pm

Merci encore pour ta patience

Les changement ont été fait.

[mono]cat /proc/sys/net/ipv4/ip_forward[/mono] et [mono]cat /proc/sys/net/ipv4/conf/eth0/forwarding[/mono] renvoient [mono]1[/mono]

Voici le résultat de certaines commandes :

sudo iptables --line-numbers -nvx -t nat -L POSTROUTING

Chain POSTROUTING (policy ACCEPT 1955 packets, 113130 bytes) num pkts bytes target prot opt in out source destination 1 0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0 2 0 0 MASQUERADE all -- * eth0 10.9.0.0/24 0.0.0.0/0 3 0 0 MASQUERADE all -- * eth0 10.9.8.0/24 0.0.0.0/0

Les lignes 1 et 2 sont de vieilles erreurs dont j’avais essayé de supprimer, sans succès, je m’y pencherai dés que possible

extrait iptables :

Chain FORWARD (policy DROP 380 packets, 25608 bytes) pkts bytes target prot opt in out source destination

aucun ifconfig, ifconfig-push, route, iroute actifs dans les fichiers de conf.

[mono]redirect-gateway def1[/mono] activé.

Que veux-tu dire par :

[quote][…] je te suggère de consolider tous les fichiers de configuration en un seul, coté serveur et coté client[/quote] ?

Que je mette les tun0.conf et le dossier …/ccd/monclient dans server.conf et tun0.conf dans client.conf ?

----- résultat :

ovpn-server[6323]: e.f.g.h:33474 [client] Peer Connection Initiated with [AF_INET]e.f.g.h:33474 ovpn-server[6323]: client/e.f.g.h:33474 MULTI_sva: pool returned IPv4=10.9.8.6, IPv6=(Not enabled) ovpn-server[6323]: client/e.f.g.h:33474 MULTI: Learn: 10.9.8.6 -> client/e.f.g.h:33474 ovpn-server[6323]: client/e.f.g.h:33474 MULTI: primary virtual IP for client/e.f.g.h:33474: 10.9.8.6 ovpn-server[6323]: client/e.f.g.h:33474 PUSH: Received control message: 'PUSH_REQUEST' ovpn-server[6323]: client/e.f.g.h:33474 send_push_reply(): safe_cap=940 ovpn-server[6323]: client/e.f.g.h:33474 SENT CONTROL [client]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.9.8.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.8.6 10.9.8.5' (status=1) ovpn-server[6323]: client/e.f.g.h:33474 MULTI: bad source address from client [192.168.0.11], packet dropped ovpn-server[6323]:client/e.f.g.h:33474 MULTI: bad source address from client [192.168.0.11], pa...

— j’ai remis ces lignes actifs :
#client-config-dir ccd
#route 10.9.8.2 255.255.255.0

en faisant plusieurs essaies entre 10.9.8.2 et 192.168.0.11 dans le fichier ./ccd/monclient en mettant les mêmes ip, en les intervertissant mais idem :
résultat :

Options error: in --iroute 192.168.0.11 255.255.255.0 : Bad network/subnet specification

Je les ai donc commenté de nouveau, refait un restart…

AnonymousCoward · Février 21, 2016, 9:55pm

[quote=“NuX_o”]sudo iptables --line-numbers -nvx -t nat -L POSTROUTING

Chain POSTROUTING (policy ACCEPT 1955 packets, 113130 bytes) num pkts bytes target prot opt in out source destination 1 0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0 2 0 0 MASQUERADE all -- * eth0 10.9.0.0/24 0.0.0.0/0 3 0 0 MASQUERADE all -- * eth0 10.9.8.0/24 0.0.0.0/0

Les lignes 1 et 2 sont de vieilles erreurs dont j’avais essayé de supprimer, sans succès, je m’y pencherai dés que possible [/quote]
Réglons déjà ce problème… Si tu consulte la page de man de iptables, tu pouuras en déduire les commandes suivantes :

iptables -t nat -F POSTROUTING pour “flush” CAD vider la chaîne POSTROUTING de la table nat.
iptables -t nat -D POSTROUTING 1 pour “delete” la rêgle n°1 de cette même chaîne.

Ensuite, une fois que la chaîne a été vidée, pour installer un SNAT propre, tu peux utiliser :
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source aa.bb.cc.dd , aa.bb.cc.d étant l’IP publique / WAN de ton dédié.

Par rapport à MASQUERADE, la cible SNAT fait la même chose mais cette dernière est mieux adaptée au cas d’une IP publique / WAN qui ne change pas.

[quote=“NuX_o”]extrait iptables :

Chain FORWARD (policy DROP 380 packets, 25608 bytes) pkts bytes target prot opt in out source destination[/quote]
Là aussi, si on ne règle pas ça, il n’y a aucune chance que cela marche. La “policy” CAD la politique par défaut étant configurée pour “DROP” tout ce qui demande à être routé, on change cela avec :
iptables -t filter -P FORWARD ACCEPT

[quote=“NuX_o”]Que veux-tu dire par :

[quote][…] je te suggère de consolider tous les fichiers de configuration en un seul, coté serveur et coté client[/quote] ?

Que je mette les tun0.conf et le dossier …/ccd/monclient dans server.conf et tun0.conf dans client.conf ?[/quote]
Oui, c’est tout à fait ça.

[quote=“NuX_o”]----- résultat :

ovpn-server[6323]: client/e.f.g.h:33474 MULTI: bad source address from client [192.168.0.11], packet dropped ovpn-server[6323]:client/e.f.g.h:33474 MULTI: bad source address from client [192.168.0.11], pa...[/quote]
Alors ça, ce pourrait être un problème très drôle. Mais il faut que je fasse quelques vérifications avant de répondre.

Mais déjà, en réglant les 2 soucis liés à iptables, ce ne sera pas pire…

–
AnonymousCoward

NuX_o · Février 21, 2016, 9:55pm

Merci pour ces explications

J’ai quelques questions basiques…

le tun0.con et le fichier client dans ./ccd/ sont ainsi :

[code]/etc/openvpn$ cat tun0.conf
dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret /etc/openvpn/serv.key
/etc/openvpn$ cat ccd/monclient

cat /etc/openvpn/ccd/monclient

iroute 10.9.8.2 255.255.255.0[/code]

Si j’ai bien suivi tu m’as demandé d’enlever tout ce qui se réfère à [mono]ifconfig[/mono] et [mono]iroute[/mono], en sommes je n’ai pas l’utilité de les mettre dans [mono]server.conf[/mono] (?) le fichier se suffit ainsi à lui même (?)

nouvelles règles (sur le serveur):

[code]Chain FORWARD (policy ACCEPT 14 packets, 1064 bytes)
pkts bytes target prot opt in out source destination

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
SNAT all – 0.0.0.0/0 0.0.0.0/0 to:a.b.c.d (IP public serveur)
[/code]

question niaiseuse, si je puis dire, la règle contenant la [mono]–to-source monServeur[/mono] ne devrait pas être mis sur mon client ? Si j’ai bien compris le man, le [mono]postrouting[/mono] va prendre le paquet qui est prêt à être envoyé à l’IP de mon serveur (??? et non à mon client ? )

j’ai retenté, avec les changements de règles et le résultat semble être identique :

coté client :

/sbin/ip route add 0.0.0.0/1 via 10.9.8.5 /sbin/ip route add 128.0.0.0/1 via 10.9.8.5 /sbin/ip route add 10.9.8.1/32 via 10.9.8.5 GID set to nogroup UID set to nobody Initialization Sequence Completed event_wait : Interrupted system call (code=4) /sbin/ip route del 10.9.8.1/32 RTNETLINK answers: Operation not permitted ERROR: Linux route delete command failed: external program exited with error status: 2

coté serveur :

ovpn-server[6952]: e.f.g.h:33711 [client] Peer Connection Initiated with [AF_INET]e.f.g.h:33711 ovpn-server[6952]: client/e.f.g.h:33711 MULTI_sva: pool returned IPv4=10.9.8.6, IPv6=(Not enabled) ovpn-server[6952]: client/e.f.g.h:33711 MULTI: Learn: 10.9.8.6 -> client/e.f.g.h:33711 ovpn-server[6952]: client/e.f.g.h:33711 MULTI: primary virtual IP for client/e.f.g.h:33711: 10.9.8.6 ovpn-server[6952]: client/e.f.g.h:33711 PUSH: Received control message: 'PUSH_REQUEST' ovpn-server[6952]: client/e.f.g.h:33711 send_push_reply(): safe_cap=940 ovpn-server[6952]: client/e.f.g.h:33711 SENT CONTROL [client]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.9.8.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.8.6 10.9.8.5' (status=1) ovpn-server[6952]: client/e.f.g.h:33711 MULTI: bad source address from client [192.168.0.11], packet dropped

ce sera vraiment drôle ou… vraiment drôle du genre -->

ps :

j’avais trouvé ça, avant d’exposer mon problème ici :

[quote]“MULTI: bad source address from client , packet dropped” or “GET INST BY VIRT: [failed]”?
These errors occur because OpenVPN doesn’t have an internal route for 192.168.100.249. Consequently, it doesn’t know how to route the packet to this machine, so it drops the packet.
Use client-config-dir and create a ccd file for your client containing the iroute option to tell OpenVPN that the 192.168.100.0/24 network is available behind this client.
“MULTI: bad source address from client [192.168.100.249], packet dropped” or “GET INST BY VIRT: 192.168.100.249 [failed]”?[/quote]
source : https://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-source-address-from-client–packet-droppedq-or-qget-inst-by-virt-failedq.html

mais la création du dossier ccd avec le fichier du client pour le routage n’a pas résolu le problème

merci encore

AnonymousCoward · Février 21, 2016, 9:55pm

[quote=“NuX_o”]le tun0.con et le fichier client dans ./ccd/ sont ainsi :

[code]/etc/openvpn$ cat tun0.conf
dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret /etc/openvpn/serv.key
/etc/openvpn$ cat ccd/monclient

cat /etc/openvpn/ccd/monclient

iroute 10.9.8.2 255.255.255.0[/code]

Si j’ai bien suivi tu m’as demandé d’enlever tout ce qui se réfère à [mono]ifconfig[/mono] et [mono]iroute[/mono], en sommes je n’ai pas l’utilité de les mettre dans [mono]server.conf[/mono] (?) le fichier se suffit ainsi à lui même (?) [/quote]
En fait, la directive server 10.9.8.0 255.255.255.0 se développe en d’autres directives dont ifconfig. Voir openvpn-20x-manpage et faire une recherche de [mono]–server network netmask[/mono].
Et la directive ifconfig ne devrait se trouver qu’une seule fois, seulement côté serveur.

Donc oui, un fichier de configuration côté serveur contenant la directive [mono]server network netmask[/mono] suffit. Si la directive [mono]server[/mono] n’est pas utilisée, là par contre, on peut en reparler.

En fait, sur le serveur, tu as oublié de préciser l’interface par laquelle doivent sortir les paquets pour qu’on leur applique le SNAT.
La commande que tu dois utiliser : iptables -t nat -A POSTROUTING [size=125]-o eth0[/size] -j SNAT --to-source aa.bb.cc.dd
La mauvaise commande que tu as probablement utilisé : iptables -t nat -A POSTROUTING -j SNAT --to-source aa.bb.cc.dd

La chaîne POSTROUTING de la table nat se situe simplement à la toute fin du parcours d’un paquet dans netfilter/iptables. On peut voir un schéma très simplifié de ce parcours ici. Les paquets qui traversent cette chaîne sont presque prêts à être émis par la machine sur laquelle tu as mis une rêgle en place dans POSTROUTING, c’est tout.
Et la cible SNAT (ou MASQUERADE) permet de dissimuler des adresses IP privées / RFC1918 derrière une adresse IP publique. Si ton dédié envoie des paquets sur Internet dont l’adresse IP source est du genre 10.8.0.55, le premier routeur venu qui verra passer le paquet LE SUPPRIMERA et peut-être même qu’il ira prévenir ton hébergeur de te couper l’accès pour utilisation d’une IP interdite. Wikipedia FR - SNAT

[quote=“NuX_o”]j’ai retenté, avec les changements de règles et le résultat semble être identique :

coté client :

/sbin/ip route add 0.0.0.0/1 via 10.9.8.5 /sbin/ip route add 128.0.0.0/1 via 10.9.8.5 /sbin/ip route add 10.9.8.1/32 via 10.9.8.5 ... ERROR: Linux route delete command failed: external program exited with error status: 2[/quote]
Et en commentant / supprimant les directives suivantes côté client, est-ce que OpenVPN arrive à enlever proprement les routes ?

user nobody group nogroup

–
AnonymousCoward

NuX_o · Février 21, 2016, 9:55pm

Bonjour,

Merci pour toutes ces explications et ces liens instructifs !

En ce qui concernait la règle, j’avais fait un copié collé (flemmard en puissance).

j’ai désactivé sur le client.conf
[mono];user nobody
;group nogroup[/mono]

je lance le tout… j’ai le réseau… je vais sur mon-ip.com et j’aperçois l’IP publique de mon serveur ! MERCI MERCI MERCI

La question qui me vient à l’esprit :

mais alors, openvpn est obligé de rester en utilisateur root ?

Normalement là… mon VPN est chiffré et tout et tout…

Je vais relire le tout, au final pas si compliqué

ps : je continue à avoir ces logs :

ovpn-server[23610]: serveur/a.b.c.d:47216 SENT CONTROL [client]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.9.8.1,topology net30,ping 10,ping-restart 120,ifconfig 10.9.8.6 10.9.8.5' (status=1) ovpn-server[23610]: serveur/a.b.c.d:47216 MULTI: bad source address from client [192.168.0.11], packet dropped ovpn-server[23610]: serveur/a.b.c.d:47216 MULTI: bad source address from client [192.168.0.11], packet dropped

Merci encore

[OpenVPN] mauvaise attribution IP coté client

Côté serveur uniquement

will be pulling certain config file directives

from the server.

[quote=“AnonymousCoward”] Accessoirement, comment fais-tu pour redémarrer OpenVPN sur le serveur dédié après avoir changé le fichier de configuration ? Tu utilises une ligne de commande ? Laquelle ?

cat /etc/openvpn/ccd/monclient

cat /etc/openvpn/ccd/monclient

[quote=“AnonymousCoward”]
Accessoirement, comment fais-tu pour redémarrer OpenVPN sur le serveur dédié après avoir changé le fichier de configuration ? Tu utilises une ligne de commande ? Laquelle ?