Archives par étiquette : VPN

3G, régions surpeuplées et filtrage discrétos => VPN

Le blocage

Salut,
Imaginez un opérateur (dernièrement de téléphonie mobile) toujours balaise côté technique, qui apporte de sacrés trucs, qui fait plier commercialement les autres, qui est un opérateur vraiment impressionnant chaque fois qu’il lance un truc, mais avec qui parfois c’est la lutte et là ça peut vraiment te gonfler à l’usage.

Alors avant te barrer chez un autre opérateur sans engagement qui a de meilleures infrastructures en place, tu cherches à sortir la tête du troupeau et faire en sorte que le service marche comme il devrait.
Et le tout sans rooter mon téléphone flambant neuf que je n’ai pas encore envie de massacrer en changeant la ROM. Pour les iphoneux, euh… ça doit aussi exister un client openvpn
free

L’idée

Bref, aujourd’hui, comment faire passer tout son trafic 3G dans un VPN (openvpn) Continuer la lecture

OpenVPN les doigts dans le nez

Mmmmm, j’angoissais à l’idée d’installer à nouveau un serveur OpenVPN en urgence (psychose de la grippe A-H1N1-truc oblige, ‘faut que le pékin lambda puisse bosser à distance…). En effet, la génération des certificats, ce genre de trucs, ça m’énerve, je ne me souviens jamais des lignes de commandes.
Renseignements pris, ça tombe bien, les choses ont dû évolué depuis… euh… la dernière fois. Et le projet OpenVPN fournit un bel outil « easy-rsa » pour générer facilement les clefs serveurs, client, les inscrire dans la base de clefs autorisées, les révoquer etc.
Ca rend OpenVPN installable et exploitable facilement en 10 minutes + le temps de faire un peu de firewalling propre à votre configuration (et de prendre un café).

Toujours à mon habitude, j’essaye d’utiliser ce qu’a fait Debian pour moi. Point de compilation, de création de machin-bidule à la main lorsque ce n’est pas une absolue nécessité.

Pour le contexte, on va dire que le VPN va être installé sur une machine de type passerelle Internet-LAN. Pourquoi pas une Debian avec shorewall et 2 pattes : loc, net (et $FW of course). Je parlerai rapidement des modifications de firewall à la fin. Vous pouvez trouver une introduction à shorewall sur ma doc d’initiation à Debian. Continuer la lecture

Bloquer Hamachi au niveau shorewall et squid

Sympa Hamachi, j’en parlais dans un précédent billet pour l’aspect « je joue en réseau avec mes potes ».

=> Aujourd’hui, j’en parle pour bloquer cette saloperie 😉 d’outil qui peut apporter de gros ennuis au boulot 🙂

Pour rappel, c’est un VPN « zero-conf » qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.

Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye – donc je dois avoir fait le tour de la question), tant au niveau shorewall – si l’accès Internet est direct – qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.

Analyse à 2 balles du comportement de hamachi pour mieux le bloquer

Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
– essayer tout un tas de ports standards
– avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins

MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier – puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.

Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :

1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -

De là, avec quelques commandes hosts, genre :

for i in `seq -f '%02g' 1 40`
do
host ssl-$i.hamachi.cc
done

Ainsi que :

for i in `seq 1 255`
do
host 74.201.74.$i
done

Ce qui donne :

...
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
...

Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.

Blocage niveau shorewall

En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option « blacklist » dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans « blacklist », ajoutez la ligne :

74.201.74.0/24

Ou, dans « rules », ajoutez :

DROP    lan     net:74.201.74.0/24      all

Relancez shorewall via /etc/init.d/shorewall reload

Blocage niveau Squid

Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des « ACL », ajoutez celles-ci – c’est un exemple à adapter.

acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi

Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload

Validez que ça ne marche plus

Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :

1221666080.309      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816      5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html

En images, ça reste sur ça :
Hamachi bloqué

OpenVPN, OpenVPN GUI, droits admin et « add route »…

Si vous avez besoin de donner un accès OpenVPN sur des PC Windows à des personnes n’étant pas admin de leur poste (ce qui est largement raisonnable), il y a 2/3 pièges. Je vous fais part de mes recherches sur le sujet. Au final, c’est possible. Ouf !
Les pièges sont :
– pouvoir accéder à l’interface virtuelle en tant que non-admin
– pouvoir ajouter des routes en tant que non-admin
– pouvoir utiliser proprement le OpenVPN GUI en tant que non-admin.

Accéder à l’interface réseau virtuelle

OpenVPN 2.0 ne permet pas d’exploiter la carte virtuelle si vous n’êtes pas admin, d’après ce que j’en comprends vu la remarque sur la version 2.1 sur le site :

TAP-Win32 adapter can now be opened from non-administrator mode

En fait sur ce sujet, avec OpenVPN 2.0, je ne sais plus si j’avais simplement un problème pour accéder à l’interface virtuelle ou pour créer des « routes » ou les 2. J’ai opté pour la 2.1 RC7 (et tant pis si ce n’est pas la finale).

Pour résoudre à coup sûr ce problème, utilisez la version 2.1.

Ajouter des « routes »

Une fois que l’utilisateur sans droit est capable de lancer l’openvpn, vous vous chopez des erreurs sur vos routes ajoutées dans la conf de votre VPN histoire que tout ce petit monde communique avec le reste de votre infra. En effet, sous Windows, le « add route » est réservé à l’admin… ou plus simplement aux personnes du groupe « Opérateurs de configuration réseau ».
Donc ajoutez vos utilisateurs sans droits là-dedans. Ils ne seront pas admin complet mais pourront déjà abîmer leur configuration réseau…

Impossible d’écrire des logs par le GUI

Si vous avez cette erreur, pensez à donner les droits d’écriture sur tout le répertoire C:\Program Files\OpenVPN\log, pour tout le monde, ou, moins bourrin, pour votre utilisateur.
Notez : le GUI OpenVPN est intégré à OpenVPN 2.1 maintenant. Ce n’est pas le cas avec le package 2.0

Cette fois, c’est bon, votre utilisateur presque-sans-droit peut faire du VPN et massacrer involontairement votre LAN depuis chez lui… :/

Hamachi : client VPN zero-conf pour faire plein de belles (vilaines ?) choses

Hamachi est un client VPN zero-conf. En gros, vous êtes censé installer le bazar et point, votre VPN est monté, vos amis vous trouvent par magie, l’être cher revient, l’argent coule à flot et vous retrouvez la sérénité intérieure.
Dans la pratique, y’a tout de même un peu plus à faire et tout cela mérite quelques explications.

Au fait à quoi ça sert ? En gros un VPN à la maison, ça sert en général à des groupes d’amis un peu geeks voulant vraiment avoir leur VPN flottant au-dessus d’Internet pour s’échanger des fichiers facilement, avoir leurs réseaux fermés de je ne sais quoi.

Si maintenant on imagine que ce réseau fermé est – exemple tout à fait au hasard 😉 – un serveur de jeu que vous voulez rendre accessible comme si vous étiez en LAN, alors que vous êtes sur Internet, certains trouveront cet outil complètement génialissime. Va savoir pourquoi… 😉
Enfin, si j’ai choisi Hamachi, c’est parce-que VOUS êtes quelqu’un aimant un peu l’informatique (sinon vous ne liriez pas cet article) et que vos amis joueurs sont des buses en informatique (cas classique). Ainsi, si vous leur demander d’installer un client VPN hyper compliqué, vous n’êtes pas près de jouer…

En relisant, je vois que l’article est long. Comme quoi, « zero-conf » < => beaucoup d’explications. Allez, visite guidée. Continuer la lecture