Petite question du soir. Je suis en train d'essayer de configurer un
client SIP derrière un routeur NetBSD. La configuration est la
suivante :
Terminal SIP
192.168.11.250/32
|
| LAN 192.168.10.0/24
| |
Blade 2000 (NetBSD/Sparc64)
| |
| Internet public (route par défaut)
|
|
VPN (192.168.1.0/24) niveau 2
|
| LAN 192.168.0.0/24 2001:x:y:z::0/64
| |
Serveur Linux
| |
| Internet backup (route par défaut IPv6)
|
Internet (route par défaut IPv4)
|
|
|
serveur SIP (IPv4)
J'ai routé naïvement le protocole SIP (5060/TCP) et j'arrive à me
connecter et à m'enregistrer sur le serveur SIP. Mais aucune
communication ne passe. En collant un tcpdump sur la patte sur
laquelle est connectée le terminal SIP (Cisco SPA 112), je me suis
aperçu que les paquets RTP allaient vers une autre machine que le
proxy SIP. Pratique pour le routage !
J'ai donc restreint les plages UDP pour le RTP et, côté serveur
Linux, je route autoritairement tous les paquets UDP en question
vers le 192.168.10.250. Ça passe. En revanche, jusqu'à présent, je
n'avais fait côté NetBSD qu'ajouter une route vers un host précis
pour forcer les paquets SIP à emprunter le VPN.
Je viens de googliser, mais je ne vois pas trop comment forcer un
paquet sous NetBSD en fonction du port source et du protocole à
emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Manuel Bouyer
JKB wrote:
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB <jkb@koenigsberg.invalid> wrote:
[...]
Je viens de googliser, mais je ne vois pas trop comment forcer un
paquet sous NetBSD en fonction du port source et du protocole à
emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais
ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
J'en ai besoin pour router de la VoIP sur une route qui n'est pas la route par défaut (abonnement Nerim pour être tout à fait honnête). J'ai résolu mon problème différemment (avec quelques routes vers des host et net bien senties). Reste maintenant à savoir pourquoi la communication échoue après 18 secondes de communication...
J'ai trouvé entre temps dans la doc, mais je n'ai pas testé, qu'il était possible d'indiquer une règle de routage avec une interface et un 'next hop' comme ceci : tap0:192.168.1.128
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
[...]
Je viens de googliser, mais je ne vois pas trop comment forcer un
paquet sous NetBSD en fonction du port source et du protocole à
emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais
ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
J'en ai besoin pour router de la VoIP sur une route qui n'est pas la
route par défaut (abonnement Nerim pour être tout à fait honnête).
J'ai résolu mon problème différemment (avec quelques routes vers des
host et net bien senties). Reste maintenant à savoir pourquoi la
communication échoue après 18 secondes de communication...
J'ai trouvé entre temps dans la doc, mais je n'ai pas testé, qu'il
était possible d'indiquer une règle de routage avec une interface et
un 'next hop' comme ceci : tap0:192.168.1.128
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
J'en ai besoin pour router de la VoIP sur une route qui n'est pas la route par défaut (abonnement Nerim pour être tout à fait honnête). J'ai résolu mon problème différemment (avec quelques routes vers des host et net bien senties). Reste maintenant à savoir pourquoi la communication échoue après 18 secondes de communication...
J'ai trouvé entre temps dans la doc, mais je n'ai pas testé, qu'il était possible d'indiquer une règle de routage avec une interface et un 'next hop' comme ceci : tap0:192.168.1.128
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
Je viens de mettre la chose en oeuvre avec :
pass in on hme0 to tap0:192.168.1.1 proto tcp from 192.168.10.250 port = 80 to any
dans /etc/ipf.conf.
Tout ce qui vient du boîtier VoIP Cisco 192.168.10.250 sur le port 80/TCP est balancé vers le VPN et n'emprunte pas la route par défaut (qui est sur gem0).
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
[...]
Je viens de googliser, mais je ne vois pas trop comment forcer un
paquet sous NetBSD en fonction du port source et du protocole à
emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais
ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
Je viens de mettre la chose en oeuvre avec :
pass in on hme0 to tap0:192.168.1.1 proto tcp
from 192.168.10.250 port = 80 to any
dans /etc/ipf.conf.
Tout ce qui vient du boîtier VoIP Cisco 192.168.10.250 sur le port
80/TCP est balancé vers le VPN et n'emprunte pas la route par défaut
(qui est sur gem0).
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sat, 4 Apr 2015 16:23:34 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
[...] Je viens de googliser, mais je ne vois pas trop comment forcer un paquet sous NetBSD en fonction du port source et du protocole à emprunter une route qui ne serait pas la route par défaut...
Tout pointeur vers de la documentation sera le bienvenu.
Je n'ai jamais vraiment eu besoin de faire un truc comme ca, mais ca doit etre possible avec ipf (avec une regle fastroute, ou dup-to)
Je viens de mettre la chose en oeuvre avec :
pass in on hme0 to tap0:192.168.1.1 proto tcp from 192.168.10.250 port = 80 to any
dans /etc/ipf.conf.
Tout ce qui vient du boîtier VoIP Cisco 192.168.10.250 sur le port 80/TCP est balancé vers le VPN et n'emprunte pas la route par défaut (qui est sur gem0).
