Au feu, tournez à gauche

Tags: , , , ,
2 Comments »

Pour des raisons évidentes, j’ai décidé de rendre un peu moins aisée (i.e. pas immédiate) la découverte de mon IP. Plus précisemment, pour certains protocoles et pour certaines machines, je veux que l’IP vue par mon/mes peers ne soit pas directement l’IP que mon fournisseur d’accès m’affecte.

J’ajoute, mais cela n’a evidemment aucun rapport avec cet article, que certains pays intellectuellement plus développés ont recemment confirmé que le partage de fichiers sur le réseau n’était pas illégal sur leur sol.

Le postulat est donc le suivant: seules certaines machines de mon réseau privé devront “sortir” sur une passerelle differente, et uniquement pour certains ports et protocoles.

Pour réaliser cette petite tambouille, j’ai à ma disposition :

  • Un serveur dédié ou virtuel hébergé “ailleurs”, possédant une interface sur une DMZ
  • Le serveur en question fonctionne sous GNU/Linux, on gère donc le NAT et le firewalling grâce à iptables
  • Une passerelle qui me relie à l’Internet par le biais de mon fournisseur d’accès
  • Cette passerelle fonctionne sous NetBSD 5.0.2, on gère le NAT et le firewalling grâce à pf (notez qu’ipf ne permettrait pas, à ma connaissance, d’utiliser les fonctions qui nous seront nécessaires)

La première étape consiste à établir un lien VPN entre la passerelle et le serveur dédié. J’ai utilisé OpenVPN, solution de choix de par sa simplicité, sa souplesse et sa grande stabilité. Étant donné qu’il existe un nombre incalculable de documentations sur cet outil, je colle ici mes configurations client et serveur sans plus de détails :

Sur le serveur :

tls-server

port 4444
dev tun
proto udp
local mon.serveur.dedie

cd /home/imil/etc/openvpn
ca keys/ca.crt
cert keys/dedie.crt
key keys/dedie.key
dh keys/dh1024.pem

client-config-dir ccd

server 10.20.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client
route 192.168.1.0 255.255.255.0

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

status openvpn-status.log

verb 3

Sur le client :

tls-client

proto udp
dev tun0

remote mon.serveur.dedie 4444

nobind

cd /usr/pkg/etc/openvpn/dedie-keys
ca ca.crt
cert monhost.crt
key monhost.key

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

pull

verb 3
log /var/log/openvpn.log

Une fois OpenVPN démarré sur chaque point, une interface tun0 monte, avec coté serveur une IP du type 10.20.0.1 et côté client, 10.20.0.6.
Notez que, coté serveur dédié, on verra arriver une machine depuis la passerelle avec son IP réelle sur le réseau domestique, soit ici 192.168.1.0/24. Ainsi, c’est ce sous-réseau que nous devons NATer sur le dédié GNU/Linux.

Une particularité de mon montage est que je ne souhaite pas utiliser l’IP publique principale de mon serveur public car celle-ci possède un reverse sur mon domaine et est facilement identifiable. Par chance, mon hébergeur me donne la possibilité d’ajouter des alias IP routés sur l’interface publique. En l’occurence, c’est précisemment sur cet alias que j’effectue un source NAT plutot que du MASQUERADING :

### règles INPUT
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # j'autorise en entrée les connexions établies et connexes
# iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # j'autorise l'echo-request
# iptables -A INPUT -p udp -m udp --dport 4444 -j ACCEPT # j'autorise la connexion vers OpenVPN
# iptables -A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable # et je rejette tout le reste sur l'interface eth0
### règles de NAT
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source mon.alias.ip.public

Désormais, si sur ma passerelle je plaçais une route par defaut sur 10.20.0.1 (le boût du tunnel sur le serveur dédié), les machines de mon réseau 192.168.1.0/24 apparaîtraient avec l’IP mon.alias.ip.public.
Cependant, seulement certaines machines, et surtout certains protocoles devront être soumis à cette politique, et c’est grâce à pf, et en particulier la directive route-to, que nous allons mettre en place ce routage conditionnel. Voici les lignes corresponsantes du fichier pf.conf de notre passerelle NetBSD :

int_if="xennet0"

[...]

pass in on $int_if route-to (tun0 10.20.0.1) proto tcp from 192.168.1.10 \
        to any port 80
pass in on $int_if route-to (tun0 10.20.0.1) proto udp from 192.168.1.10 \
        to any port > 10000

Décodage: Concernant le traffic qui arrive sur l’interface interne $int_if, toute demande en provenance de l’IP 192.168.1.10 à destination du protocole HTTP devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.
toute demande en provenance de l’IP 192.168.1.10 à destination de ports UDP supérieurs à 10000 devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.

J’utilise ce routage depuis hier soir, l’overhead du lien VPN est minimal et l’ensemble se comporte correctement. Je ne prétend pas, avec ce système, bénéficier d’un anonymat hors du commun, mais il me permet au moins de ne pas exposer mon IP publique.

OpenVPN, DD-WRT et Fonera

Tags: , ,
2 Comments »

J’ai refait mon LAN. Dans les grandes lignes, une Fonera flashée en DD-WRT bridge la connexion au net via une freebox. Le wrt est le routeur du LAN, il est connecté à un bete switch sur lequel est branché une Fonera “legacy”, qui me fournit l’acces WiFi de manière classique via son SSID “MyPlace”.

Jusque là, rien de particulier.
Mais dans ce petit réseau, j’ai également des téléphones SIP dont un white, WiFi donc. Et comme vous le savez probablement, SIP et plus particulièrement RTP ne font pas bon ménage avec du NAT. Pour pallier ce problème, j’ai l’habitude d’utiliser des liens privés vers mes Asterisk en utilisant OpenVPN. J’ai testé par mal de packages avant de trouver une combinaison fonctionnelle sur Fonera/DD-WRT. En effet, les packages openvpn, libopenssl et liblzo disponibles ici: http://ipkg.k1k2.de/packages/ coredumpent simplement. Voici les emplacements de packages qui marchent:

http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/libopenssl_0.9.8e-1_mips.ipk
http://ipkg.hotsplots.de/kamikaze/7.06/atheros-2.6/packages/liblzo_2.02-1_mips.ipk
http://ipkg.hotsplots.de/kamikaze/7.06/atheros-2.6/packages/openvpn_2.0.9-1_mips.ipk

J’ai également trouvé de très bons tips à cette adresse:

http://www.dd-wrt.com/wiki/index.php/OpenVPN

notemment quelques informations relatives au règles iptables à placer sur le DD-WRT après que le tunnel soit établi pour assurer un routage sans encombres.

et ça jle rentre lààà…

Tags: , , ,
2 Comments »

Après avoir testé moult repositories, des plus farfelus au plus serieux, puis en ayant flingué le firmware avec un package foireux, me poussant donc à re-flasher puis re-”ouvrir” ma Fonera, j’en suis venu à reduire le spectre des repositories de packages à deux :

. http://www.gcd.org/fonera/ (cité dans le post précedent)
. http://downloads.openwrt.org/people/mbm/mips/packages/, une impressionnante collection de packages initialement prévus pour de l’OpenWRT classique mais qui passent parfaitement sur La Fonera.

Et du coup :

root@OpenWrt:~# uname -a
Linux OpenWrt 2.4.32 #9 jue nov 23 12:11:45 UTC 2006 mips unknown
root@OpenWrt:~# openvpn --version
OpenVPN 2.0.7 mips-linux [SSL] [LZO] [EPOLL] built on Apr 27 2006
Developed by James Yonan
Copyright (C) 2002-2005 OpenVPN Solutions LLC 

huhuhu :)

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in