fabien29200 Posté(e) le 3 avril 2010 Partager Posté(e) le 3 avril 2010 Bonjour à tous ! Je lutte depuis ce midi face à un problème que je n'ai jamais rencontré. J'ai un serveur maison qui était jusqu'à présent sous Ubuntu 9.10. Ce serveur sert de passerelle pour le réseau. Je me suis lancé ce matin dans une migration vers Debian testing (car trop galère de mettre à jour Ubuntu tous les 6 mois). J'étais assez confiant car je me disais que de Ubuntu à Debian, il ne devrait pas y avoir de grandes différences. Eh bien on dirait que si. La fonctionnalité de passerelle est gérée par iptables (table nat). J'ai écrit un script qui est lancé à chaque démarrage qui définit toutes les règles du firewall. Le script est assez complexe car il gère des variables, donc je vais poster ce que les règles une fois le script passé. Tout d'abord la passerelle a deux interfaces réseau : eth0 et eth1. eth1 a une IP sur le LAN (192.168.1.254) et eth0 une IP pour les requêtes internet (192.168.0.1). Les machines du LAN ont des IP en 192.168.1.x Je vous poste donc les règles du firewall après le script : # iptables -L -n -v -t filter Chain INPUT (policy DROP 180 packets, 15142 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 21 5104 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 926 77302 ACCEPT all -- eth0 * 0.0.0.0/0 192.168.0.1 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 192.168.0.1 tcp dpt:80 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 192.168.0.1 tcp dpt:443 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 192.168.0.1 tcp dpt:8080 0 0 ACCEPT udp -- eth0 * 212.27.38.253 192.168.0.1 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 eth0 192.168.1.1 0.0.0.0/0 0 0 ACCEPT all -- eth0 eth1 0.0.0.0/0 192.168.1.1 0 0 ACCEPT all -- eth1 eth0 192.168.1.3 0.0.0.0/0 0 0 ACCEPT all -- eth0 eth1 0.0.0.0/0 192.168.1.3 0 0 ACCEPT all -- eth1 eth0 192.168.1.2 0.0.0.0/0 0 0 ACCEPT all -- eth0 eth1 0.0.0.0/0 192.168.1.2 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.100 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.100 tcp spt:80 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.100 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.100 tcp spt:443 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.101 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.101 tcp spt:80 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.101 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.101 tcp spt:443 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.102 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.102 tcp spt:80 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.102 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.102 tcp spt:443 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.103 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.103 tcp spt:80 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.103 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.103 tcp spt:443 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.253 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.253 tcp spt:80 0 0 ACCEPT tcp -- eth1 eth0 192.168.1.253 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 192.168.1.253 tcp spt:443 Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 726 325K ACCEPT all -- * eth0 192.168.0.1 0.0.0.0/0 state NEW,RELATED,ESTABLISHED,UNTRACKED 0 0 ACCEPT tcp -- * eth0 192.168.0.1 0.0.0.0/0 tcp spt:80 0 0 ACCEPT tcp -- * eth0 192.168.0.1 0.0.0.0/0 tcp spt:443 0 0 ACCEPT tcp -- * eth0 192.168.0.1 0.0.0.0/0 tcp spt:8080 0 0 ACCEPT udp -- * eth0 192.168.0.1 212.27.38.253 # iptables -L -n -v -t nat Chain PREROUTING (policy ACCEPT 191 packets, 17858 bytes) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- eth1 * 192.168.1.100 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.100 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.101 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.101 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.102 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.102 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.103 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.103 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.253 0.0.0.0/0 tcp dpt:80 redir ports 3128 0 0 REDIRECT tcp -- eth1 * 192.168.1.253 0.0.0.0/0 tcp dpt:80 redir ports 3128 191 17858 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `PREROUTING boule : ' Chain POSTROUTING (policy ACCEPT 2 packets, 112 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth0 192.168.1.1 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.3 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.2 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.100 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.101 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.102 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.103 0.0.0.0/0 0 0 MASQUERADE all -- * eth0 192.168.1.253 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 2 packets, 112 bytes) pkts bytes target prot opt in out source destination On voit donc que le serveur accepte toutes les requêtes provenant du LAN (interface eth1) en INPUT. Cela a toujours très bien fonctionné sous Ubuntu et avant sous Gentoo. Mais depuis ma migration à Debian, les machines du LAN n'arrivent plus à communiquer avec le serveur. Enfin, elles arrivent à obtenir une adresse IP avec dnsmasq, mais lorsque je tente une simple connexion SSH au serveur, aucune réponse (et le NAT ne fonctionne pas non plus). J'ai alors ajouté des logs au script pour trouver ce qui bloque (sans firewall, aucun problème) et voilà ce qui en ressort : kernel: [ 5299.881732] PREROUTING boule : IN=eth0 OUT= MAC=00:26:18:4d:1f:3c:00:40:d0:71:88:11:08:00 SRC=192.168.1.3 DST=192.168.1.254 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=13224 DF PROTO=TCP SPT=33372 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 J'en au compris que la machine 192.168.1.3 essaie d'accéder au serveur (192.168.1.254) vers le port 22. Par contre les paramètres IN et OUT restent énigmatiques. Est-ce que ça veut dire que les paquets arrivent sur l'interface eth0 (interface Internet) ? Si quelqu'un a une idée pour continuer l'enquête, je suis preneur Lien vers le commentaire Partager sur d’autres sites More sharing options...
PyKaBoo Posté(e) le 3 avril 2010 Partager Posté(e) le 3 avril 2010 Bonjour, J'ai un peu du mal avec ta trace : kernel: [ 5299.881732] PREROUTING boule : IN=eth0 OUT= MAC=00:26:18:4d:1f:3c:00:40:d0:71:88:11:08:00 SRC=192.168.1.3 DST=192.168.1.254 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=13224 DF PROTO=TCP SPT=33372 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Ton packet semblerait arriver sur ton interface eth0, avec en ip source 192.168.1.3, alors que ton interface eth0 est das le reseau 192.168.0.x. Tu devrais essayer de faire des traces avec tcpdump sur les deux interfaces pour mieux comprendre le problème. bon courage, Lien vers le commentaire Partager sur d’autres sites More sharing options...
madko Posté(e) le 3 avril 2010 Partager Posté(e) le 3 avril 2010 ifconfig et route -n ça donne quoi? Lien vers le commentaire Partager sur d’autres sites More sharing options...
fabien29200 Posté(e) le 3 avril 2010 Auteur Partager Posté(e) le 3 avril 2010 @madko : # route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0 # ifconfig eth0 Link encap:Ethernet HWaddr 00:26:18:4d:1f:3c inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0 adr inet6: fe80::226:18ff:fe4d:1f3c/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17380 errors:0 dropped:0 overruns:0 frame:0 TX packets:10814 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:10301576 (9.8 MiB) TX bytes:2919024 (2.7 MiB) Interruption:21 Adresse de base:0x8000 eth1 Link encap:Ethernet HWaddr 00:1b:21:2c:d7:ce inet adr:192.168.1.254 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::21b:21ff:fe2c:d7ce/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2499 errors:0 dropped:0 overruns:0 frame:0 TX packets:2157 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:357835 (349.4 KiB) TX bytes:1927150 (1.8 MiB) Mémoire:faee0000-faf00000 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:51 errors:0 dropped:0 overruns:0 frame:0 TX packets:51 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:3938 (3.8 KiB) TX bytes:3938 (3.8 KiB) Tout me paraît correct pourtant ... je comprends pas comment un paquet à destination de 192.168.1.254 arrive sur l'interface eth0. Mystère ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dark26 Posté(e) le 3 avril 2010 Partager Posté(e) le 3 avril 2010 tu devrais essayer d'utiliser des softs qui simplifie la création des régles comme shorewall Ma config shorewall avec dmz je me suis servi entre autre de ce tuto : Tuto debian shorewall on ne peux pas faire plus simple..... Lien vers le commentaire Partager sur d’autres sites More sharing options...
PyKaBoo Posté(e) le 4 avril 2010 Partager Posté(e) le 4 avril 2010 Tout me paraît correct pourtant ... je comprends pas comment un paquet à destination de 192.168.1.254 arrive sur l'interface eth0. Mystère ... Salut, j'insiste peux-être, mais des traces tcpdump sur tes deux interfaces peuvent t'aider. Essayes avec et sans firewall comme cela tu verras bien la différence :). @+ Lien vers le commentaire Partager sur d’autres sites More sharing options...
fabien29200 Posté(e) le 4 avril 2010 Auteur Partager Posté(e) le 4 avril 2010 Bon, les choses se précisent avec tcpdump (merci PyKaBoo). Pour le test, j'ai configuré une machine (Dauntless) en 192.168.1.3 et je lance une connexion SSH sur 192.168.1.254 (donc le serveur). Alors premier test sans le firewall (enfin toutes les policies à ACCEPT) : # tcpdump -i eth1 -vv | grep Dauntless tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes Dauntless.local.52033 > BlackPearl.local.ssh: Flags [S], cksum 0xc2fd (correct), seq 573010948, win 5840, options [mss 1460,sackOK,TS val 165980 ecr 0,nop,wscale 6], length 0 BlackPearl.local.ssh > Dauntless.local.52033: Flags [S.], cksum 0xb675 (correct), seq 689077196, ack 573010949, win 5792, options [mss 1460,sackOK,TS val 19621532 ecr 165980,nop,wscale 7], length 0 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [.], cksum 0xfb85 (correct), seq 1, ack 1, win 92, options [nop,nop,TS val 165980 ecr 19621532], length 0 BlackPearl.local.ssh > Dauntless.local.52033: Flags [P.], seq 1:33, ack 1, win 46, options [nop,nop,TS val 19621536 ecr 165980], length 32 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [.], cksum 0xfb5d (correct), seq 1, ack 33, win 92, options [nop,nop,TS val 165984 ecr 19621536], length 0 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [P.], seq 1:40, ack 33, win 92, options [nop,nop,TS val 165984 ecr 19621536], length 39 BlackPearl.local.ssh > Dauntless.local.52033: Flags [.], cksum 0xfb64 (correct), seq 33, ack 40, win 46, options [nop,nop,TS val 19621536 ecr 165984], length 0 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [P.], seq 40:832, ack 33, win 92, options [nop,nop,TS val 165984 ecr 19621536], length 792 BlackPearl.local.ssh > Dauntless.local.52033: Flags [.], cksum 0xf83f (correct), seq 33, ack 832, win 58, options [nop,nop,TS val 19621537 ecr 165984], length 0 BlackPearl.local.ssh > Dauntless.local.52033: Flags [P.], seq 33:817, ack 832, win 58, options [nop,nop,TS val 19621537 ecr 165984], length 784 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [P.], cksum 0xc69e (correct), seq 832:856, ack 817, win 116, options [nop,nop,TS val 165985 ecr 19621537], length 24 BlackPearl.local.ssh > Dauntless.local.52033: Flags [P.], seq 817:969, ack 856, win 58, options [nop,nop,TS val 19621538 ecr 165985], length 152 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [P.], seq 856:1000, ack 969, win 141, options [nop,nop,TS val 165987 ecr 19621538], length 144 BlackPearl.local.ssh > Dauntless.local.52033: Flags [P.], seq 969:1689, ack 1000, win 70, options [nop,nop,TS val 19621545 ecr 165987], length 720 Dauntless.local.52033 > BlackPearl.local.ssh: Flags [P.], cksum 0xe669 (correct), seq 1000:1016, ack 1689, win 165, options [nop,nop,TS val 165994 ecr 19621545], length 16 ^C24 packets captured 24 packets received by filter 0 packets dropped by kernel Pas de souci, les paquets arrivent bien sur l'interface eth1. Puis, je remets les règles comme elles doivent l'être et là, surprise ça marche : # tcpdump -i eth1 -vv | grep Dauntless tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes Dauntless.local.52034 > BlackPearl.local.ssh: Flags [S], cksum 0xc9f6 (correct), seq 2282003582, win 5840, options [mss 1460,sackOK,TS val 193290 ecr 0,nop,wscale 6], length 0 BlackPearl.local.ssh > Dauntless.local.52034: Flags [S.], cksum 0xeed3 (correct), seq 2397272549, ack 2282003583, win 5792, options [mss 1460,sackOK,TS val 19648844 ecr 193290,nop,wscale 7], length 0 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [.], cksum 0x33e4 (correct), seq 1, ack 1, win 92, options [nop,nop,TS val 193290 ecr 19648844], length 0 BlackPearl.local.ssh > Dauntless.local.52034: Flags [P.], seq 1:33, ack 1, win 46, options [nop,nop,TS val 19648848 ecr 193290], length 32 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [.], cksum 0x33b7 (correct), seq 1, ack 33, win 92, options [nop,nop,TS val 193299 ecr 19648848], length 0 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [P.], seq 1:40, ack 33, win 92, options [nop,nop,TS val 193299 ecr 19648848], length 39 BlackPearl.local.ssh > Dauntless.local.52034: Flags [.], cksum 0x33b9 (correct), seq 33, ack 40, win 46, options [nop,nop,TS val 19648853 ecr 193299], length 0 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [P.], seq 40:832, ack 33, win 92, options [nop,nop,TS val 193299 ecr 19648853], length 792 BlackPearl.local.ssh > Dauntless.local.52034: Flags [.], cksum 0x3095 (correct), seq 33, ack 832, win 58, options [nop,nop,TS val 19648853 ecr 193299], length 0 BlackPearl.local.ssh > Dauntless.local.52034: Flags [P.], seq 33:817, ack 832, win 58, options [nop,nop,TS val 19648854 ecr 193299], length 784 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [P.], cksum 0xfef3 (correct), seq 832:856, ack 817, win 116, options [nop,nop,TS val 193299 ecr 19648854], length 24 BlackPearl.local.ssh > Dauntless.local.52034: Flags [P.], seq 817:969, ack 856, win 58, options [nop,nop,TS val 19648855 ecr 193299], length 152 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [P.], seq 856:1000, ack 969, win 141, options [nop,nop,TS val 193301 ecr 19648855], length 144 BlackPearl.local.ssh > Dauntless.local.52034: Flags [P.], seq 969:1689, ack 1000, win 70, options [nop,nop,TS val 19648862 ecr 193301], length 720 Dauntless.local.52034 > BlackPearl.local.ssh: Flags [P.], cksum 0x1ebf (correct), seq 1000:1016, ack 1689, win 165, options [nop,nop,TS val 193308 ecr 19648862], length 16 ^C22 packets captured 48 packets received by filter 0 packets dropped by kernel Trouvant ça bizarre, je reboote le serveur (qui reprend donc les règles normales du firewall) et là ça ne remarche plus : # tcpdump -i eth1 -vv | grep Dauntless tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C24 packets captured 24 packets received by filter 0 packets dropped by kernel # tcpdump -i eth0 -vv | grep Dauntless tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes Dauntless.local.60459 > BlackPearl.local.ssh: Flags [S], cksum 0xc5f3 (correct), seq 2834378858, win 5840, options [mss 1460,sackOK,TS val 270666 ecr 0,nop,wscale 6], length 0 Dauntless.local.60459 > BlackPearl.local.ssh: Flags [S], cksum 0xc305 (correct), seq 2834378858, win 5840, options [mss 1460,sackOK,TS val 271416 ecr 0,nop,wscale 6], length 0 13:16:09.746512 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has BlackPearl.local tell Dauntless.local, length 46 ^C78 packets captured 78 packets received by filter 0 packets dropped by kernel On voit que la communication passe par eth0 au lieu de eth1 .... mais en quoi les règles du firewall influent sur l'interface réseau où arrivent les paquets ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
PyKaBoo Posté(e) le 4 avril 2010 Partager Posté(e) le 4 avril 2010 On voit que la communication passe par eth0 au lieu de eth1 .... mais en quoi les règles du firewall influent sur l'interface réseau où arrivent les paquets ? Je pense que la réponse à cette question est à chercher sur tes règles de post-routing. Pour le prouver, tu devrais refaire ta trace sans le grep, tu devrais ainsi voir ton IP nattée (192.168.0.1 si je ne me trompe). Essayes de voir côté nattage si ton problème ne se situe pas à ce niveau... Peux-être que tes règles ne matchent pas tes paquets par ce qu'ils sont déjà nattés quand tu arrives aux niveau des chaine INPUT / OUTPUT. Quelqu'un sur le forum serait sûrement dire comment voir la table de nattage (ou un man iptables pourrait répondre)... PS : je connais pas bien iptables, mais si tu t'en sort toujours pas essayes de logger aussi les chaines INPUT et OUTPUT @+ Lien vers le commentaire Partager sur d’autres sites More sharing options...
fabien29200 Posté(e) le 4 avril 2010 Auteur Partager Posté(e) le 4 avril 2010 Bon plutôt que de reprendre point par point le script, j'ai suivi le conseil de Dark26, j'ai testé shorewall. C'est pas trop mal foutu. Par contre, je n'arrive pas à avoir de réponse DHCP lorsqu'il est activé. C'est toujours le serveur qui gère le DHCP avec dnsmasq. J'ai pourtant ajouté ceci dans les policies : loc $FW ACCEPT Lorsque je désactive iptables, j'ai une réponse... des idées ? Edit : Bon ben boulet inside, il manquait la règle inverse : $FW loc ACCEPT Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dark26 Posté(e) le 5 avril 2010 Partager Posté(e) le 5 avril 2010 ravi d'avoir pu aider.... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.