Emile "iMil" Heitor 's home

Ç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.

Imaginons le scénario suivant :

”
- Bonjour, Pizza Free’30, que puis-je faire pour vous ?
- Bonjour madame, j’aimerais commander une Spicy-chaude
- Bien sur monsieur, il vous en coutera 29€90
- Super, je peux espérer être livré quand ?
- À titre indicatif, la livraison aura lieu dans 15 à 30mn
- Génial, merci beaucoup
- Je me joins à toute l’équipe de Free’30 pour vous souhaiter une bonne soirée
”

40mn plus tard

”
- Oui bonjour, j’ai commandé une Spicy-chaude il y a 40mn mais je n’ai toujours aucune nouvelle de votre part, est-ce normal ?
- Ah ? laissez moi regarder
- Merci j’attend
…
- Monsieur ? je viens de m’enquerir auprès de notre service Pizzaïolo, en fait il se trouve que nous n’avons plus de place dans notre four
- Hmm, oui… et donc ?
- Il va falloir patienter encore quelques minutes monsieur, mais je ne saurais vous dire combien de temps
- Ah, c’est super ça…
- Oui nous sommes navrés monsieur, mais le four appartient à France’30, et nous ne controllons pas ce qui s’y passe
- Mouais ok… bon bah je vais patienter quoi…
- Voila, une autre question monsieur ?
- Bah nan… merci.
- Je me joins à toute l’équipe de Free’30 pour vous souhaiter une bonne soirée
- mouais.
”

1h20 plus tard

”
- Oui bonjour, j’ai commandé une Spicy-chaude il y a 1h20 et je n’ai toujours aucune nouvelle de votre part. Je suis au courant de vos histoires de four monopolisés par France’30, mais je commence à serieusement avoir faim.
- Ah oui, oui je vois sur mon logiciel que le four est toujours occuppé par France’30… il va falloir patienter monsieur…
- Oui, alors c’est à dire qu’à un moment donné je vais prendre ma pizza chez 9’30 quoi, parce voyez vous, il est 21h20 et j’ai faim.
- Je comprend monsieur, mais il faut patienter que le four se libère
- Ouais ok. Merci au revoir
- Je me joins à toute l’équipe de Free’30 pour vous souhaiter une bonne soirée
- ouais, tcho.

[quelques mails et coups de téléphone plus tard]

2h40 plus tard
”
- Oui bonjour, j’ai commandé une Spicy-chaude il y a pratiquement 3 heures, et j’en ai vraiment marre là.
- Ah, oui, oui oui effectivement, je vois que votre pizza est sur la file d’attente, mais le pizzaïolo de France’30 ne l’a pas encore enfournée, mais je vous rassure, cette étape là ne dure généralement que quelques minutes
- Quelques minutes ?? mais j’ai commandé ma pizza il y a 2h40 !
- Oui désolé monsieur, mais la cuisson de votre pizza ne dépend pas de nous. Avez-vous une autre question ?
- Nan.
- Je me joins à toute l’équipe de Free’30 pour vous souhaiter une bonne soirée
- …
”

5ème semaine d’attente et pas l’ombre d’un lien. À Paris attention hein, pas à Pwetpwet-sur-Yonne. 5 semaines and counting. Je pense pas que j’aurais attendu ma pizza plus d’1h, et de plus, on me l’aurait remboursée, au pire, on m’aurait filé un bon d’achat. Mais là non, tu vas juste te faire foutre en silence et t’attend ton tour.

Update

Eh bah voila, il suffisait d’en parler pour que ça se débloque :

Sending 1, 16-byte ICMP Echo to 88.181.26.254, timeout 5000 msec, TTL 64
Type Control-c to abort
Reply from 88.181.26.254   : bytes=16 time=31ms TTL=64
Success rate is 100 percent (1/1), round-trip min/avg/max=31/31/31 ms.

Ça va faire 3 semaines que j’attend de passer l’étape 1 chez Free. C’est pas comme si j’étais surpris, à chaque déménagement, c’est l’enfer. En fait, s’ils n’étaient pas les seuls à proposer une IP fixe à ce prix, ça fait belle lurette que je les aurais envoyé chier. Bref, en attendant, je squatte un access point en toute légalité puisqu’il s’agit d’un hotspot Neuf Wifi FON que j’ai parfaitement le droit d’utiliser en tant que Fonero. Le Link Quality est pas mauvais, ~30%, mais deux aspects sont ennuyeux: ils n’autorisent que les ports http/s, SMTP et SIP, et surtout, on est obligé de se re-authentifier toutes les deux heures sur un portail captif.
Pour le premier point, un simple VPN sur le port 443 me permet d’utiliser ssh. Pour le second, c’est un peu plus sioux. Voici, pour ceux d’entre vous qui rencontreraient le même type de désagrément, un petit bout de script permettant d’automatiser l’enregistrement sur le portail captif Neuf/FON à l’aide de curl :

#!/bin/sh

url="https://hotspotneufbox.neuf.fr/d3/nb4_crypt.php"
okmatch="licitations"
login="identifiant%40fon" # %40 == @ url encodé
password="password_fon"

# quel que soit le site visité, on sera redirigé vers le
# portail captif qui génerera un token. L'utilisation du switch
# -L permet de suivre la redirection de type 302
challenge=`curl -L http://www.google.com|grep name=\"challenge|sed -r 's/.*value=\"([0-9a-z]+)\".*/\1/'`

echo "challenge: ${challenge}"

# la phase 2 renvoie une réponse au token
response=`curl -L -d "username=${login}&password=${password}&cond=on&accessType=fon&nb4=https://hotspotneufbox.neuf.fr/d3/nb4_crypt.php&challenge=${challenge}" ${url}|grep response=|sed -r 's/.*response=([0-9a-z]+).*/\1/'`

echo "reponse: ${response}"
# enfin, un refresh renvoie sur une page qui attend la
# réponse précedente pour activer la connexion
final=`curl -L "http://192.168.2.1:3990/logon?username=fon/${login}&response=${response}&uamip=192.168.2.1&userurl=http%3A%2F%2Fwww.fon.com%2Ffr%2Flanding%2Ffoneroneufbox%3Bfon%3B%3B"|grep ${okmatch}`

if [ ! -z "${final}" ];then
        echo "connected"
else
        echo "connection failed"
fi

Un petit while [ 1 ] muni de quelques conditions permet de garder un lien à peu près stable.

Ce midi, le domU GCU était injoignable. Une connexion VNC nous permet de voir que le noyau vomissait depuis quelques minutes une floppée de :

rtk0: unable to allocate Tx cluster

Une rapide recherche nous amène sur ce post qui, comme on pouvait le soupçonner, explique que les cartes de type rtl8139 sont moisies, mais que dans l’urgence, l’ajout de la directive :

options		NMBCLUSTERS=4096

à la conf kernel permet de résoudre le problème.

Dans le cadre d’un projet perso dont j’aurai bientot largement l’occasion de vous parler, j’ai été confronté à un petit casse tête dont je vais vous exposer l’énoncé et la solution.

Le but de l’opération est de faire booter plusieurs instances de NetBSD diskless, en utilisant le même root filesystem NFS, mais avec des repertoires /etc et /dev séparés pour des raisons évidentes de marchage sur les pieds.

La réalisation de cette bidouille s’effectue en deux étapes. Tout d’abord, il est evidemment nécessaire de “reconnaitre” la machine qui boote, et pour cela, c’est une directive du dhcpd.conf qui nous vient en aide. En effet, la directive option host-name permet de “passer” à la machine qui boote une information sur son nom. Voici à quoi ressemble une section typique du fichier :

        host toto {
                hardware ethernet 10:10:10:10:10:10;
                fixed-address 192.168.0.20;
                option host-name "toto";
                filename "pxeboot_ia32.bin";
                next-server 192.168.0.1;
                option root-path "/home/netbsd/rootdir";
        }

Préalablement à la seconde étape, nous devons evidemment créer des repertoires etc et dev reconnaissables, par exemple :

# pwd
/home/netbsd/rootdir
# mkdir -p toto/etc toto/dev

Puis peupler etc grace au set binaire NetBSD prévu à cet effet :

# tar zxvfp /path/vers/etc.tgz -C /home/netbsd/rootdir/toto

Enfin, pour faire en sorte que rc charge la petite magouille qui permettra de surcharger les repertoires localisés, nous créons un rc.d-script de cette forme :

# cat /home/netbsd/rootdir/etc/rc.d/premount
#!/bin/sh

# PROVIDE: premount
# REQUIRE: root
# BEFORE: mountcritlocal

$_rc_subr_loaded . /etc/rc.subr

name="premount"
start_cmd="premount_start"
stop_cmd=":"

premount_start()
{
        echo -n "mounting local NULLfs..."
        mount -t null /`hostname`/etc /etc
        mount -t null /`hostname`/dev /dev
        echo "done."

        if [ ! -c /dev/zero ];then
                echo -n "creating devices..."
                cd /dev && ./MAKEDEV all
                echo "done."
        fi
}

load_rc_config $name
run_rc_command "$1"

Ce qui nous permet, avant le montage du filesystem, de “mounter” nos repertoires locaux etc et dev en utilisant nullfs.

Pour le reste de la configuration PXE / NFS, je vous renvoie à la version en ligne de mon article paru dans GLMF HS Spécial BSD.