WAP dans la zone BLUE innacessible de la zone GREEN

Forum traitant de la distribution sécurisée montante nommée IP cop et basée sur la distribution Smoothwall. C'est à l'heure actuelle le forum le plus actif du site.

Modérateur: modos Ixus

WAP dans la zone BLUE innacessible de la zone GREEN

Messagepar lpascou » 14 Août 2008 13:59

Bonjour,

J'ai un IPCop configuré en GREEN (eth0, LAN, 192.168.16.0/24) + ORANGE (eth2, routeur Cisco VPN 192.168.18.0/24) + BLUE (eth3, Wireless access point Planet 192.168.17.0/24) + RED (eth1, modem SDSL Orange Business, IP public octroyé par le FAI).

J'ai configuré IPCop pour permettre l'octroi automatique des addresses aux ordinateurs connectés par le point d'accès Wifi et la navigation sur Internet en utilisant l'interface Web sans aucun problème (par l'écran Blue Access).

Par contre, je voudrais pouvoir administrer le point d'accès Wifi (192.168.17.253 , MAC 00:30:4F:3C:6E:D8) à partir de mon poste situé en zone GREEN; j'ai donc exécuté en ligne de commande sur IPCop :

# iptables -I WIRELESSFORWARD -i eth0 -o eth3 -d 192.168.17.253 -j ACCEPT
# iptables -I WIRELESSFORWARD -i eth3 -o eth0 -s 192.168.17.253 -j ACCEPT

de sorte que ma table WIRELESSFORWARD est maintenant :

Chain WIRELESSFORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth3 eth0 192.168.17.253 0.0.0.0/0
0 0 ACCEPT all -- eth0 eth3 0.0.0.0/0 192.168.17.253
0 0 ACCEPT all -- eth3 !eth0 0.0.0.0/0 0.0.0.0/0 MAC 00:30:4F:3C:6E:D8
0 0 DMZHOLES all -- eth3 * 0.0.0.0/0 0.0.0.0/0 MAC 00:30:4F:3C:6E:D8
0 0 ACCEPT all -- eth3 !eth0 192.168.17.10 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.10 0.0.0.0/0
48 2380 ACCEPT all -- eth3 !eth0 192.168.17.9 0.0.0.0/0
8 608 DMZHOLES all -- eth3 * 192.168.17.9 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.8 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.8 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.7 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.7 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.6 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.6 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.5 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.5 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.4 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.4 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.3 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.3 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.2 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.2 0.0.0.0/0
0 0 ACCEPT all -- eth3 !eth0 192.168.17.1 0.0.0.0/0
0 0 DMZHOLES all -- eth3 * 192.168.17.1 0.0.0.0/0
8 608 LOG_DROP all -- eth3 * 0.0.0.0/0 0.0.0.0/0

ce que devrait permettre (IMHO) la traversée dans les deux sens GREEN->BLUE et BLUE->GREEN des messages pour l'hôte 192.168.17.253.

Et pourtant je ne peux ni le pinguer ni l'accéder en http ! Pourriez vous m'aider à comprendre où est-ce que j'ai fait l'erreur et comment obtenir ce que je désire ?

Les tables de routage sont :

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<IP publique> * 255.255.255.248 U 0 0 0 eth1
10.23.11.0 192.168.18.253 255.255.255.0 UG 0 0 0 eth2
10.23.10.0 192.168.18.253 255.255.255.0 UG 0 0 0 eth2
192.168.18.0 * 255.255.255.0 U 0 0 0 eth2
192.168.17.0 * 255.255.255.0 U 0 0 0 eth3
192.168.16.0 * 255.255.255.0 U 0 0 0 eth0
default <gateway publique> 0.0.0.0 UG 0 0 0 eth1

Je peux pinguer le point d'accès à partir du IPCop :

# ping 192.168.17.253
PING 192.168.17.253 (192.168.17.253): 56 data bytes
64 bytes from 192.168.17.253: icmp_seq=0 ttl=255 time=1.535 ms
64 bytes from 192.168.17.253: icmp_seq=1 ttl=255 time=1.289 ms
64 bytes from 192.168.17.253: icmp_seq=2 ttl=255 time=1.278 ms
64 bytes from 192.168.17.253: icmp_seq=3 ttl=255 time=1.258 ms
64 bytes from 192.168.17.253: icmp_seq=4 ttl=255 time=1.266 ms
64 bytes from 192.168.17.253: icmp_seq=5 ttl=255 time=1.270 ms
--- 192.168.17.253 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.258/1.316/1.535/0.098 ms

et aussi l'interface BLUE à partir du réseau GREEN:

K:\Documents and Settings\lpu.ICARENET>ping 192.168.17.254

Pinging 192.168.17.254 with 32 bytes of data:

Reply from 192.168.17.254: bytes=32 time<1ms TTL=64
Reply from 192.168.17.254: bytes=32 time<1ms TTL=64
Reply from 192.168.17.254: bytes=32 time<1ms TTL=64
Reply from 192.168.17.254: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.17.254:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

J'avoue être à court d'idées, pourriez vous m'aider s'il vous plaît ?

Cordialement

Laurent PASCOU
lpascou
Matelot
Matelot
 
Messages: 3
Inscrit le: 14 Août 2008 11:13

Communication GREEN <-> BLUE : aucune idée ?!

Messagepar lpascou » 18 Août 2008 11:10

Bonjour,

Je n'ai toujours pas de solution; y-a-t-il quelqu'un pour m'aider, s'il vous plaît ?

Cordialement,

lpascou
lpascou
Matelot
Matelot
 
Messages: 3
Inscrit le: 14 Août 2008 11:13

Messagepar ccnet » 18 Août 2008 12:54

Je suis un peu surpris car : http://forums.ixus.fr/viewtopic.php?t=24737 (Question : Qu'est-ce qu'IPCOP bloque et laisse passer comme flux.) nous confirme que l'accès de Green vers Blue est ouvert.
Je ne vois donc pas de raison d'éxécuter :

# iptables -I WIRELESSFORWARD -i eth0 -o eth3 -d 192.168.17.253 -j ACCEPT
# iptables -I WIRELESSFORWARD -i eth3 -o eth0 -s 192.168.17.253 -j ACCEPT


Une question concernant votre point d'accès : je suppose qu'il dispose de contrôles pour déterminer qui peut ou non l'administrer. Quels sont ces contrôles ?
ccnet
Amiral
Amiral
 
Messages: 2687
Inscrit le: 27 Mai 2006 12:09
Localisation: Paris

Messagepar lpascou » 20 Août 2008 11:12

Bonjour,

D'abord je vous remercie pour votre réponse; j'avais laissé ce problème temporairement de côté et c'est pour cela que la vois qu'aujourd'hui.

Mois aussi je m'attendais d'avoir accès libre en connexion de GREEN vers BLUE (ce qu'est apparamment vrai) et les réponses garantis par la règle générale de laisser passer les réponses (related) dans l'autre sens (ce que n'est pas vrai).

La preuve et que je ne peux pas faire de ping ni de connexion en http vers mon point d'accès. Et c'est l'IPCOP qui bloque car si je fait sur ma machine en LAN :

K:\>ping 192.168.17.253

et sur IPCOP :

root@gateway:~ # tcpdump -i eth3 host 192.168.17.253

je vois bien le message qui parte vers le WAP et sa réponse

10:07:20.451269 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 20232, length 40
10:07:20.452285 IP 192.168.17.253 > 192.168.16.21: ICMP echo reply, id 1280, seq 20232, length 40
10:07:25.444962 arp who-has 192.168.17.253 tell 192.168.17.254
10:07:25.445806 arp reply 192.168.17.253 is-at 00:30:4f:3c:6e:d8 (oui Unknown)
10:07:25.700349 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 20488, length 40
10:07:25.701349 IP 192.168.17.253 > 192.168.16.21: ICMP echo reply, id 1280, seq 20488, length 40
10:07:31.200095 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 20744, length 40
10:07:31.201132 IP 192.168.17.253 > 192.168.16.21: ICMP echo reply, id 1280, seq 20744, length 40
10:07:36.699847 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 21000, length 40
10:07:36.700873 IP 192.168.17.253 > 192.168.16.21: ICMP echo reply, id 1280, seq 21000, length 40

10 packets captured
10 packets received by filter
0 packets dropped by kernel[/code][/i]

mais de l'autre côté :

# tcpdump -i eth0 host 192.168.17.253

la demande passe mais la réponse non :

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
10:05:15.967150 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 19208, length 40
10:05:21.205821 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 19464, length 40
10:05:26.705574 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 19720, length 40
10:05:32.205327 IP 192.168.16.21 > 192.168.17.253: ICMP echo request, id 1280, seq 19976, length 40

4 packets captured
8 packets received by filter
0 packets dropped by kernel

Et même si inutiles, mes commandes auraient dû de surcroît permettre l'accès. Il semblerait que le filtre est ailleurs, mais où ? Quel moyen de diagnostique supplémentaire pourrais-je utiliser pour comprendre ?

Je vous remercie d'avance pour votre aide.

Cordialement,

lpascou
lpascou
Matelot
Matelot
 
Messages: 3
Inscrit le: 14 Août 2008 11:13


Retour vers IPCop

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité

cron