Aller au contenu

[Résolu] Réseau : routage de port et VPN


PiFou86

Messages recommandés

bonjour,

je suis sur un réseau (connection extérieure via NAT), et je me connecte en VPN (openvpn) sur un autre réseau. Jusuque là pas de problèmes.

J'ai redirigé tout mon trafic réseau (sauf celui du réseau local) vers le VPN (route add -net 0.0.0.0 iprouteur).

=> le problème c'est que du coup c'est lent.

=> ce que je voudrais c'est rediriger toutes les connections de certains ports sur le réseau local et toutes les autres sur le VPN

(ie : j'ai deux gateway A et B, B par VPN et je voudrais faire passer par exemple le traffic web par A et le trafic mail par B => répartir en quelque sorte les charges)

quelqu'un à une piste (pour rediriger certain port vers le réseau local) ?

(OSX 10.4, 10.5 dans 2 jours :transpi:

Lien vers le commentaire
Partager sur d’autres sites

=> le problème c'est que du coup c'est lent.

Hello,

quelques questions qui me viennent à l'esprit par rapport à la lenteur :

Tu es en tcp ou udp?

Tu as activé la compression lzo?

Tu as mis un chiffrement très fort?

N'oublie pas que la vitesse de ton VPN dépend du débit montant, et pas du débit descendant.

Ton idée de routage vient-elle du constat de lenteur?

Le client et le serveur sont tous deux sous OS X? Dans mon cas mon serveur VPN tourne sous NetBSD mais mon client est sous Tiger.

Lien vers le commentaire
Partager sur d’autres sites

Tu es en tcp ou udp?

tcp -> udp serait certe moins lourd.

Tu as activé la compression lzo?

oui.

Tu as mis un chiffrement très fort?

N'oublie pas que la vitesse de ton VPN dépend du débit montant, et pas du débit descendant.

j'ai fait une clef static (2048 bit OpenVPN static key). généré par openvpn Le problème vient surtout de la connection entre le mac et le serveur vpn car le débit montant du serveur vpn n'est pas terrible (connection adsl simple).

Ton idée de routage vient-elle du constat de lenteur?

oui car faire passer une partie du traffic par le serveur A et ne prendre que ce que j'ai besoin sur B (VPN) éviterai du traffic inutile.

Le client et le serveur sont tous deux sous OS X? Dans mon cas mon serveur VPN tourne sous NetBSD mais mon client est sous Tiger.

non seulement le client. Le serveur est un routeur wrt54gs sous dd-wrt. client et serveur utilisent openvpn.

Lien vers le commentaire
Partager sur d’autres sites

Tu es en tcp ou udp?

tcp -> udp serait certe moins lourd.

Je confirme. UDP est bien moins lourd. Par contre tu auras moins de contrôles de flux.

Tu as activé la compression lzo?

oui.

Bien :zarb:

Tu as mis un chiffrement très fort?

N'oublie pas que la vitesse de ton VPN dépend du débit montant, et pas du débit descendant.

j'ai fait une clef static (2048 bit OpenVPN static key). généré par openvpn Le problème vient surtout de la connection entre le mac et le serveur vpn car le débit montant du serveur vpn n'est pas terrible (connection adsl simple).

Selon le degré d'importance, une clé 2048 n'est peut-être pas nécessaire... je ne sais pas à quoi tu veux accéder mais sans doute que 1024 peut suffire.

Ton idée de routage vient-elle du constat de lenteur?

oui car faire passer une partie du traffic par le serveur A et ne prendre que ce que j'ai besoin sur B (VPN) éviterai du traffic inutile.

Dans ce cas pourquoi ne retires-tu pas la route par défaut qui te fait tout passer par le VPN? Active juste la route qui te donne accès à ton LAN, et ton surf passera par la connexion extérieure.

Le client et le serveur sont tous deux sous OS X? Dans mon cas mon serveur VPN tourne sous NetBSD mais mon client est sous Tiger.

non seulement le client. Le serveur est un routeur wrt54gs sous dd-wrt. client et serveur utilisent openvpn.

Ah. J'aimerais bien que tu lances un top sur ton wrt quand t'es connecté... et aussi un free -m de temps en temps... je suis curieux de voir si le CPU de cette petite bête est à fond.

Lien vers le commentaire
Partager sur d’autres sites

Je confirme. UDP est bien moins lourd. Par contre tu auras moins de contrôles de flux.

Le but au départ c'était de limiter les erreurs potentielles.

Dans ce cas pourquoi ne retires-tu pas la route par défaut qui te fait tout passer par le VPN? Active juste la route qui te donne accès à ton LAN, et ton surf passera par la connexion extérieure.

Simplement parceque j'ai besoin de passer par mon LAN pour certains service réseau (comme IMAP, SMTP et autre). et que le gateway par défaut les filtres.

C'est pour cela que j'aimerai faire passer certains ports par mon VPN et d'autre sur le réseau local. (ou l'inverse)

Je pourrais le faire par adresse de destination mais ce n'est pas vraiment très efficace...

Ah. J'aimerais bien que tu lances un top sur ton wrt quand t'es connecté... et aussi un free -m de temps en temps... je suis curieux de voir si le CPU de cette petite bête est à fond.

Avec un client : openvpn prend dans les 5 à 10% du cpu pour naviguer sur le web. => étonnant au premier abord....

~ # uptime
13:46:59 up 7 days, 15:59, load average: 0.27, 0.22, 0.17

=> raisonnable

Lien vers le commentaire
Partager sur d’autres sites

désolé j'ai été pris entre un article à pondre, des cours à donner et l'install de léopard... :p

heu donc pour l'instant je n'ai pas essayé de passer le protocole en udp, ni de baisser la clef de cryptage. Ce que je désire avant tout, c'est savoir s'il est possible de faire passer tout le traffic d'un port par un réseau et tout le reste vers un autre réseau, un peu comme on fait avec les tables de routages.....

Lien vers le commentaire
Partager sur d’autres sites

Hello,

de mon expérience en matière de routage, je ne crois pas qu'il soit prévu de faire du routage avec le port en tant que critère, du moins pas avec les outils dont nous disposons dans le cas présent. J'aurais tendance à te proposer une solution similaire à celle que tu pensais : avoir une passerelle pour certains hôtes, et une autre passerelle pour d'autres.

Je vois la configuration comme ça :

- ton VPN ne modifie pas la route par défaut (=> donc, tu ne fais pas passer tout ton traffic par le VPN);

- tu crées un script shell dans lequel tu dis que pour tes serveurs POP et IMAP, la passerelle n'est plus la passerelle du réseau où tu es, mais ton concentrateur VPN (appelons ce script up.sh et plaçons le dans /tondossierutilisateur/bin/);

- tu crées un autre script shell qui retire ces routes (appelons ce script down.sh et plaçons le au même endroit que up.sh).

- tu ajoutes le lancement de ces scripts dans ta config client VPN, de cette manière :

# up & down scripts
up ~/bin/up.sh
down ~/bin/down.sh

J'espère que ça aide.

Lien vers le commentaire
Partager sur d’autres sites

Oula, tu as quelquechose derrière la tête toi pour avoir une idée aussi tordue (et j'aimerais bien savoir laquelle et je ne suis pas le seul ^^)

Tout d'abord, saches que Openvpn fait du transport IP, que le TCP/l'UDP, il s'en sert pour son tunnel, ailleurs, c'est un couple de gros mots.

Tu peux créer une route IP si tu veux pour des cibles différents, mais pas pour des ports car cette notion n'existe même pas en IP.

Ce que tu veux faire, c'est du port forwarding version alcooliques anonymes. Et c'est impossible si tu n'as pas les compétences techniques de programmation, ou beaucoup de sousous pour du matériel Cisco :iloveyou: .

A la rigueur, tu peux "privilégier" des IPs particulières, avec ta table de routage, mais je doute que tu puisses faire plus.

Lien vers le commentaire
Partager sur d’autres sites

de mon expérience en matière de routage, je ne crois pas qu'il soit prévu de faire du routage avec le port en tant que critère, du moins pas avec les outils dont nous disposons dans le cas présent. J'aurais tendance à te proposer une solution similaire à celle que tu pensais : avoir une passerelle pour certains hôtes, et une autre passerelle pour d'autres.

J'ai essayé de tripatouiller le firewall avec ipfw (car c'est pas du routage ip en fin de compte mais de la "redirection" en quelque sorte) mais j'avoue que j'ai lu la doc en diagonale et qu'il me manque du vocabulaire en réseau... au final ca ne marché pas... :p J'ai cherché de la doc sur qos et ipfw mais ca n'a pas donné grand chose.

Je vois la configuration comme ça :

- ton VPN ne modifie pas la route par défaut (=> donc, tu ne fais pas passer tout ton traffic par le VPN);

- tu crées un script shell dans lequel tu dis que pour tes serveurs POP et IMAP, la passerelle n'est plus la passerelle du réseau où tu es, mais ton concentrateur VPN (appelons ce script up.sh et plaçons le dans /tondossierutilisateur/bin/);

- tu crées un autre script shell qui retire ces routes (appelons ce script down.sh et plaçons le au même endroit que up.sh).

- tu ajoutes le lancement de ces scripts dans ta config client VPN, de cette manière :

# up & down scripts
up ~/bin/up.sh
down ~/bin/down.sh

J'espère que ça aide.

Vi ca c'est une solution qui marche plutot bien ;)

Oula, tu as quelquechose derrière la tête toi pour avoir une idée aussi tordue (et j'aimerais bien savoir laquelle et je ne suis pas le seul ^^)

Heu non rien de spécial. Surtout lire mes mails par imap au lieu des webmails habituels et envoyer des mails. Mes supérieurs ne sont pas contre.

Tout d'abord, saches que Openvpn fait du transport IP, que le TCP/l'UDP, il s'en sert pour son tunnel, ailleurs, c'est un couple de gros mots.

Tu peux créer une route IP si tu veux pour des cibles différents, mais pas pour des ports car cette notion n'existe même pas en IP.

bof des trucs doivent surement exister, je ne peux pas croire que je sois le seul à me poser la question.

Ce que tu veux faire, c'est du port forwarding version alcooliques anonymes. Et c'est impossible si tu n'as pas les compétences techniques de programmation, ou beaucoup de sousous pour du matériel Cisco :chinois:.

J'aime le bordeau mais je ne vois pas le rapport... ;)

A la rigueur, tu peux "privilégier" des IPs particulières, avec ta table de routage, mais je doute que tu puisses faire plus.

Vi c'est ce que propose TheNastyBoy.

Donc merci à tous pour vos solutions ;)

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...