OpenVPN et partage de connexion Internet

Support Debian
#1

Salut salut,

Je viens vous parler d’un petit problème de conf OpenVPN : j’ai suivi ce guide (blog.nicolargo.com/2010/10/insta … buntu.html), grâce auquel j’ai pu installer sans problème un serveur VPN sur une machine, et faire démarrer un client sur mon laptop.
Par contre, si je peux bien pinger dans le réseau 10.8.0.0/24, je ne peux en sortir; je reçois l’erreur suivante :

Sat Apr  6 12:18:28 2013 us=76837 loic-skaro/MONIP:33386 MULTI: bad source address from client [192.168.1.203], packet dropped

192.168.1.203 est l’adresse derrière le NAT de mon laptop, chez moi. MONIP est mon adresse IP publique chez moi (ADSL).

Après quelques recherches, il semble qu’il puisse s’agir d’un problème de routage. J’ai vu pas mal de posts concernant un fichier ccd, mais j’ai eu beau suivre ces indications, pas plus de glop que sans.

A priori, ma conf firewall est correcte, mais j’ai pu louper un truc :

$ sudo iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 22 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
 
...

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:4443 

...

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0  
$ sudo iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.8.0.0/24          0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

(Le VPN écoute sur 4443)

Une piste ?

Merci d’avance

#2

slt

isalo.org/wiki.debian-fr/Serveur_OpenVPN

#3

Qu’entends-tu exactement par “pinger dans le réseau” et “je ne peux en sortir” ? Des exemples concrets de préférence.
Où vois-tu cette erreur ?

Dans cette hypothèse il pourrait être utile de fournir les tables de routage du client et du serveur (affichées par “ip route”) lorsque le VPN est établi.
Pour lister les règles iptables, la sortie de la commande “iptables-save” est plus complète et lisible.

#4

Bonjour,
Si tu veux j’ai fais un script pour installer openvpn facilement et activer openvpn en tant que “passerelle” :

jette un oeil tu vas trouver mon script avec les explications :
pour-les-scripts-c-est-ici-t3548-300.html

Kit’

#5

Salut,

Désolé du temps mis à répondre, j’ai apparemment oublié d’activer le suivi du sujet.

Je ne suis pas chez moi, donc ne peux copier les tables de routage pour le moment, mais je peux fournir la conf firewall :

$ sudo iptables-save 
# Generated by iptables-save v1.4.8 on Fri Apr 12 13:31:03 2013
*nat
:PREROUTING ACCEPT [78016:7769699]
:POSTROUTING ACCEPT [12612:775970]
:OUTPUT ACCEPT [12612:775970]
-A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE 
COMMIT
# Completed on Fri Apr 12 13:31:03 2013
# Generated by iptables-save v1.4.8 on Fri Apr 12 13:31:03 2013
*filter
:INPUT DROP [95:30769]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [359:21907]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A INPUT -m state --state INVALID -j DROP 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 4443 -j ACCEPT  ## openvpn écoute sur 4443
-A INPUT -p tcp -m tcp --dport 25565 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10011 -j ACCEPT 
-A INPUT -p udp -m udp --dport 9987 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 5280 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT 
-A FORWARD -m state --state INVALID -j DROP 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A fail2ban-ssh -j RETURN 
COMMIT
# Completed on Fri Apr 12 13:31:03 2013

PascalHamboug : Pas “je ne peux en sortir”, je veux dire que s’il m’est possible de pinger une adresse IP dans le réseau 10.8.0.0/24, si je tente de pinger 8.8.8.8 par exemple, le ping échoue (je ne sais plus s’il s’agit d’un timeout ou d’un host unreachable, par contre).
Je pourrais montrer quelques exemples depuis chez moi ce week-end.

Kitsun, Ghrim : Merci pour les liens, je vais y jeter un coup d’œil dès que possible.

Merci :slightly_smiling:

#6

Premier problème : aucune règle iptables dans la chaîne FORWARD n’accepte les paquets qui créent de nouvelles connexions (état NEW), donc toute communication entre un client VPN et l’extérieur à travers cette machine est impossible.

Secondairement, l’unique règle dans la chaîne OUTPUT est inutile puisque la politique par défaut de la chaîne est déjà OUTPUT.

#7

Merci PascalHamboug, en passant la policy de forward à ACCEPT, j’ai accès au reste du monde via le VPN.

Pour la règle inutile en OUTPUT, c’est en fait une règle par défaut de ferm (ferm.foo-projects.org/), une interface très simple à iptables.
Vu qu’elle n’influait pas le comportement du firewall, je ne l’ai juste pas commentée :slightly_smiling:

Maintenant, le forward est potentiellement trop laxiste, je vais m’atteler à le restreindre un peu. Je suppose que le limiter au range 10.8.0.0/24 devrait être suffisant…

Merci encore

#8

Il est généralement plus sûr de se baser sur l’interface d’entrée (-i) que sur l’adresse source seule, car cette dernière peut être usurpée par l’émetteur d’un paquet.

En tout cas, s’il s’agissait seulement d’un filtrage iptables trop strict, le message d’erreur que tu citais dans ton premier message n’était pas lié au problème.

#9

En effet, le message apparait toujours. Je vais continuer à tenter de le faire disparaitre, peut-être que maintenant, les insctructions sur le ccd que j’ai vues fonctionneront, puisqu’il peut effectivement y avoir forward de paquets.

Pour la restriction, je n’ai qu’une interface sur le serveur, donc ça revient un peu au même. Toujours est-il qu’il faut un certificat valide pour se connecter au VPN, donc quelque part, seuls ceux qui ont un pied sur le serveur (ou une des machines clientes) peuvent s’en servir.

#10

Non, le serveur a au moins deux interfaces réseau. L’interface “physique” (généralement ethX) par laquelle passe le trafic internet et le transport du VPN, et l’interface “virtuelle” (tapX ou tunX selon le type de VPN ponté ou routé) par laquelle passe le trafic à l’intérieur du VPN. La sortie des commandes “ifconfig” ou “ip addr” le montrera. Si l’interface “physique” est connectée à un réseau public, alors n’importe qui peut y envoyer du trafic depuis ce réseau avec n’importe quelle adresse IP source, pas besoin d’être un client authentifié.

Ce n’est qu’en te basant sur l’interface d’entrée que tu pourras savoir si un paquet est arrivé par le VPN ou par le réseau public.

Concernant le message d’erreur, dans quelles circonstances apparaît-il ? N’importe quand ou seulement à certains moments, par exemple lors de l’établissement ou de l’arrêt du VPN par le client ? Si je l’interprète correctement, il signifie qu’un client a envoyé un paquet dans le VPN avec comme adresse IP source l’adresse de son interface “normale” (physique) au lieu de l’adresse de l’interface VPN. Mais visiblement ce n’est pas systématique pour tous les paquets puisque la communication à travers le VPN fonctionne quand même. Quel est l’OS du poste client ?

#11

Ow, en effet, j’avais oublié le tun0… Je limite ça de suite.

Le client est sous Archlinux. Je vais faire un peu de tcpdump pour comprendre quels paquets vont vers le VPN.

Edit: J’aurais pu être malin et me souvenir que le trafic est chiffré, j’aurais du mal à lire :stuck_out_tongue:

#12

(Je réfléchis tout haut)
Par défaut, l’adresse source d’un paquet émis est l’adresse de l’interface de sortie. Donc les paquets envoyés dans le VPN devraient avoir comme adresse source l’adresse de l’interface tun et non celle de l’interface eth. Cependant, pour certaines communications, notamment TCP, l’adresse source est sélectionnée lors de l’établissement de la connexion et utilisée pour tous les paquets. Donc si une communication de ce type était en cours avant le lancement du VPN (et sortait par l’interface eth), alors cela pourrait expliquer que des paquets soient ensuite envoyés par le VPN suite au changement de route par défaut mais toujours avec la même adresse source. La communication en question sera peut-être visible avec netstat qui affiche les sockets ouvertes.

#13

[quote=“loic”]Ow, en effet, j’avais oublié le tun0… Je limite ça de suite.

Le client est sous Archlinux. Je vais faire un peu de tcpdump pour comprendre quels paquets vont vers le VPN.

Edit: J’aurais pu être malin et me souvenir que le trafic est chiffré, j’aurais du mal à lire :p[/quote]
Le trafic n’est chiffré que sur l’interface eth. Un tcpdump sur l’interface tun0 montrera le trafic en clair.

#14

haaa sympa ferm je connaissais pas wiki.debian.org/ferm , a tester !!

#15

[quote=“PascalHambourg”](Je réfléchis tout haut)
Par défaut, l’adresse source d’un paquet émis est l’adresse de l’interface de sortie. Donc les paquets envoyés dans le VPN devraient avoir comme adresse source l’adresse de l’interface tun et non celle de l’interface eth. Cependant, pour certaines communications, notamment TCP, l’adresse source est sélectionnée lors de l’établissement de la connexion et utilisée pour tous les paquets. Donc si une communication de ce type était en cours avant le lancement du VPN (et sortait par l’interface eth), alors cela pourrait expliquer que des paquets soient ensuite envoyés par le VPN suite au changement de route par défaut mais toujours avec la même adresse source. La communication en question sera peut-être visible avec netstat qui affiche les sockets ouvertes.[/quote]

Ça peut donc être ma connexion SSH au serveur, initiée largement avanty la session VPN, du coup ?
Je vois effectivement des connexion entre mon pc et le serveur :

# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 192.168.1.203:58829     SERVEUR:4443      ESTABLISHED 12897/openvpn       

tcp        0      0 192.168.1.203:54636     SERVEUR:22        ESTABLISHED 2439/ssh            

tcp        0      0 192.168.1.203:50878     SERVEUR:5222      ESTABLISHED 2412/psi-plus

(je n’ai laissé que les lignes concernant les connexions au serveur, qui fait aussi serveur Jabber depuis peu :slightly_smiling: )

#16

Probablement pas. Si je ne m’abuse l’adresse du serveur VPN est un cas particulier, car quand le client openvpn modifie la route par défaut pour la faire passer par le VPN, il crée une route spécifique pour l’adresse du serveur (à vérifier avec ip route) pour que le routage de celle-ci ne soit pas modifié. Sinon les paquets d’encapsulation transportant le tunnel seraient à leur tour routés et encapsulés dans le tunnel et ainsi de suite, ce qui ne peut évidemment pas marcher.

Dans le cas contraire, ces communications seraient interrompues après l’établissement du VPN, car comme ton poste client est derrière un routeur NAT, le serveur s’attend à voir arriver leurs paquets avec l’adresse publique du NAT et non l’adresse privée du poste.
Avec une capture des paquets qui ont pour adresse 192.168.1.203 (ou l’adresse du moment si elle change) sur l’interface tun0 du client, tu devrais pouvoir en déduire de quoi il s’agit.

#17

Oui, j’avais bien fait ça, tant sur le client que le serveur, mais sans résultat. Ja vais laisser tourner plus longtemps cette fois-ci…

Edit : Du nouveau :

# tcpdump -A -X -s0 -nti tun0 host 192.168.1.203
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes




IP 192.168.1.203.51662 > 23.23.145.121.443: Flags [P.], seq 4069249024:4069249466, ack 2058999801, win 205, options [nop,nop,TS val 8112512 ecr 194388970], length 442
        0x0000:  4500 01ee 7952 4000 4006 54b4 c0a8 01cb  E...yR@.@.T.....
        0x0010:  1717 9179 c9ce 01bb f28b d000 7ab9 d7f9  ...y........z...
        0x0020:  8018 00cd 0fd0 0000 0101 080a 007b c980  .............{..
        0x0030:  0b96 23ea 1703 0100 20af b720 53cf 7b2b  ..#.........S.{+
        0x0040:  c600 db6f a855 a4e5 6c45 452d 3674 d737  ...o.U..lEE-6t.7
        0x0050:  d253 7566 2d55 baa2 4917 0301 0190 2fd9  .Suf-U..I...../.
        0x0060:  2abc d2d3 4b8a a3ec f504 0540 594b 368c  *...K......@YK6.
        0x0070:  51b7 5aff 1f4a 16ce 59d2 a31e df65 1be8  Q.Z..J..Y....e..
        0x0080:  3565 9ccf 9787 728a fa47 b348 dd5a 32ff  5e....r..G.H.Z2.
        0x0090:  bc19 b572 8586 fa0d 7fd5 421c 10b4 f5de  ...r......B.....
        0x00a0:  32a3 a1fb f964 5599 ef47 02c4 1ed5 891e  2....dU..G......
        0x00b0:  bbed 3b40 a381 4f9c 5bd5 2d4a c8ca 1930  ..;@..O.[.-J...0
        0x00c0:  2c62 b419 65a2 2c9e ed72 b234 9506 cd73  ,b..e.,..r.4...s
        0x00d0:  eb41 02e1 3e1c fe80 9cdd 81d3 cfff 45af  .A..>.........E.
        0x00e0:  c454 3325 467f 0e83 6da8 4cf0 b641 a84d  .T3%F...m.L..A.M
        0x00f0:  fd9b 76e6 7a93 6b27 b7c1 e78b 2761 061c  ..v.z.k'....'a..
        0x0100:  6868 5ea0 cf4c d92d 0fc2 026a 0763 bc03  hh^..L.-...j.c..
        0x0110:  ad9c 20fa c63c 5719 1410 11ac 93ba 94f0  .....<W.........
        0x0120:  b9a2 3a62 00a7 aab8 b6d4 69e0 4299 ddb4  ..:b......i.B...
        0x0130:  5f5e 7a15 482e 1713 7389 b205 a825 1c61  _^z.H...s....%.a
        0x0140:  6706 0387 6ea6 aa32 38c4 26fe 0cce b950  g...n..28.&....P
        0x0150:  4ad6 031f d50f f89f 4bb7 d66f fc65 8acb  J.......K..o.e..
        0x0160:  d745 cc55 e4dd 01f6 1d41 1bc0 4959 c8b3  .E.U.....A..IY..
        0x0170:  ada3 0ff2 16f6 3ebc e29f 1615 b6fe 5a83  ......>.......Z.
        0x0180:  0472 5ca3 1186 adb4 3b6a d31e 5d49 3063  .r\.....;j..]I0c
        0x0190:  607d a2f3 3819 a572 6b57 15ed 4268 8bde  `}..8..rkW..Bh..
        0x01a0:  e15d aa42 25d0 9927 5a85 c7e7 f520 2113  .].B%..'Z.....!.
        0x01b0:  79b2 3c90 185b 302b 4355 2c44 811b f757  y.<..[0+CU,D...W
        0x01c0:  ac38 8407 aa83 7740 4162 82b7 d3f8 e292  .8....w@Ab......
        0x01d0:  1e00 4481 3203 121c 89be b908 e7da 41d1  ..D.2.........A.
        0x01e0:  f1ff 3189 7a7c 412e 9832 1f53 3a1d       ..1.z|A..2.S:.

# netstat -anpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0    442 192.168.1.203:51662     23.23.145.121:443       ESTABLISHED 1257/firefox   
$ dig -x 23.23.145.121

; <<>> DiG 9.9.2-P2 <<>> -x 23.23.145.121
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36404
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:                                                                                                                            
;121.145.23.23.in-addr.arpa.    IN      PTR                                                                                                     

;; ANSWER SECTION:
121.145.23.23.in-addr.arpa. 300 IN      PTR     ec2-23-23-145-121.compute-1.amazonaws.com.

;; AUTHORITY SECTION:
145.23.23.in-addr.arpa. 900     IN      NS      pdns5.ultradns.info.
145.23.23.in-addr.arpa. 900     IN      NS      pdns4.ultradns.org.
145.23.23.in-addr.arpa. 900     IN      NS      pdns1.ultradns.net.
145.23.23.in-addr.arpa. 900     IN      NS      pdns2.ultradns.net.
145.23.23.in-addr.arpa. 900     IN      NS      pdns6.ultradns.co.uk.
145.23.23.in-addr.arpa. 900     IN      NS      pdns3.ultradns.org.

;; ADDITIONAL SECTION:
pdns1.ultradns.net.     725     IN      A       204.74.108.1
pdns1.ultradns.net.     725     IN      AAAA    2001:502:f3ff::1
pdns2.ultradns.net.     15650   IN      A       204.74.109.1
pdns2.ultradns.net.     15650   IN      AAAA    2610:a1:1014::1
pdns3.ultradns.org.     725     IN      A       199.7.68.1
pdns3.ultradns.org.     725     IN      AAAA    2610:a1:1015::1
pdns4.ultradns.org.     725     IN      A       199.7.69.1
pdns4.ultradns.org.     725     IN      AAAA    2001:502:4612::1
pdns5.ultradns.info.    725     IN      A       204.74.114.1
pdns5.ultradns.info.    725     IN      AAAA    2610:a1:1016::1
pdns6.ultradns.co.uk.   725     IN      A       204.74.115.1
pdns6.ultradns.co.uk.   725     IN      AAAA    2610:a1:1017::1

;; Query time: 281 msec
;; SERVER: 192.168.1.199#53(192.168.1.199)
;; WHEN: Sat Apr 13 18:04:34 2013
;; MSG SIZE  rcvd: 545

Je ne sais pas encore pourquoi cette connexion est ouverte, mais je vais enquêter plus loin. Au moins je sais d’où ça vient. Et avec la tripotée d’extension que je traine avec mon Firefox, je serais pas surpris que ça joue :stuck_out_tongue:
J’ai aussi un onglet ouvert plus ou moins tout le temps sur Amazon :stuck_out_tongue:

#18

Le message d’erreur, c’est bien sur le serveur que tu l’as ? Alors à mon avis le démon serveur Openvpn jette ces paquets après décapsulation sans les tranférer à son interface tun0 donc un tcpdump sur le serveur ne montrera rien.
Logiquement, tu devrais avoir une trace avec tcpdump sur le client à chaque occurrence du message d’erreur.

#19

C’est effectivement un paquet d’une connexion HTTPS établie avec un serveur dont l’adresse IP appartient à Amazon Web Services. Connexion qui a dû être créée avant l’établissement du VPN. Si c’est bien Firefox (netstat -p devrait identifier le processus utilisant cette socket), le redémarrer devrait faire apparaître cette connexion mais avec l’adresse locale de l’interface tun cette fois.

#20

C’est bien ce qui se passe. Merci de ton aide :slightly_smiling: