Openvpn - Initialization Sequence Completed - Et après ?

lol · Février 21, 2016, 2:12am

Salut,
J’ai créé un tunnel avec Openvpn sur ma passerelle pfSense.
Je me connecte pour des essais avec mon eeepc sous squeeze (connecté par l’extérieur - ppp)

root@eee:~# openvpn /etc/openvpn/client.conf ... Mon May 9 10:09:47 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Mon May 9 10:09:47 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mon May 9 10:09:47 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Mon May 9 10:09:47 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mon May 9 10:09:47 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Mon May 9 10:09:47 2011 [www.hotspot.zehome.org] Peer Connection Initiated with [AF_INET]41.188.26.122:1194 Mon May 9 10:09:50 2011 SENT CONTROL [www.hotspot.zehome.org]: 'PUSH_REQUEST' (status=1) Mon May 9 10:09:50 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.252.0,route 192.168.100.1,topology net30,ping 10,ping-restart 60,ifconfig 192.168.100.6 192.168.100.5' Mon May 9 10:09:50 2011 OPTIONS IMPORT: timers and/or timeouts modified Mon May 9 10:09:50 2011 OPTIONS IMPORT: --ifconfig/up options modified Mon May 9 10:09:50 2011 OPTIONS IMPORT: route options modified Mon May 9 10:09:50 2011 ROUTE: default_gateway=UNDEF Mon May 9 10:09:50 2011 TUN/TAP device tun0 opened Mon May 9 10:09:50 2011 TUN/TAP TX queue length set to 100 Mon May 9 10:09:50 2011 /sbin/ifconfig tun0 192.168.100.6 pointopoint 192.168.100.5 mtu 1500 Mon May 9 10:09:50 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.252.0 gw 192.168.100.5 Mon May 9 10:09:50 2011 /sbin/route add -net 192.168.100.1 netmask 255.255.255.255 gw 192.168.100.5 Mon May 9 10:09:50 2011 Initialization Sequence Completed

[code]$ netstat -ie
Table d’interfaces noyau
eth0 Link encap:Ethernet HWaddr 00:23:54:7c:fb:b1
adr inet6: fe80::223:54ff:fe7c:fbb1/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:914 errors:0 dropped:0 overruns:0 frame:0
TX packets:100 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 lg file transmission:1000
RX bytes:141459 (138.1 KiB) TX bytes:12520 (12.2 KiB)
Interruption:27

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

ppp0 Link encap:Protocole Point-à-Point
inet adr:10.128.7.210 P-t-P:10.6.6.6 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:946 errors:0 dropped:0 overruns:0 frame:0
TX packets:1522 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
RX bytes:97099 (94.8 KiB) TX bytes:196801 (192.1 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:192.168.100.6 P-t-P:192.168.100.5 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:443 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:0 (0.0 B) TX bytes:37024 (36.1 KiB)

wlan0 Link encap:Ethernet HWaddr 00:22:43:3b:e5:9b
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:2 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:3780 (3.6 KiB)
Interruption:18 Mémoire:f8080000-f8080100[/code]

root@eee:~# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.100.1 192.168.100.5 255.255.255.255 UGH 0 0 0 tun0 192.168.100.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.6.6.6 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 192.168.100.5 255.255.252.0 UG 0 0 0 tun0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Maintenant je suis un peu couillon… Des pings sur les ip du réseau “tunnelé” ne donne rien… (sur 192.168.0.0/22 ou 192.168.100.0/24)
Que faire pour avoir accès aux machines de mon lan ?

fran.b · Février 21, 2016, 2:12am

Il te faut configuer l’autre bout en passerelle, il faut que les machines du réseau 192.168.0.0/22 sachent comment te joindre (retour du ping par exemple). Bref, il faut faire des choses sur le serveur VPN. Bref, regarde le routage de tes paquets, là tu as fait tes chemins, mets les panneaux pour que les paquets puissent se diriger.

lol · Février 21, 2016, 2:12am

Salut,

Merci,
j’étais un peu paumé. Il faut des règles NAT sur le serveur, ou juste des routes ?

Edit: Il me faut aussi un autre gateway sur le serveur, non ?

fran.b · Février 21, 2016, 2:12am

Il te faut activer ip_forward, puis tu peux effectivement faire une sortie NAT pour tous les paquets provenant de ton VPN ou rajouter un route sur la passerelle par défaut si tu peux.

lol · Février 21, 2016, 2:12am

[quote=“fran.b”]Il te faut activer ip_forward[/quote]Sur le client ? Sur le serveur (pfSense) je suppose que c’est fait par défaut…

Merci en tout cas, j’y suis presque et c’est cool!

lol · Février 21, 2016, 2:12am

Re,
mon affaire se corse sans que je ne comprenne pourquoi…

Alors que je n’ai rien changé sur le client, j’ai maintenant une erreur qui ne disparaît pas au redémarrage…

[quote]root@eee:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.100.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
10.6.6.6 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.100.0 192.168.100.5 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 192.168.100.5 255.255.252.0 UG 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0[/quote]

[quote]# openvpn /etc/openvpn/client.conf
…
Mon May 9 16:31:51 2011 OPTIONS IMPORT: route options modified
Mon May 9 16:31:51 2011 ROUTE: default_gateway=UNDEF
Mon May 9 16:31:51 2011 TUN/TAP device tun1 opened
Mon May 9 16:31:51 2011 TUN/TAP TX queue length set to 100
Mon May 9 16:31:51 2011 /sbin/ifconfig tun1 192.168.100.6 pointopoint 192.168.100.5 mtu 1500
Mon May 9 16:31:51 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.252.0 gw 192.168.100.5
SIOCADDRT: File exists
Mon May 9 16:31:51 2011 ERROR: Linux route add command failed: external program exited with error status: 7
Mon May 9 16:31:51 2011 /sbin/route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.100.5
SIOCADDRT: File exists
Mon May 9 16:31:51 2011 ERROR: Linux route add command failed: external program exited with error status: 7
Mon May 9 16:31:51 2011 Initialization Sequence Completed[/quote]

J’arrive tout de même à partir d’une machine derrière la serveur openvpn à me connecter en ssh au client.
Mais le client lui, est aveugle…

Faut-il purger les routes et recommencer ?

fran.b · Février 21, 2016, 2:12am

Je pense que tu as as deux VPNS qui tournent, le premier utilisant tun0, il te faut le virer.

lol · Février 21, 2016, 2:12am

Salut,
C’est un peu plus clair, mais ça reste un peu flou dans mon esprit.

J’ai effacé toutes les routes redémarré, c’était ok pour les routes - Mais toujours pas ok pour accéder au serveur depuis le client.

J’ai activé l’ip_forwarding sur le client, j’ai essayé en tcp puis en udp…

Nouvel essai après redémarrage:

Premier essai, tun0 créé, tables ok
Et toc: SIGUSER1 (soft, connexion-reset)
nouvelle tentative (automatique) et paf: interface tun1 crée

Ça ne peut pas fonctionner avec deux interfaces…
Je tourne en rond. Je vais faire des recherches sur le net pour ce souci.

Ce qui n’arrange pas mes affaires, c’est que la connexion avec laquelle je fais les tests est un peu pourave… Je ne sais pas toujours si les problèmes viennent de la ligne ou de openvpn…
A partir de demain j’aurais la possibilité de tester avec une bonne ligne, je verrais ce qu’il en est.

Tu me conseillerais de rester en udp ou de passer en tcp ? J’ai lu que certains routeur Internet bloquaient le tcp…

fran.b · Février 21, 2016, 2:12am

J’utilise sans problème le TCP -en fait même tcp et interface tap plus primaire que tun mais qui marche très bien notamment avec des clients Windows))

Quelles sont les tables de routage (route -n) sur

Le serveur VPN
Le client VPN
Une machine à laquelle tu veux accéder
et l’éventuelle passerelle

Pyc · Février 21, 2016, 2:12am

Salut !

Dans le fichier de configuration du serveur OpenVPN (par exemple /etc/openvpn/serveur.conf) il y a un pavé commenté disant ceci :

[code]# Push routes to the client to allow it

to reach other private subnets behind

the server. Remember that these

private subnets will also need

to know to route the OpenVPN client

address pool (10.8.0.0/255.255.255.0)

back to the OpenVPN server.[/code]

J’ai donc écrit ceci dessous :

push "route 192.168.4.0 255.255.255.0" push "route 192.168.10.0 255.255.255.0"

Afin que deux de mes 10 sous-réseaux puissent être accessibles par les clients VPN, sans rien toucher de plus à mes règles iptables.

En espérant t’avoir aidé… Sinon, tant pis

lol · Février 21, 2016, 2:12am

Salut,
Merci , Ed viens justement de me conseiller la même chose tout à l’heure sur le chan.
Je n’ai malheureusement pas de meilleurs résultats.

J’ai manifestement un soucis du côté du client. J’ai une interface “tun” en trop…
Je pense que c’est bon côté serveur, je me connecte bien, et j’accède au client à partir d’une machine derrière le serveur.

Le “Roadwarrior” sous squeeze déraille…

Edit: Faut-il rajouter “pull” chez le client ?

lol · Février 21, 2016, 2:12am

Salut,
j’ai contourné le problème.
Règle NAT de la passerelle pfSense (VM) vers mon serveur Debian. Serveur OpenVpn sur le serveur Debian.

Tout roule. C’était donc simplement un problème de conf pfSense…

Merci.

lol · Février 21, 2016, 2:12am

Re,

Juste pour dire… C’est génial ce truc!
Pourquoi ne pas l’avoir fait avant…

Yohann22 · Février 21, 2016, 2:12am

Juste une petite question, comment as tu fait pour supprimé tes interfaces virtuelles multiples ?

lol · Février 21, 2016, 2:12am

Salut,
Tout est revenu à la normale tout seul (ou presque) sur le client.

Liste des routes:ip route ls
Effacement des routes inutiles (exemple):ip route del 10.8.0.0/24 via 10.8.0.5 dev tun0

Et redémarrage.
J’ai l’impression (certaine) que ce sont les connexion avortée multiples du client qui créaient les interfaces virtuelles en trop.

Yohann22 · Février 21, 2016, 2:12am

Okay

Merci de ta réponse

M3t4linux · Février 21, 2016, 2:12am

Question naïve :

Quelle est la préférence d’un VPN par rapport à SSH?

fran.b · Février 21, 2016, 2:12am

Là je n’ai pas compris la question.

Si celle ci est quel est l’intérêt d’un VPN, imagine la situation suivante (la mienne), tu organises un concours dans un lieu où on te donne un réseau physique, réseau dont tu ne peux avoir la confiance absolue (il pourrait être écouter, quelqu’un se brancghe dessus, etc.) Tu mets toutes les machines sur un réseau VPN, une fois cela fait, tout est transparent.

Un autre exemple plus classique est la possibilité de quelqu’un à l’extérieur pouvant se raccorder à un LAN donné de manière transparente.

Un dernier exemple (personnel) est que tu as des neveux et enfants disséminés cherchant à faire une partie de Starcraft en LAN.

Dans tous ses exemples, ssh ne suffit pas loin de là.

M3t4linux · Février 21, 2016, 2:12am

Tu as bien interprété ma question: je voulais comprendre l’intérêt d’un VPN…

Chose faite, merci!