Envoyé par unreal
Pourquoi ce dossier ?
Il peut être parfois intéressant de sortir par un VPN. Par exemple pour contourner un blocage de site ou pour accéder à du contenu qui n'est pas encore disponible dans le pays où l'on habite. Le soucis c'est qu'utiliser un VPN implique généralement plusieurs choses :
- Installer un logiciel sur son ordinateur
- Envoyer inconditionnellement tout son trafic par le VPN à partir du moment où le client VPN est démarré
- Beaucoup de difficultés si l'on souhaite utiliser le VPN sur un appareil mobile, tel qu'un smartphone
La solution proposée dans ce dossier est de configurer le VPN sur un serveur (et non sur le client) et d'utiliser un proxy HTTP installé sur le même serveur pour communiquer avec le VPN. Le client peut alors sélectivement utiliser le proxy (par le bias d'un fichier .pac par exemple) pour router son trafic Web selon ses besoins.
Le schéma ci-dessous résume la architecture :
Avant de commencer
Je vous propose quelques lectures en rapport avant de se lancer dans le vif du sujet :
- Policy routing avec Packet Filter
- Gérer multiples tables de routage avec setfib
- Article de Wikipedia sur le PAC
- La documentation officielle Packet Filter
Configuration requise
Pour réaliser ce projet, nous allons utiliser les applications et services suivants :
- Le service VPN TunnelBear qui se base sur OpenVPN ; vous pouvez utiliser le service de votre choix.
- FreeBSD 8.2 avec support multiples tables de routage (important !)
- Squid 3.1
Configuration
TunnelBear
Téléchargez et installez l'application proposée car elle vous permettra de créer un compte gratuit avec 500Mo de quota mensuel. Ils ont des abonnements payants si vous avez besoin de plus de 500Mo mensuel. Localisez les fichiers suivants et copiez-les sur le serveur dans /usr/local/etc/openvpn :
- tbearProd.ovpn
- ca.crt
- key.crt
- key.key
Démarrez la connexion VPN avec le client officiel sur le serveur souhaité et utilisez la commande netstat pour déterminer l'IP du serveur et son port (443 normalement).
Installez ensuite /usr/ports/security/openvpn en choisissant "PW_SAVE Interactive passwords may be read from a file". Créez un fichier /usr/local/etc/openvpn/password lisible uniquement par root avec votre login et mot de passe sur deux lignes.
Nous allons maintenant créer une configuration tunnelbear.conf à partir de tbearProd.ovpn. Le mien ressemble à ceci :
Configurez /etc/rc.conf pour activer OpenVPN :
Enfin, démarrez la connexion VPN, et vérifiez avec ifconfig que vous parvenez à vous connecter :
Si le VPN démarre correctement, nous pouvons passer à la configuration du proxy Squid.
Squid
Installez /usr/ports/www/squid31 en prenant soin de désélectionner toutes les options pour alléger l'installation. Côté configuration, si vous ne voulez pas qu'on sache que vous surfez par un proxy, je vous conseille d'ajouter les directives suivantes dans votre configuration :
Nous n'allons pas démarrer Squid de la façon habituelle (en l'activant dans rc.conf) car nous avons besoin qu'il démarre en utilisant une table de routage alternative. Pour ce faire, nous allons utiliser un script rc spécifique qui aura comme rôle de configurer les routes et démarrer Squid :
/usr/local/etc/rc.d/setfibroutes
Redémarrez le serveur (si possible) pour vérifier que tous les services (OpenVPN et Squid) démarrent correctement.
Utilisation reply-to avec PF
Si vous tentez d'utiliser le Squid à ce stade, vous allez constater qu'il ne fonctionne pas ; en effet il reçoit bien les requêtes sur l'interface publique re0 du serveur, mais il répond vers tun0, ce qui ne peut pas fonctionner. Pour éviter ce soucis, nous allons utiliser une règle très utile de PF :
/etc/pf.conf
# Interface definitions
ethif0 = "re0"
ethgw0 = "1.2.3.4"
table <allowedproxy> { 1.1.2.3, \
2.3.4.5, \
3.4.5.6 }
# Proxy must reply to re0 interface
pass in quick on $ethif0 reply-to ($ethif0 $ethgw0) inet proto tcp from <allowedproxy> to any port 22222 keep state
block drop in quick on $ethif0 inet proto tcp from any to any port 22222
Note : 22222 est le port d'écoute du proxy Squid.
Relancez PF et normalement tout fonctionne maintenant. Squid répond bien sur l'interface publique pour discuter avec le client, et utilise l'interface tun0 pour sortir.
Conclusion
J'espère que vous avez aimé ce petit dossier et n'hésitez pas à faire des remarques si vous en avez, bien sûr.
Il peut être parfois intéressant de sortir par un VPN. Par exemple pour contourner un blocage de site ou pour accéder à du contenu qui n'est pas encore disponible dans le pays où l'on habite. Le soucis c'est qu'utiliser un VPN implique généralement plusieurs choses :
- Installer un logiciel sur son ordinateur
- Envoyer inconditionnellement tout son trafic par le VPN à partir du moment où le client VPN est démarré
- Beaucoup de difficultés si l'on souhaite utiliser le VPN sur un appareil mobile, tel qu'un smartphone
La solution proposée dans ce dossier est de configurer le VPN sur un serveur (et non sur le client) et d'utiliser un proxy HTTP installé sur le même serveur pour communiquer avec le VPN. Le client peut alors sélectivement utiliser le proxy (par le bias d'un fichier .pac par exemple) pour router son trafic Web selon ses besoins.
Le schéma ci-dessous résume la architecture :
Avant de commencer
Je vous propose quelques lectures en rapport avant de se lancer dans le vif du sujet :
- Policy routing avec Packet Filter
- Gérer multiples tables de routage avec setfib
- Article de Wikipedia sur le PAC
- La documentation officielle Packet Filter
Configuration requise
Pour réaliser ce projet, nous allons utiliser les applications et services suivants :
- Le service VPN TunnelBear qui se base sur OpenVPN ; vous pouvez utiliser le service de votre choix.
- FreeBSD 8.2 avec support multiples tables de routage (important !)
- Squid 3.1
Configuration
TunnelBear
Téléchargez et installez l'application proposée car elle vous permettra de créer un compte gratuit avec 500Mo de quota mensuel. Ils ont des abonnements payants si vous avez besoin de plus de 500Mo mensuel. Localisez les fichiers suivants et copiez-les sur le serveur dans /usr/local/etc/openvpn :
- tbearProd.ovpn
- ca.crt
- key.crt
- key.key
Démarrez la connexion VPN avec le client officiel sur le serveur souhaité et utilisez la commande netstat pour déterminer l'IP du serveur et son port (443 normalement).
Installez ensuite /usr/ports/security/openvpn en choisissant "PW_SAVE Interactive passwords may be read from a file". Créez un fichier /usr/local/etc/openvpn/password lisible uniquement par root avec votre login et mot de passe sur deux lignes.
Nous allons maintenant créer une configuration tunnelbear.conf à partir de tbearProd.ovpn. Le mien ressemble à ceci :
client
dev tun0
proto tcp
remote <ip serveur> <port serveur>
persist-key
persist-tun
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/key.crt
key /usr/local/etc/openvpn/key.key
ns-cert-type server
resolv-retry infinite
nobind
comp-lzo
verb 3
status /var/log/openvpn-status.log
log /var/log/openvpn.log
auth-user-pass /usr/local/etc/openvpn/password
ping 10
route-nopull
dev tun0
proto tcp
remote <ip serveur> <port serveur>
persist-key
persist-tun
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/key.crt
key /usr/local/etc/openvpn/key.key
ns-cert-type server
resolv-retry infinite
nobind
comp-lzo
verb 3
status /var/log/openvpn-status.log
log /var/log/openvpn.log
auth-user-pass /usr/local/etc/openvpn/password
ping 10
route-nopull
Configurez /etc/rc.conf pour activer OpenVPN :
# OpenVPN client
openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/tunnelbear.conf"
openvpn_dir="/usr/local/etc/openvpn"
openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/tunnelbear.conf"
openvpn_dir="/usr/local/etc/openvpn"
Enfin, démarrez la connexion VPN, et vérifiez avec ifconfig que vous parvenez à vous connecter :
# /usr/local/etc/rc.d/openvpn start
...
ifconfig tun0
...
ifconfig tun0
Si le VPN démarre correctement, nous pouvons passer à la configuration du proxy Squid.
Squid
Installez /usr/ports/www/squid31 en prenant soin de désélectionner toutes les options pour alléger l'installation. Côté configuration, si vous ne voulez pas qu'on sache que vous surfez par un proxy, je vous conseille d'ajouter les directives suivantes dans votre configuration :
via off
forwarded_for delete
forwarded_for delete
Nous n'allons pas démarrer Squid de la façon habituelle (en l'activant dans rc.conf) car nous avons besoin qu'il démarre en utilisant une table de routage alternative. Pour ce faire, nous allons utiliser un script rc spécifique qui aura comme rôle de configurer les routes et démarrer Squid :
/usr/local/etc/rc.d/setfibroutes
#!/bin/sh
#
#
# PROVIDE: setfibroutes
# REQUIRE: LOGIN openvpn
#
. /etc/rc.subr
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"
echo -n "Waiting for network"
COUNT=0
while [ ! "$GWROUTE" ] && [ $COUNT -lt 50 ]; do
sleep 1
echo -n "."
GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"
COUNT=`expr $COUNT + 1`
done
[ ! $GWROUTE ] && echo " Failed." && exit 1
echo " OK."
echo "Setting setfib routes..."
/usr/sbin/setfib 1 route delete -net 0.0.0.0
/usr/sbin/setfib 1 route add -net 0.0.0.0 $GWROUTE
echo "Starting Squid..."
/usr/sbin/setfib 1 /usr/local/etc/rc.d/squid onestart
#
#
# PROVIDE: setfibroutes
# REQUIRE: LOGIN openvpn
#
. /etc/rc.subr
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"
echo -n "Waiting for network"
COUNT=0
while [ ! "$GWROUTE" ] && [ $COUNT -lt 50 ]; do
sleep 1
echo -n "."
GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"
COUNT=`expr $COUNT + 1`
done
[ ! $GWROUTE ] && echo " Failed." && exit 1
echo " OK."
echo "Setting setfib routes..."
/usr/sbin/setfib 1 route delete -net 0.0.0.0
/usr/sbin/setfib 1 route add -net 0.0.0.0 $GWROUTE
echo "Starting Squid..."
/usr/sbin/setfib 1 /usr/local/etc/rc.d/squid onestart
Redémarrez le serveur (si possible) pour vérifier que tous les services (OpenVPN et Squid) démarrent correctement.
Utilisation reply-to avec PF
Si vous tentez d'utiliser le Squid à ce stade, vous allez constater qu'il ne fonctionne pas ; en effet il reçoit bien les requêtes sur l'interface publique re0 du serveur, mais il répond vers tun0, ce qui ne peut pas fonctionner. Pour éviter ce soucis, nous allons utiliser une règle très utile de PF :
/etc/pf.conf
# Interface definitions
ethif0 = "re0"
ethgw0 = "1.2.3.4"
table <allowedproxy> { 1.1.2.3, \
2.3.4.5, \
3.4.5.6 }
# Proxy must reply to re0 interface
pass in quick on $ethif0 reply-to ($ethif0 $ethgw0) inet proto tcp from <allowedproxy> to any port 22222 keep state
block drop in quick on $ethif0 inet proto tcp from any to any port 22222
Note : 22222 est le port d'écoute du proxy Squid.
Relancez PF et normalement tout fonctionne maintenant. Squid répond bien sur l'interface publique pour discuter avec le client, et utilise l'interface tun0 pour sortir.
Conclusion
J'espère que vous avez aimé ce petit dossier et n'hésitez pas à faire des remarques si vous en avez, bien sûr.
Posté le 19/11/11 à 15:20 - 0 Commentaires...