Emile “iMil” Heitor ‘s home

Un des trucs, sinon LE truc que je crevais d’envie de faire dans mon nouvel appart, c’était de monter un vrai hotspot, comme je l’expliquait deux news plus bas. Eh bah ça y est, c’est up. Je sais pas encore bien si j’en ferai un article ou si je donnerai des astuces au coup par coup, mais en attendant, voici à quoi ça ressemble.

Deux OpenWRT configurés en simples bridges permettent aux invités de se raccorder au VLAN dédié au wireless public :

/etc/config/wireless

config wifi-device  wifi0
        option type     atheros
        option disabled 0
        option mode             11b
        option distance         10000
        option diversity        0
        option txantenna        1
        option rxantenna        1
        option channel          6

config wifi-iface
        option device   wifi0
        option ifname   ath0
        option network  lan
        option mode     ap
        option ssid     Empire-Network
        option encryption none
        option txpower 18

/etc/config/network

config interface loopback
        option ifname   lo
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

config interface lan
        option ifname   eth0 ath0
        option type     bridge
        option proto    static
        option ipaddr   192.168.200.253
        option netmask  255.255.255.0

Où un serveur dhcp leur fournira une IP dans le subnet adéquat. Un simple règle pf redirigera alors toute requète http vers un portail captif qui expliquera à l’invité quelles informations entrer dans son browser afin de pouvoir utiliser HTTP, HTTPS et FTP (notez que pour le moment un seul sur une bonne 30aine a reussi à effectuer cette opération heutement technique…). Quelques règles de QoS m’assurent que l’invité ne crame pas toute ma bande passante :

/etc/pf.conf

int="fxp0"

table <empire_guests> { 192.168.200.0/24, ! 192.168.200.254, ! 192.168.200.253, ! 192.168.200.252 }

altq on $int cbq bandwidth 28Mb queue { empirenet_in, empirenet_out }
queue empirenet_in bandwidth 2Mb priority 1 cbq(default)
queue empirenet_out bandwidth 128Kb priority 7

rdr on $int inet proto tcp from any to <empire_guests> port www -> 127.0.0.1 port 80

pass in on $int from any to <empire_guests> queue empirenet_in
pass out on $int from <empire_guests> to any queue empirenet_out

L’utilisateur passe alors via Squid et son activité est soumise au filtrage de squidGuard dans lequel j’ai interdit les catégories !aggressive !violence !hacking !ads !porn !warez !suspect.
J’applique sur le switch des access-list par port qui n’autorisent que les protocoles HTTP, SSH et DHCP.

[...]
ip access-list extended wifiout
 permit ip any host 192.168.200.254
 permit tcp any any eq http
 permit udp any any eq bootps
 permit tcp any any eq ssh
[...]
interface e 18
 ip access-group wifiout in
[...]

Le tout est graphé par Cacti, notemment grace à l’extension dhcpd-snmp de Net-SNMP et au template cacti associé.

Si vous passez dans le 17eme, cherchez le ssid “Empire-Network” :)

update

Bon bah en fait si, y’aura un article :)

Ça faisait un petit moment que j’avais envie de monter une vraie infrastructure Wireless publique. Un vrai truc quoi, avec tout ce que ça suppose, VLAN, proxy filtrant, QoS, logging, monitoring… et il se trouve qu’il a un moment de cela, j’ai fait l’aquisition de ce genre de bestiau.

Bien qu’il existe une doc officielle, on ne trouve pas autant de posts, exemples, HOWTOs et autres tutoriaux qu’on a l’habitude de trouver dans le monde du bien. Je vous propose un petit topo sur l’art et la manière de réaliser un simple NAT avec ce switch.

On déclare tout d’abord deux des VLANs, par port, qui constitueront notre réseau :

vlan 2 name LAN by port
 untagged ethe 2 to 8
 no spanning-tree
  router-interface ve 1

vlan 3 name WAN by port
 untagged ethe 1
 no spanning-tree
  router-interface ve 2

Les ports spécifiés ne seront pas taggés, et nous ne souhaitons pas utiliser de STP.

On place ensuite une access-list représentant le réseau qui aura le droit d’être NATté :

access-list 10 permit 192.168.1.0/24

Un point clé, on définit deux interface virtuelles de type ve, qui serviront d’interfaces de routage pour ces deux réseaux :

interface ve 1
 ip address 192.168.1.254 255.255.255.0
!
interface ve 2
 ip address 212.10.20.30 255.255.255.0

Où 212.10.20.30 représente notre IP publique.

Enfin, on configure le NAT à propremement dit :

ip nat inside
ip nat inside source list 10 pool NAT1 overload
ip nat pool NAT1 212.10.20.30 212.10.20.30 prefix-len 24

La conf est assez explicite, mais pour tout eclaircissement, rendez-vous sur la doc officielle.

update

ah-ah-ah. Alors. J’vais baver. Donc hier, à peu près à l’heure ou je postais ce billet, le bestiau arrête de natter. Comme ça. Evidemment, rien changé, rien débranché, juste, il s’arrete de natter.
Je reload, je cold restart, j’enlève / remet les rules de nat, je downgrade, j’upgrade. Rien-a-faire. Cette merde refuse de natter. Evidemment, matos propriétaire, brosse toi pour debugger. En tout cas, la conf sus-citée n’a fonctionné que pendant quelques heures. Si jamais j’en viens à bout, jvous tiendrai au jus, mais dans l’immediat :

nat on $ext from 192.168.1.0/24 to any -> $ext

Ça, ça juste marche.

update

En remplaçant :

interface ve 2
 ip address 212.10.20.30 255.255.255.0

par

interface ve 2
 ip nat-address 212.10.20.30 255.255.255.0

Ou :

The nat-address parameter applies to active-standby configurations. This parameter configures a shared IP interface for use with SLB source NAT. Enter the same command with the same IP address on each of the SIs in the active-standby configuration. The address is active only on one SI (the SI that is currently active) at a time.

Rien à voir avec le schmillblick donc.

Tout vient de se remettre à fonctionner. Reste à savoir pour combien de temps…

update

Après avoir débranché puis rebranché le lien WAN, même symptome que précedemment. Fin de l’histoire, j’ai collé une vieille Netra X1 sous OpenBSD comme gateway, pf ne perd pas les sessions, lui.