<releaseinfo>$Id: realisation.xml,v 1.2 2003/11/23 20:58:49 laurent Exp $</releaseinfo>
Copyright © 2003
Les différents tests ont été réalisé dans les conditions suivantes : Un des clients se trouvait derrière la passerelle LINUX (RedHat7) , l'autre en frontal (voir détail des connexions)
Bon, ceci-étant, la mise en oeuvre est relativement lourde puisqu'il faut patcher le kernell, recompiler ... Mais le but était de vérifier si l'utilisation d'un logiciel de visio-conférence était possible derrière une passerelle LINUX. Visualiser le détail des connexions ... ... Affaire à suivre ;o)
> Est-ce qu'on peut savoir comment ça se traduit au niveau des ports ouverts sur la passerelle ?
Bon, j'éssais de m'expliquer : (ou plutôt d'apporter des éléments de réponse ...)
Concrètement, 5 ports sont ouverts pour permettre le passage d'une visio au travers de la passerelle. (constaté) La machine situé côté intranet devant initié la connexion, se trouve être le "CLIENT" Netmeeting. Les ports qui vont lui être attribués par le serveur Netmeeting seront donc dynamique et unique > 1024. Etant dynamique, la valeur de ces ports ne peut être connue à l'avance. En revanche, les ports utilisés par l'application "SERVEUR" de Netmeeting sont connus : 389, 522, 1503, 1720, 1731
Voilà ce qu'on peut voir au niveau des connexions TCP et UDP lors d'une visio entre un CLIENT Netmeeting situé derrière un SLIS et un SERVEUR Netmeeting localisé sur Internet :
Topologie :Etapes :
Les connexions résultantes, d'après un "netstat -n" sous Windows :
================================================ Proto Adresse locale Adresse distante ================================================ TCP 62.212.105.43:1411 193.251.69.69:1087 | TCP 62.212.105.43:1503 193.251.69.69:1090 | TCP 62.212.105.43:1503 193.251.69.69:1091 |<= "vue" machine Extranet (SERVEUR Netmeeting) TCP 62.212.105.43:1503 193.251.69.69:1092 | TCP 62.212.105.43:1720 193.251.69.69:1086 | ================================================ TCP 172.16.101.3:1086 62.212.105.43:1720 | TCP 172.16.101.3:1087 62.212.105.43:1411 | TCP 172.16.101.3:1090 62.212.105.43:1503 |<= "vue" machine Intranet (CLIENT Netmmeting) TCP 172.16.101.3:1091 62.212.105.43:1503 | TCP 172.16.101.3:1092 62.212.105.43:1503 | ================================================
Les connexions résultantes, présentées différemment :
===================================================================== Proto SERVEUR Netmeeting Gateway CLIENT Netmmeting ===================================================================== TCP 62.212.105.43:1411 193.251.69.69:1087 172.16.101.3:1087 TCP 62.212.105.43:1503 193.251.69.69:1090 172.16.101.3:1090 TCP 62.212.105.43:1503 193.251.69.69:1091 172.16.101.3:1091 TCP 62.212.105.43:1503 193.251.69.69:1092 172.16.101.3:1092 TCP 62.212.105.43:1720 193.251.69.69:1086 172.16.101.3:1086 =====================================================================
les ports n'ont subi quant à eux aucune modification.
Cependant, n'étant pas tout à fait convaincu par ce que je dis et sentant bien que quelque chose m'échappe ... (notament au niveau du travail réalisé par ip_conntrack_h323 et ip_nat_h323, qui serait transparent !! ) J'écoute donc ce qui se passe dans le monde fou des interfaces de la passerelle, et là surprise :
#tcpdump -i eth0 -f |grep -v ssh | grep -v 8000 05:51:13.363443 PPPoE [ses 0xddf] IP 58: 193.251.69.69.49589 > 62.212.105.43.49609: udp 28 05:51:13.387188 PPPoE [ses 0xddf] IP 259: 62.212.105.43.49606 > 193.251.69.69.49586: udp 229 05:51:13.465645 PPPoE [ses 0xddf] IP 492: 62.212.105.43.49606 > 193.251.69.69.49586: udp 462 05:51:13.537088 PPPoE [ses 0xddf] IP 117: 62.212.105.43.49606 > 193.251.69.69.49586: udp 87 05:51:13.615895 PPPoE [ses 0xddf] IP 355: 62.212.105.43.49606 > 193.251.69.69.49586: udp 325 05:51:13.689423 PPPoE [ses 0xddf] IP 440: 62.212.105.43.49606 > 193.251.69.69.49586: udp 410 05:51:13.725212 PPPoE [ses 0xddf] IP 121: 62.212.105.43.49606 > 193.251.69.69.49586: udp 91 05:51:13.811204 PPPoE [ses 0xddf] IP 338: 62.212.105.43.49606 > 193.251.69.69.49586: udp 308 05:51:13.880990 PPPoE [ses 0xddf] IP 459: 62.212.105.43.49606 > 193.251.69.69.49586: udp 429 05:51:13.924366 PPPoE [ses 0xddf] IP 188: 62.212.105.43.49606 > 193.251.69.69.49586: udp 158 05:51:13.997857 PPPoE [ses 0xddf] IP 220: 62.212.105.43.49606 > 193.251.69.69.49586: udp 190 05:51:14.067333 PPPoE [ses 0xddf] IP 379: 62.212.105.43.49606 > 193.251.69.69.49586: udp 349 05:51:14.133301 PPPoE [ses 0xddf] IP 451: 62.212.105.43.49606 > 193.251.69.69.49586: udp 421 05:51:14.180066 PPPoE [ses 0xddf] IP 129: 62.212.105.43.49606 > 193.251.69.69.49586: udp 99
#tcpdump -i eth1 -af |grep -v 5900 05:55:51.634330 62.212.105.43.49606 > 172.16.101.3.49586: udp 490 05:55:51.678649 62.212.105.43.49606 > 172.16.101.3.49586: udp 141 05:55:51.752954 62.212.105.43.49606 > 172.16.101.3.49586: udp 313 05:55:51.818247 62.212.105.43.49606 > 172.16.101.3.49586: udp 393 05:55:51.881339 62.212.105.43.49606 > 172.16.101.3.49586: udp 321 05:55:51.950910 62.212.105.43.49606 > 172.16.101.3.49586: udp 403 05:55:52.036765 62.212.105.43.49606 > 172.16.101.3.49586: udp 222 05:55:52.099600 62.212.105.43.49606 > 172.16.101.3.49586: udp 239 05:55:52.167589 62.212.105.43.49606 > 172.16.101.3.49586: udp 269 05:55:52.239469 62.212.105.43.49606 > 172.16.101.3.49586: udp 423 05:55:52.293235 62.212.105.43.49606 > 172.16.101.3.49586: udp 273 05:55:52.349412 62.212.105.43.49606 > 172.16.101.3.49586: udp 133 05:55:52.423768 62.212.105.43.49606 > 172.16.101.3.49586: udp 341
les ports utilisés sont très "haut", et n'ont plus rien à voir avec ceux utilisés par les 2 machines exécutant le service netmeeting ! De plus, Il ne passe plus que de l'UDP ... Résultat de la "mécanique" ip_conntrack_h323 et ip_nat_h323s ? (tracking, réécriture ...) A ce niveau, un travail s'éffectue, c'est sur ! mais là, je ne sais plus interpréter ...
je vous livre les différents opérations que nous avons réalisé pour mettre en oeuvre la redirection H323 : Merci à Patrick, le patcheur fou, sans qui rien n'aurait été possible ...
Nous avons utilisé l'utilitaire P-O-M de chez netfilter On récupère le patch : ftp.netfilter.org/pub/patch-o-matic/snapshot/patch-o-matic-20021017.tar.bz2 #./runme /submitted (installe les patches préconisés par netfilter) On installe toutes la série ("yes" to all), certains patches trop récent ne passe pas cause kernel trop ancien, on passe ("enter") - on installe le patche qui nous intéresse précisément (h323) : #./runme extra/h323-conntrack-nat.patch
- Le compilateur doit être installé (gcc) - librairie ncurse pour accéder au menu graphique on récupère la conf du kernel redhat (dans/boot/config-2.4) #make menuconfig on choisi les options à compiler : => networking option ==> netfiler configuration puis on active : - h323 (en tant que module (pas le choix)) - NAT of local connection on créé les dépendances : #make dep #make clean
#make bzImage ("b" comme big zimage) <![CDATA[ </programlisting> </sect2> <sect2><title>Compilation des modules </title> <programlisting> <![CDATA[ #make modules
#make modules_install #depmod -a les modules sont installés /lib/modules/2.4.18-10custom/ récupérer le System.map dans /usr/src/linux 2.4 le copier dans /boot (attention on écrase le précédent, ou possibilité de faire un boot multi-noyaux => alors modif du chargeur de démarrage...) récupérer le noyaux : /usr/src/linux/arch/i386/boot/bZimage le copier dans /boot le renommer par /vmlinuz-2.4.18-10 On décharge ensuite les modules : #rmmod -a (éventuellement plusieurs fois, cause sous-modules) On refait l'image ramdisk : #mkinitrd /boot/System.map-2.4.18-10.img 2.4.18-10custom c'est fini ;o) #reboot
Pour rendre active la redirection, on éxécute le script suivant :
#! /bin/bash EXTERNAL_IF=eth0 EXTERNAL_IP=193.251.69.69 PCA_HOST=172.16.101.3 IPTABLES=/sbin/iptables /sbin/modprobe -a -k -s -v ip_nat_h323 logger -s "H323 Ports" H323_PORTS="389 522 1503 1720 1731 8080" for PORT in $H323_PORTS; do $IPTABLES -t nat -A PREROUTING -i $EXTERNAL_IF -p tcp -d $EXTERNAL_IP \ --dport $PORT -m state --state NEW,ESTABLISHED,RELATED \ -j DNAT --to-destination $PCA_HOST -v done logger -s "H323 Ports" H323_PORTS="389 522 1503 1720 1731 8080" for PORT in $H323_PORTS; do $IPTABLES -t nat -A PREROUTING -i $EXTERNAL_IF -p udp -d $EXTERNAL_IP \ --dport $PORT -m state --state NEW,ESTABLISHED,RELATED \ -j DNAT --to-destination $PCA_HOST -v done
Pour une mise en oeuvre plus simple, nous proposons un Package RPM :