Je vous présente via cet article ma transformation d’un EeePC, qui ne me servait à rien, en routeur-passerelle réseau. Je vous présente mon travail, mais il est très facile d’adapter ce travail à votre utilisation et à votre propre machine afin de la transformer en un super routeur Linux qui tue tout

Article illustré par l’exemple

Cette documentation est adapté à mon LAN qui est paramétré sur le subnet 10.0.69.0/24. Le eeegw, comme je l’appelle, prend donc l’adresse 10.0.69.250/24 est sera la gateway de mon réseau afin que mes autres machines puissent accéder à l’internet.

À quoi ça sert de monter sa propre Gateway ?

• Ne pas avoir à redémarrer sa connexion internet chaque fois qu’on a envie de toucher aux règles de firewalling. En effet les box des FAI nécessitent de redémarrer pour prendre en compte de nouveaux paramètres
• Ne pas avoir une boite noire à la place de routeur : on peut surveiller son réseau et savoir quels sont les packets qui y passent
• Pouvoir loguer via iptables et ulogd par exemple (futur article)
• Pouvoir grapher via rrdtool / Mrtg la bande passante qui passe par vos liens
• Pouvoir héberger un petit blog (par exemple) directement sur votre passerelle
• Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante (futur article)
• Savoir exactement ce qui se passe avec votre connexion internet
• Mettre en place des outils de détection d’attaques sur votre réseau via SNORT (futur article)

Choisir le bon matériel

N’importe quel ordinateur avec un tant soit peu de puissance est suffisant pour faire un bon gateway, il suffit que cette machine soit munie de plusieurs interfaces réseau.

Durant des années j’ai eu en tant que passerelle un PII 266Mhz muni de 128MB de ram et d’un disque dur de 2Go. Pour cette nouvelle gateway j’ai choisi le EeePC 7″ que j’ai baptisé eeegw

Pourquoi ce choix? Parce que le EeePC dispose de beaucoup d’avantages à être transformé en Gateway :

• Il est muni d’une batterie donc non affecté par une coupure de courant éventuelle
• Il dispose d’une interface réseau ethernet et d’une interface wifi
• La carte wifi intégrée est une Atheros et supporte donc (via le pilote madwifi) les multi wireless WAN
• Sa puissance est honorable (512 de RAM / 900Mhz / 4Go de SSD)
• On peut très facilement installer une distribution GNU/Linux dessus
• On peut installer un serveur web dessus en toute tranquillité
• Son matériel est pleinement supporté par le noyau Linux
• Sa consommation est très faible, permettant donc d’être allumé 24/24 sans détruire son budget EDF

Installer la bonne distribution

Si comme moi vous souhaitez transformer un EeePC, je vous conseille Debian. Personnelement j’aurais bien choisi Gentoo, mais le EeePC prendrait trop de temps à compiler, et ne refroidit pas spécialement bien.

Installer la distribution Debian sur un EeePC est très bien documenté, il vous suffit de créer une clée usb bootable. Je vous renvoie à la documentation de Debian : EeeDebian.

Glossaire des packets Debian nécessaires pour ce howto

• iproute
• iptables
• apache2
• munin munin-node
• wireless-tools

Se connecter aux FAI sur les interfaces concernées

Je dispose pour ma part d’une connexion au web fournie via le fournisseur d’accès Nerim (j’établis donc la connexion en PPPoE comme avec la plupart des fournisseurs ADSL). Je dispose d’une seconde connexion via du WiFi fourni par un de mes voisins (qui accepte que je me serve de sa connexion).

Ne vous inquiétez pas si vous n’avez qu’une seule connexion, ou si vous avez Free+Numericable ou n’importe quelle autre combinaison, cet article est facilement adaptable à votre configuration.

Connexion PPP

Configurez la connexion PPPoE:
/etc/ppp/peers/dsl-provider
# Minimalistic default options file for DSL/PPPoE connections
noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
#persist
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0
user "plopplop@adslc.fai.fai"
usepeerdns

Et enregistrez vos identifiants:
/etc/ppp/chap-secret
# Secrets for authentication using CHAP
# client server secret IP addresses
"plopplop@adslc.fai.fai" * "mdpdelamortquituedevotreFAI"

Et créez le script qui initiera cette connexion:
/etc/eeegw/fai.sh
#!/bin/bash
/usr/sbin/pppd call dsl-provider

Placez ensuite ce script fai.sh dans les régles de pre-up du fichier Debian /etc/network/interfaces. Votre connexion ppp sera ainsi demarré au boot de la eeegw. Voir, pour exemple, le mien en fin d’article.

Finalement, un script pour s’assurer que votre connexion PPP est bien up avec votre fournisseur d’accès ADSL. Il est lancé via un cron toutes les 5 minutes ainsi, si la connexion tombe, ce script lui permettra de se relancer automatiquement.
/etc/eeegw/nerim.sh
#!/bin/bash

rm -f /var/run/checkadsl

Connexion wifi

Voici une simple configuration de l’interface WiFi. Je vous renvoie à la documentation adaptée pour plus de détails.

Placez la clé wep dans /etc/eeegw/fb.key puis créez le script
/etc/eeegw/wifi.sh
#!/bin/bash
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode sta
sleep 5
ifconfig ath0 up
iwconfig ath0 essid freebox key `cat /etc/eeegw/fb.key`
dhclient ath0

Ajoutez /etc/eeegw/wifi.sh à vos régles pre-up du fichier /etc/network/interfaces

Autre type de connexion

Si par exemple vous êtes chez Free, je vous conseille de monter votre Freebox en mode bridge. Ainsi votre eeegw n’aura plus qu’à effectuer un bound dhcp sur eth0 afin d’obtenir l’IP publique Free et tous les packets arriveront donc directement sur votre eeegw.

Pour redispatcher la connexion, vous pouvez soit le faire via une seconde carte réseau sur votre eeegw (ou votre pc équivalent), soit transformer votre eeegw en point d’accès WiFi! Transformer un eeepc en eeeap est expliqué ici : eeeAP

Faire fonctionner les deux connexions ensemble

Plusieurs choix s’offrent à vous:

• Vous n’avez qu’un seul lien vers une seule connexion internet. Passez directement à l’étape suivante.
• Vous avez deux connexions web qui ont le même débit et vous souhaitez partager symétriquement le débit
• Vous avez deux connexions web qui n’ont pas le même débit et vous souhaitez partager asymétriquement le débit
• Vous avez deux connexions web qui ont ou pas le même débit : une en tant que connexion principale et l’autre en secours ou pour certaines routes en particulier

Personnellement j’utilise cette dernière solution, mais je vais aussi vous expliquer les deux autres possibilités de répartiton.

Activer IP Forwarding

Quel que soit les choix que vous ferrez par la suite vous avez besoin d’activer ip_forward dans votre noyau.

Indispensable pour que votre routeur fonctionne!
/etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Et rechargez la configuration:
# sysctl -p

Distribuer sur deux connexions ayant le même poids

Imaginons que nous ayons FAI-1 derrière eth1 et FAI-2 derrière eth2. Ce deux connexions sont relativement identiques et nous souhaitons donc simplement distribuer équitablement le traffic et ainsi profiter du débit des deux connexions.

eth1: net=192.168.1.0/24, IP=192.168.1.130, Gateway=192.168.1.1
eth2: net=192.168.2.0/24, IP=192.168.2.131, Gateway=192.168.2.1

ip route add 192.168.1.0 dev eth1 src 192.168.1.130 table fai1
ip route add default via 192.168.1.1 table fai1

ip route add 192.168.2.0 dev eth2 src 192.168.2.131 table fai2
ip route add default via 192.168.2.1 table fai2

ip route add 192.168.1.0 dev eth1 src 192.168.1.130 ip route add 192.168.2.0 dev eth2 src 192.168.2.131

ip rule add from 192.168.1.130 table fai1
ip rule add from 192.168.2.131 table fai2

ip route add default scope global nexthop via 192.168.1.1 dev eth1 weight 1 nexthop via 192.168.2.1 dev eth2 weight 1

Distribuer sur deux réseaux de poids différents

Petit schéma explicatif de ce qu’on peut espérer faire avec une passerelle comme eeegw

(schéma a compléter)

Un script pour loadbalancer les connexions sur deux wan ayant différents poids : Notre eeegw devient multi lien ou dualwan

#!/bin/bash

##ip rule flush

## recupere l'ip du peer
peer=$(/sbin/ifconfig ppp0 | /bin/grep "P-t-P" | /usr/bin/cut -d":" -f3 | /usr/bin/cut -d" " -f1)

ip route add ${peer} dev ppp0 table uplink1
#ip route add default via 213.41.185.56 table uplink1

ip route add 192.168.0.0/24 dev ath0 src 192.168.0.12 table uplink2
#ip route add default via 192.168.1.1 table uplink2

ip rule add from 192.168.0.12 table uplink2
ip rule add from 213.41.185.56 table uplink1

ip route add default scope global nexthop via 192.168.0.254 dev ath0 weight 1 nexthop via ${peer} weight 3

Le but du script share_wan.sh est d’enlever les deux routes par defaut engendré par le faite de se connecter en ppp et avec dhcp sur le wifi.
Ensuite il faut mettre en route par defaut soit le lien ppp soit le lien wifi.
La dernière ligne sert a donner un poids de 3 à la connexion Nerim et un poid de 1 à la connexion wifi.

Ainsi on enverra 3 fois plus de packets à Nerim qu’au WiFi.

/etc/eeegw/share_wan.sh

#!/bin/bash
ip route del default dev ppp0 scope link
ip route del default via 192.168.0.254 dev ath0
ip route add default scope global nexthop via 192.168.0.254 dev ath0 weight 1 nexthop via ${peer} weight 3


Routes par defaut / routes statiques

J’utilise ce système de route static via mon script route_static.sh pour définir via quel FAI je préfère me rendre pour tel ou tel service. C’est très pratique. (Je rappelle que j’utilise le cas numero 4, c’est à dire que ma connexion ppp est ma connexion principale, mais la connexion wifi ne me sert que ne backup au cas ou, et pour des routes particulières).

/etc/eeegw/route_static.sh
#!/bin/bash

## recupere l'ip du peer PPP
peer=$(/sbin/ifconfig ppp0 | /bin/grep "P-t-P" | /usr/bin/cut -d":" -f3 | /usr/bin/cut -d" " -f1)

# telephone passe par la connexion ppp
ip route add 81.93.243.132 via ${peer}

# vpn perso passe par la connexion wifi
ip route add 81.93.247.160 via ${peer}
ip route add 193.47.184.2 via ${peer}
ip route add 94.23.219.37 via 192.168.0.254

Serveur DHCP

L’eeegw doit donner des IPs via DHCP aux différentes machines du réseau.
# apt-get install dhcpd

/etc/dhcp3/dhcpd.conf
# option definitions common to all supported networks...
option domain-name "lucifer.bragon.info";
option domain-name-servers 8.8.8.8;

ddns-update-style none;

authoritative;

default-lease-time 86400;
max-lease-time 86400;

subnet 10.0.69.0 netmask 255.255.255.0 {
range 10.0.69.10 10.0.69.199;
option routers 10.0.69.250;
}

# Réservations
host satanas {
hardware ethernet 00:02:b3:21:40:c0;
fixed-address 10.0.69.18;
option routers 10.0.69.250;
option broadcast-address 10.0.69.255;
}

Rajouter des VPN

Vous pouvez bien sûr rajouter des connexions VPN sur votre eeegw.
En effet cela vous permettra de directement propager la connectivité au VPN à toutes les machines de votre lan.
Pour se faire je vous renvoi vers les articles de target0 et moi même concernant les VPN.

http://geekfault.org/2009/10/04/allocation-dipv6-over-openvpn/
http://geekfault.org/2009/09/24/allocation-dadresses-ipv4-publiques-over-vpn/

Quality Of Service / tc qdisc

La qualité de service sur le reseau est très importante si vous ne voulez pas que vos utilisateurs se plaignent de lags.

Par exemple lorsqu’un appel en VoIP est émit, il est très désagréable de se mettre à laguer tout d’un coup car un de vos collaborateurs envoie un e-mail avec une pièce jointe énorme. Pour éviter d’avoir ce genre de désagrements, il faut mettre des priorités sur le traffic entrant et sortant.

J’ai décidé de faire un article prochainement afin de vous expliquer comment je gère la QOS de ma eeegw.

Firewalling

/etc/eeegw/firewall.sh
#!/bin/bash
# REMISE à ZERO des règles de filtrage
iptables -F
iptables -t nat -F

# DEBUT des "politiques par défaut"
# Je veux que les connexions entrantes soient bloquées par défaut
iptables -P INPUT DROP

# Je veux que les connexions destinées à être forwardées soient acceptées par défaut
iptables -P FORWARD ACCEPT

# Je veux que les connexions sortantes soient acceptées par défaut
iptables -P OUTPUT ACCEPT

# FIN des "politiques par défaut"
# Pas de filtrage sur l'interface de "loopback"
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT

#on ne filtre pas les vpn
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i tap1 -j ACCEPT
iptables -A INPUT -i ethylix0 -j ACCEPT

# J'accepte le protocole ICMP (i.e. le "ping")
iptables -A INPUT -p icmp -j ACCEPT

# J'accepte le protocole IGMP (pour le multicast)
iptables -A INPUT -p igmp -j ACCEPT

# J'accepte les packets entrants relatifs ? des connexions d?j? ?tablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 2605 -j ACCEPT

#apache
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#tftp
iptables -A INPUT -p udp --dport 69 -j ACCEPT

#mon smtp
iptables -A INPUT -p tcp --dport 25 -j ACCEPT

#vpn
iptables -A INPUT -p tcp --dport 7777 -j ACCEPT

# voip
#iptables -A INPUT -p tcp --dport 5060 -j ACCEPT
#iptables -A INPUT -p tcp --dport 5061 -j ACCEPT

# supervision zabbix

iptables -A INPUT -p tcp --dport 10050 -j ACCEPT
iptables -A INPUT -p tcp --dport 10051 -j ACCEPT

#Munin
iptables -A INPUT -p tcp --dport 4949 -j ACCEPT

# La règle par défaut pour la chaine INPUT devient "REJECT" (il n'est pas possible de mettre REJECT comme politique par défaut)
#iptables -A INPUT -j REJECT

#forward de la connection
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ath0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tap1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ethylix0 -j MASQUERADE

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o ppp0 --clamp-mss-to-pmtu

Le but du script de firewall est d’être lancé une première fois, puis d’être sauvegardé comme la Debian-Way le suggère. Pocédons donc comme suit :
# sh /etc/eeegw/firewall.sh
# iptables-save > /etc/network/firewall
Ainsi au boot des interfaces la machine lancera les règles iptables sauvegardées.

Firewall en sortie

NB : Dans cette exemple le firewall n’agit qu’en entrée, c’est à dire que par defaut nous laissons tout sortir sur le réseau. Vous pourriez sans aucun soucis filtrer en sortie.

Exemple de regles de filtrage en sortie :
# A mettre en début de script pour n'accepter explicitement QUE ce qui est autorisé.
iptables -P OUTPUT DROP

# Règles output fonctionnement de base
iptables -A OUTPUT -p tcp -o eth0 --dport domain -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --dport domain -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport ntp -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --dport ntp -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport rsync -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --dport rsync -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport http -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport smtp -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport ssh -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 --dport ftp -j ACCEPT

Explication fonctionnement du NAT

Imaginons que vous ayez un serveur FTP sur la machine A.
Imaginons que vous ayez un serveur Web sur la machine B.
Afin qu’un client puisse s’y connecter en venant de l’internet vous ne pouvez pas lui donner comme adresse afin de s’y connecter une des ip de votre LAN, mais l’ip que vous a attribué le FAI lors de votre connexion à celui-ci.
Le NAT est le fait que la eeegw sache vers quelle machine transmettre le traffic de tel ou tel service.
Ainsi le client établi une connexion FTP vers votre IP publique, la connexion FTP arrive sur votre eeegw qui va savoir qu’il faut qu’elle transmette ce traffic vers la machine A.

Pour plus d’explication sur comment faire ça, allez voir la partie firewall de la documentation.
Pour plus d’explication n’hésitez pas à aller lire la documentation Wikipédia sur le sujet.

Régles de NAT

Vous avez besoin d’ouvrir un port sur votre eeegw qui redirige sur une des machines de votre lan ?
Rien de plus simple. Procédez comme suit si vous avez par exemple un serveur web derrière 10.0.69.1 :

# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to 10.0.69.1:80

Ensuite on save la nouvelle régle dans les régles devant se lancer au boot :
# iptables-save > /etc/network/firewall

Votre nouvelle règle de NAT/Firewall est donc automatiquement activée sans avoir à faire quoi que ce soit de plus sur votre eeegw.

Automatiser le lancement des scripts eeegw_script au boot

/etc/network/interfaces
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.0.69.250
netmask 255.255.255.0
network 10.0.69.0
broadcast 10.0.69.255
pre-up iptables-restore -c /etc/network/firewall

auto ath0
iface ath0 inet dhcp
wireless_mode Managed

pre-up /etc/eeegw/wifi.sh
pre-up /etc/eeegw/nerim.sh
pre-up /etc/eeegw/route_static.sh
pre-up /etc/eeegw/ethylix.sh
pre-up /etc/eeegw/QOS/qos.sh

Et si on monitorait /graphait tout ça ?

Exemple de graph que l’on va pouvoir obtenir grace à ce super howto (vu mensuel de ma connexion internet) :


Second Exemple: vue journalière de l’utilisation d’une connexion par un vpn.


Installation

# apt-get install munin apache2 munin-node
# cd /usr/share/munin/plugins/
# ls

Repérez ici les choses qu’il serait intéressant de grapher sur votre munin puis :
# cd /etc/munin/plugins
# ln -s /usr/share/munin/plugins/acpi
# ln -s /usr/share/munin/plugins/apache_processes
# ln -s /usr/share/munin/plugins/cpu
# ln -s /usr/share/munin/plugins/df
# ln -s /usr/share/munin/plugins/swap
[....]

/etc/munin/munin.conf
[localhost.localdomain]
address 127.0.0.1
use_node_name yes

Relancez munin-node
# /etc/init.d/munin-node restart

Ça devrait grapher tout simplement comme ça sous debian (l’installation sous gentoo demande un peu plus de délicatesses). Pour plus de détails : http://eeegw-ip-adresse/munin.

Sortie de ifconfig

ath0 Link encap:Ethernet HWaddr 06:15:af:8d:37:37
inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::415:afff:fe8d:3737/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13848732 errors:0 dropped:0 overruns:0 frame:0
TX packets:4385032 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:1482140328 (1.3 GiB) TX bytes:307281227 (293.0 MiB)

eth0 Link encap:Ethernet HWaddr 00:1f:c6:28:71:9e
inet adr:10.0.69.250 Bcast:10.0.69.255 Masque:255.255.255.0
adr inet6: fe80::21f:c6ff:fe28:719e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:256988818 errors:0 dropped:0 overruns:0 frame:4160
TX packets:258912344 errors:0 dropped:0 overruns:0 carrier:6
collisions:0 lg file transmission:1000
RX bytes:3516383801 (3.2 GiB) TX bytes:0 (0.0 B)
Mémoire:fbfc0000-fc000000

ethylix0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:194.110.69.23 P-t-P:194.110.69.17 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4099 errors:0 dropped:0 overruns:0 frame:0
TX packets:3932 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:286787 (280.0 KiB) TX bytes:399957 (390.5 KiB)

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:4493171 errors:0 dropped:0 overruns:0 frame:0
TX packets:4493171 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:532519851 (507.8 MiB) TX bytes:532519851 (507.8 MiB)

ppp0 Link encap:Protocole Point-à-Point
inet adr:213.41.185.56 P-t-P:62.4.16.251 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:6108340 errors:0 dropped:0 overruns:0 frame:0
TX packets:4219070 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
RX bytes:2251583910 (2.0 GiB) TX bytes:836111670 (797.3 MiB)

tap0 Link encap:Ethernet HWaddr 00:ff:b7:de:c8:b4
inet adr:10.0.1.2 Bcast:10.0.1.255 Masque:255.255.255.0
adr inet6: 2001:758:f00:8:2ff:b7ff:fede:c8b4/64 Scope:Global
adr inet6: fe80::2ff:b7ff:fede:c8b4/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4716451 errors:0 dropped:0 overruns:0 frame:0
TX packets:2796718 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:4275489693 (3.9 GiB) TX bytes:358571500 (341.9 MiB)

tap1 Link encap:Ethernet HWaddr 00:ff:63:b8:57:ea
inet adr:81.93.X.X Bcast:81.93.X.X Masque:255.255.255.128
adr inet6: 2001:758:f00:cafe:2ff:63ff:feb8:57ea/64 Scope:Global
adr inet6: fe80::2ff:63ff:feb8:57ea/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:43229918 errors:0 dropped:0 overruns:0 frame:0
TX packets:26631144 errors:0 dropped:1826 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:3891532561 (3.6 GiB) TX bytes:4009241435 (3.7 GiB)

wifi0 Link encap:UNSPEC HWaddr 00-15-AF-8D-37-37-65-74-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:226972539 errors:0 dropped:0 overruns:0 frame:6623910
TX packets:5796868 errors:44600 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:280
RX bytes:2128136633 (1.9 GiB) TX bytes:515534254 (491.6 MiB)
Interruption:18

Sortie de iproute

194.110.69.17 dev ethylix0 proto kernel scope link src 194.110.69.23
216.165.129.135 via 192.168.0.254 dev ath0
140.211.166.134 via 192.168.0.254 dev ath0
213.186.33.19 via 192.168.0.254 dev ath0
149.20.20.135 via 192.168.0.254 dev ath0
130.239.17.6 via 192.168.0.254 dev ath0
94.23.219.37 via 192.168.0.254 dev ath0
217.23.9.148 via 192.168.0.254 dev ath0
204.152.191.39 via 192.168.0.254 dev ath0
78.41.233.57 via 192.168.0.254 dev ath0
213.251.172.23 via 192.168.0.254 dev ath0
156.56.247.195 via 192.168.0.254 dev ath0
62.4.16.251 dev ppp0 proto kernel scope link src 213.41.185.56
81.93.247.0/25 dev tap1 proto kernel scope link src 81.93.247.10
193.200.171.0/24 via 81.93.247.1 dev tap1
10.0.69.0/24 dev eth0 proto kernel scope link src 10.0.69.250
91.199.232.0/24 via 81.93.247.1 dev tap1
10.0.1.0/24 dev tap0 proto kernel scope link src 10.0.1.2
195.190.3.0/24 via 81.93.247.1 dev tap1
192.168.0.0/24 dev ath0 proto kernel scope link src 192.168.0.12
193.200.226.0/24 via 81.93.247.1 dev tap1
91.198.105.0/24 via 81.93.247.1 dev tap1
91.209.245.0/24 via 81.93.247.1 dev tap1
193.200.181.0/24 via 81.93.247.1 dev tap1
78.41.232.0/21 via 81.93.247.1 dev tap1
91.191.144.0/20 via 81.93.247.1 dev tap1
81.93.240.0/20 via 81.93.247.1 dev tap1
169.254.0.0/16 dev eth0 scope link metric 1000
10.0.0.0/8 via 10.0.1.1 dev tap0
default dev ppp0 scope link

Ma eeegw en production



Les liens interessants

http://upload.wikimedia.org/wikipedia/fr/3/3e/Netfilter_schema.png
http://wiki.gcu.info/doku.php?id=linux:openvpn_multi-listeners_debian
Dual wan Cisco
http://www.dslreports.com/forum/remark,16388383?hilite=ip+sla
Antenne wifi externe sur sa eeegw
http://chris.olstrom.com/blog/howto/setup-dual-wan/
http://tldp.org/HOWTO/Traffic-Control-HOWTO/
http://markmail.org/message/aronyjanpuxenvug
http://lartc.org/howto/lartc.rpdb.multiple-links.html

Si vous avez aimé ce post...

1. EeeGW – ZE retour du détour ! – Proxycache.
2. Eeegw – part III – Quality Of Service aka QOS
3. Firmware modifié pour Linksys WAG200G
]]> http://geekfault.org/2009/12/31/construire-sa-gateway-from-scratch/feed/ 6 http://geekfault.org/2009/09/26/ip-over-dns/ http://geekfault.org/2009/09/26/ip-over-dns/#comments Sat, 26 Sep 2009 14:50:24 +0000 Tito http://geekfault.org/?p=1517 Si vous avez aimé ce post...
1. Le tunnel SSH facile
2. Allocation d’adresses IPv4 publiques over VPN
3. Reverse SSH : accéder à un serveur derrière un NAT/Firewall
]]> Vous êtes dans une gare, un hôtel ou un aéroport. Celui-ci est équipé en hotspots WiFi mais dès que vous vous connectez ils essayent de vous sous-tirer plus de 10€ pour une petite heure de connexion, ce qui est totalement aberrant vu les coûts de déploiement actuels.

Là, vous avez deux solutions : payer (ce qui peut vite devenir cher si vous passer plus d’une semaine à l’hôtel) ou contourner les limitations. Vous vous rendrez vite compte que, même avant d’avoir payé, tous les hotspots résolvent les DNS… et il ne vous aura pas échappé qu’une résolution de DNS est un échange de données!

Attention : Cet article fait appel à des connaissances avancées.

Le port UDP 53

Pour faciliter la configuration de ces hotspots, de nombreux administrateurs n’hésitent pas à tout simplement ouvrir le port DNS, c’est-à-dire le port UDP 53. Une solution simple pour accéder à internet serait donc d’avoir un serveur VPN sur ce port.

Malheureusement on tombe souvent sur des hotspots bien configurés, qui n’autorisent du trafic que vers leur propre serveur DNS. Pourtant, vous avez remarqué qu’un dig geekfault.org vous a retourné la bonne adresse IP (81.93.247.142 actuellement) et non une adresse IP du hotspot. Vous venez de communiquer avec l’internet!

Échange de données over DNS

L’idée est donc simple : traduire vos “requêtes IP” en requêtes DNS. Un faux serveur DNS va comprendre ces requêtes, les exécuter et retourner la “réponse IP” en réponse DNS! Ce détournement du système DNS est réalisable grâce à NSTX, ou Name Service Transfer Procotol qui crée un véritable tunnel IP entre votre laptop et votre serveur, grâce aux requêtes DNS.

Par exemple vous essayez de vous connecter à Geekfault.


• Firefox génère une requête HTTP vers geekfault.org
• Celle-ci est interceptée par le client NSTX tournant sur le laptop. Il génère une requête vers le domaine KJhjh33.dd_2sT-XXT.dAAoi_f.tunnel.example.com
• Le NSTX tournant sur le serveur reçoit cette requête DNS et décode le KJhjh33.dd_2sT-XXT.dAAoi_f en “requête HTTP vers geekfault.org”
• Le serveur se connecte alors à geekfault.org et récupère son contenu
• Le contenu récupéré est encodé de la même manière et transmis vers votre laptop en tant que réponse DNS TXT
• Le NSTX tournant sur le laptop décode les données, reformant les paquets IP
• Firefox reçoit les données HTTP, Geekfault.org s’affiche

Mise en place du serveur

Attention il est important que votre vrai serveur DNS et votre serveur NSTX soient sur deux machines différentes, ou au moins sur deux IP différentes. En effet, il faut qu’un vrai serveur DNS fasse pointer le sous-domaine tunnel.example.com vers NSTX. Pour cela, ajoutez à la fin de votre zone DNS $ORIGIN tunnel.example.com.
@ IN NS ns.tunnel.example.com.
ns IN A 1.2.3.4 où example.com est votre domaine et 1.2.3.4 est l’IP du serveur où vous installerez NSTX.

Vérifiez que votre kernel est compilé avec le “Universal TUN/TAP device driver support” (dans Network device support) . Installez NSTX, disponible en package pour de nombreuses distributions.

Et il ne reste plus qu’à créer le tunnel côté serveur: # modprobe tun #Uniquement si compilé en module
# nstxd -i 1.2.3.4 tunnel.example.com
# ifconfig tun0 up 172.16.42.1 netmask 255.255.255.0
# iptables -t nat -A POSTROUTING -s 172.16.42.2 -o eth0 -j SNAT

Le client sur le laptop

De la même manière, vérifiez que vous avez le support TUN/TAP dans le kernel et installez NSTX.

Récupérez l’adresse IP du serveur DNS fourni par DHCP (dans /etc/resolv.conf) ainsi que l’adresse IP du routeur (dans route). On crée alors l’autre bout du tunnel et on route le trafic approprié dans celui-ci: # modprobe tun #Uniquement si compilé en module
# nstxcd tunnel.example.com
# ifconfig tun0 up 172.16.42.2 netmask 255.255.255.0
# route del default
# route add -host gw dev
# route add default gw 172.16.42.1 tun0

Performances

Vous devriez maintenant être capable de surfer sur le web. Selon le serveur DNS du fournisseur, vous pouvez espérer entre 10 et 60ko/s. Malheureusement les fortes latences de toutes les requêtes empêchent l’utilisation de plusieurs services, dont le SSH. Mais, hé, vous accédez à internet sans vous défaire de 10€

Vous aurez aussi sans doute compris que nous sommes là au bord de la légalité : on exploite en quelque sorte une faille dans le système de hotspot. À utiliser avec précaution et parcimonie.

Si vous avez aimé ce post...

1. Le tunnel SSH facile
2. Allocation d’adresses IPv4 publiques over VPN
3. Reverse SSH : accéder à un serveur derrière un NAT/Firewall
]]> http://geekfault.org/2009/09/26/ip-over-dns/feed/ 21 http://geekfault.org/2009/05/20/firmware-linksys-wag200g/ http://geekfault.org/2009/05/20/firmware-linksys-wag200g/#comments Wed, 20 May 2009 02:18:24 +0000 Tito http://geekfault.org/?p=644 Si vous avez aimé ce post...
1. On a testé pour vous : Ubuntu Jaunty Jackalope 9.04
2. IPv6 pour les nuls^Wgeeks
3. Introduction à l’iPhone
]]> Longtemps j’ai cru que les firmwares modifiés pour routeur étaient réservés au Linksys WRT54G, avec entre autres le fameux OpenWRT. Connexion SSH, modifications iptables et autres fonctionalités plus avancées me semblaient hors de portée sur mon routeur d’entrée de gamme.

Pourtant le Linksys WAG200G est un routeur ADSL2+ très répandu, et si je me limite aux maigres statistiques des 5 rédacteurs de Geekfault, nous sommes 60% à en avoir un! Son firmware est par ailleurs distribué en GPL par Linksys…

Mais au cours de mes divagations sur internet je l’ai trouvé! Présentation.


Woytekm

C’est sur la Google Page de Woytekm que j’ai trouvé mon bonheur.

La dernière version en date est estampillée 0.9 et est basée sur la release 1.01.06 du firmware officiel Linksys. Une version 0.10 basée sur 1.01.09 est prévue avant la fin du mois.

Fonctionalités supplémentaires



• Activation du serveur SSH et telnet
• Assignation d’IP DHCP selon l’adresse mac du client
• DynamicDNS avec No-IP.org
• Watchdog : reboot automatique lorsqu’un ping ne répond plus
• Relais de WakeOnLan depuis internet
• Analyse du traffic et graphes de l’utilisation de la bande passante

L’accès SSH permet évidemment des modifications plus fines, comme par exemple la modification manuelle des iptables !

Installation

L’installation se fait comme toute mise à jour officielle de Linksys. Pas de soudure ni de câble série à modifier donc.

Assurez-vous de travailler depuis une machine branchée en ethernet. Bien que Woytekm permette de faire une simple upgrade sans perte de paramètres, je vous conseille de restaurer votre WAG200G aux paramètres d’usine.

Téléchargez ensuite le fichier IMG (version A) sur la page SourceForce du projet et installez-la comme toute mise à jour.

Et voilà!

Vous avez maintenant un nouvel onglet MySetup dans l’interface de gestion. Vous pouvez aussi vous connecter en root sur SSH, le mot de passe étant le même que celui permettant de se connecter à l’interface de gestion.

Après une remise aux paramètres d’usine, je n’ai remarqué aucun problème avec ce firmware modifié, j’ai même trouvé une plus grande stabilité de mon routeur! Sans doute parce que mon firmware n’était pas à jour, mais bon c’est quand même Woytekm qui m’a fait mettre à jour

Screenshots

     

Liens

• Site du projet
• Une tonne d’informations pas claires
• Téléchargement SourceForge

Si vous avez aimé ce post...

1. On a testé pour vous : Ubuntu Jaunty Jackalope 9.04
2. IPv6 pour les nuls^Wgeeks
3. Introduction à l’iPhone
]]> http://geekfault.org/2009/05/20/firmware-linksys-wag200g/feed/ 1