Archives par étiquette : masquerading

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

Falling back to PORT instead of PASV mode

Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel – je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.

Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 🙂

La configuration

J’ai un serveur avec :

  • un FTP – restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
  • un shorewall ouvrant les ports 20 et 21
  • Bref que du bonheur en apparence.

    Le problème

    Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
    Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :

    Falling back to PORT instead of PASV mode

    En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode « PORT » justement. Soit environ 19,8 secondes de trop.

    Comment on le règle ?

    On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
    ./kernel/net/netfilter/nf_conntrack_ftp.ko
    ./kernel/net/ipv4/netfilter/nf_nat_ftp.ko

    Point besoin de rebooter, rien.
    Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.

    Excusez-moi pour l »à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.