Bonjour à tous,
 
Voilà la situation :
 
Je doit donner accès à un VNC installé sur un poste d'un reseau connecté à l'ADSL par un routeur/FW alcatel speedtouch 610. Il n'y a pas d'IP fixe sur cet accès.
 
Après quelques recherches sur le net j'en ai conclus qu'il fallait :
 
1/ S'abonner à un service type dyndns pour compenser l'absence d'IP fixe. Ca c'est bon, ca marche (MAJ de l'IP OK avec le client de MAJ integré au routeur).
 
2/ Ouvrir le port 5900 sur le FW. (c'est à prioris ce port -et les suivants- qui est utilisé par VNC.)
 
3/ 'Router' ce port sur l'IP du PC ou tourne VNC server.
 
 
Pour le 3/ c'est a prioris OK par contre pour le 2/ j'ai un peu de mal : j'ai fait pas mal d'essais avec des infos glannées sur le net et j'en suis arrivé au fait que si je test le port 5900 sur des outils en ligne (genre grc.com) mon port 5900 est ouvert quand un VNC server tourne et fermé lorsque je l'arrète. tout les autre ports étant 'Stealth'.
 
Ce qui est bizarre c'est que celà reste vrai même si je retire les règles que j'avais rajouté  et que  si je lance un VNC viewer sur un autre poste en donnant comme server l'adresse dyndns il ne trouve pas de serveur !
 
Voilà, si quelqu'un avait une idée ... Ai-je oublier de faire un truc ?
Comment voir à quel moment ça foire ? routage ? FW ?
 
Merci d'avance,
 
A+
 
PS : Autre question : comment se fait t'il que quand je tape seulement l'adresse chez dyndns (toto.dyndns.org) dans un navigateur (ou que je fait un telnet vers cette adresse) je tombe sur la fenêtre de login de l'admin de mon routeur ??? Les tests de vulnérabilité me donne tous les ports Stealth (dont le Telnet), je ne comprend pas !

Stealth = caché, non pas fermé (closed)
 
désactive l'administration a distance (si c'est possible sur ton model de routeur) comme sa seulement les postes local pouront administrer le routeur.
 
Pour le VPN... donne des détails... quel protocole tu prends ? les OS clients/server...etc...

pour vnc en config serveur standard sous windows il faut router les port 5800 et 5900.
 
Kernel panic : ou tu vois du vpn  
 
pour le stealth qd le serveurest démarré c'est normal ! cela signifie que ton serveur vnc "répond" sur le port 5900...
 
si tu le coupe et que rien ne répond ben c'est caché...
 

 
euh bonne question    
 
Pour le VNC c'est bien 5800/5900 par défault  

 
Dans mon esprit 'stealth' ç'était plutôt caché ET fermé, me goure-je ?
 

 
Test fait de l'extérieur du reseau (de chez moi), le routeur se comporte correctement à ce niveau (c'est à dire pas d'admin à distance ni par web, ni telnet). Le problème c'est que cela veux dire que le routeur est en mesure de savoir qu'un poste appartient au reseau (et se comporte comme tel) même si se poste passe par internet pour faire ses demandes (dyndns ...), ca va être chiant pour mes tests çà !
Quelqu'un pourrait t'il m'expliquer comment celà fonctionne ?
 
 
Merci pour ton aide,
 
A+

 
le 5800 j'en ai pas besoin, c'est pour l'utilisation par fenêtre web ..
 

 
Euh ... pardon, je comprends pas tout là ...
Moi j'ai tout mes ports en 'stealth' (normal) sauf le 5900 qui lui est en 'OPEN' quand un server VNC est lancé et en 'CLOSED' quand il n'y en a pas ! Le pb c'est que j'ai suprimmer les règles liées à ce port et que c'est toujours pareil ...
 
Merci pour ton aide,
 
A+

 
Stealth, c'est caché, c'est  un port furtif.. on peux pas dire si il est ouvert...fermer..en écoute..etc
 
Quand tu envois une trame TCP (pour te connecter a telnet par exemple) la trame contient l'addresse IP source et destination, cette trame tu l'envois au routeur ( le boulot du routeur c'est de router les trames justement) donc le routeur connais sont addresse Public et Privé (Internet et local) ainsi que tout les IP de son réseau/sous-réseau, réseau dans ton cas, donc quand le routeur reçoit la trame il se rend conte que la trame arrive de l'intérieur et est destiner a l'intérieur, dans ce cas précis la trame est destiné au routeur vu qu'aucune règle de routage ne spécifie d'envoyer tout les trames qui arrive sur le port23 vers un poste X du réseau

 
Oui, question de vocabulaire ... Mais pour celui qui voit le port en stealth, il est fermé pour lui ... Celà ne veux pas dire qu'il n'est pas ouvert pour un autre, mais bon, c'est pareil pour 'closed' : un port peut être 'closed' pour certain et Open ou stealth pour d'autres (selon les règles du FW !).
 

 
Oui, mais là il n'y a pas de raison qu'il considère l'IP comme interne au reseaux vu qu'elle à du être 'natée', l'IP que devrait voir le routeur devrait être simplement sa propre IP publique (celle assigné pas le FAI)! non ?
 
A+

 
Bon en vulgarisant plus ca nous donne a peu pres ca:
un LAN > 192.168.1.0/24
ip du routeur > 192.168.1.1
ip public > 128.39.32.123
 
Le poste1 envois une demande sur 128.39.32.123 pour le port 23
 
-Poste1(192.168.1.193): envois la trame[src:192.168.1.193-dst:128.39.32.123-dport:23] déja en partant le Poste1 sait que l'ip 128.39.32.123 ne fait pas parti de sont réseau, donc il envois la trame directement a sa paserelle par défault, le routeur
-Routeur(192.168.1.1-128.39.32.123): recois la trame[src:192.168.1.193-dst:128.39.32.123-dport:23] et l'analyse et vien a la conclusion que:
*128.39.32.123 = lui meme (donc il n'envois pas la trame faire le tour du monde pour qu'elle lui revienne)
*192.168.1.193 = une addresse connu de mon réseau
*port23 = oui, j'offre le service Telnet pour 192.168.1.0/24 ET je nai pas de règle explicite de renvois vers un poste X sur 192.168.1.0/24 DONC je considère cette demande comme m'étant destiné.

2eme exemple mais avec le port 23 natté vers le poste3 (192.168.1.239)
 
un LAN > 192.168.1.0/24
ip du routeur > 192.168.1.1
ip public > 128.39.32.123
 
Le poste1 envois une demande sur 128.39.32.123 pour le port 23
 
-Poste1(192.168.1.193): envois la trame[src:192.168.1.193-dst:128.39.32.123-dport:23] déja en partant le Poste1 sait que l'ip 128.39.32.123 ne fait pas parti de sont réseau, donc il envois la trame directement a sa paserelle par défault, le routeur
-Routeur(192.168.1.1-128.39.32.123): recois la trame[src:192.168.1.193-dst:128.39.32.123-dport:23] et l'analyse et vien a la conclusion que:
*128.39.32.123 = lui meme (donc il n'envois pas la trame faire le tour du monde pour qu'elle lui revienne)
*192.168.1.193 = une addresse connu de mon réseau
*port23 = oui, j'offre le service Telnet pour 192.168.1.0/24 MAIS j'ai une règle explicite qui m'indique que TOUT le traffic destiner a 128.39.32.123:23 doits etre renvoyé au poste3 a 192.168.1.239:23 donc je renvois la trame vers le poste3 et je vais agir comme pont entre poste1 et poste3

 
Merci pour ces infos, en fait j'était persuadé que la resolution de DNS chez dyndns faisaient que mes paquets sortait du réseau, mais les tracert et les ping semblent me prouver que ce n'est pas le cas ... comme tu le pensais !
 
Donc maintenant en plus de mon problème de paramêtrage de FW, je vais avoir des pbs pour les tests ...
Suis je obligé d'utiliser une machine hors reseaux (connecté par modem par ex) pour tester mon système ?
 
Encore merci, A+

Bon, du nouveau,
 
Pour pas être emmerdé, j'ai virer toutes les règles du FW et tout repris à 0, à partir de configs types trouvées sur le net j'ai mis en place ces regles :  
 
:firewall rule flush
:firewall flush
:firewall chain create chain=input
:firewall chain create chain=output
:firewall chain create chain=source
:firewall chain create chain=sink
:firewall chain create chain=forward
:firewall assign  hook=input chain=input
:firewall assign  hook=sink chain=sink
:firewall assign  hook=forward chain=forward
:firewall assign  hook=source chain=source
:firewall assign  hook=output chain=output
 
:firewall rule create chain=sink index=0 prot=udp dstport=dns action=accept  
:firewall rule create chain=sink index=1 prot=icmp icmptype=echo-request action=accept  
:firewall rule create chain=sink index=2 srcintf=!eth0 action=drop  
:firewall rule create chain=sink index=3 prot=udp dstport=67 dstportend=68 action=accept
:firewall rule create chain=sink index=4 prot=tcp srcintf=eth0 dstport=20 action=accept  
:firewall rule create chain=sink index=5 prot=tcp srcintf=eth0 dstport=21 action=accept  
:firewall rule create chain=sink index=6 prot=tcp srcintf=eth0 dstport=23 action=accept  
:firewall rule create chain=sink index=7 prot=tcp srcintf=eth0 dstport=80 action=accept  
:firewall rule create chain=sink index=8 action=drop  
:firewall rule create chain=source index=0 prot=udp dstport=dns action=accept  
:firewall rule create chain=source index=1 dstintf=eth0 action=accept  
:firewall rule create chain=source index=2 prot=udp dstport=67 action=accept  
:firewall rule create chain=source index=3 prot=icmp icmptype=echo-reply action=accept  
:firewall rule create chain=source index=4 action=drop
 
:firewall rule create chain=input index=0 srcintfgrp=lan dstintfgrp=lan action=accept
:firewall rule create chain=input index=1 prot=udp dstintfgrp=wan dstport=53 action accept
:firewall rule create chain=input index=2 prot=udp dstintfgrp=lan srcport=53 action accept
:firewall rule create chain=input index=3 prot=tcp dstintfgrp=wan dstport=80 action accept
:firewall rule create chain=input index=4 prot=tcp dstintfgrp=wan dstport=443 action accept
:firewall rule create chain=input index=5 prot=tcp dstintfgrp=lan srcport=80 action accept
:firewall rule create chain=input index=6 prot=tcp dstintfgrp=lan srcport=443 action accept
:firewall rule create chain=input index=7 prot=tcp dstintfgrp=wan dstport=21 action accept
:firewall rule create chain=input index=8 prot=tcp dstintfgrp=wan dstport=20 action accept
:firewall rule create chain=input index=9 prot=tcp dstintfgrp=lan srcport=21 action accept
:firewall rule create chain=input index=10 prot=tcp dstintfgrp=lan srcport=20 action accept
:firewall rule create chain=input index=11 prot=tcp dstintfgrp=wan dstport=119 action accept
:firewall rule create chain=input index=12 prot=tcp dstintfgrp=lan srcport=119 action accept
:firewall rule create chain=input index=13 prot=tcp dstintfgrp=wan dstport=25 action accept
:firewall rule create chain=input index=14 prot=tcp dstintfgrp=wan dstport=110 action accept
:firewall rule create chain=input index=15 prot=tcp dstintfgrp=lan srcport=25 action accept
:firewall rule create chain=input index=16 prot=tcp dstintfgrp=lan srcport=110 action accept
:firewall rule create chain=input index=17 prot=tcp dstintfgrp=wan dstport=5900 action accept
:firewall rule create chain=input index=18 prot=tcp dstintfgrp=lan srcport=5900 action accept
:firewall rule create chain=input index=19 srcintfgrp=lan dstintfgrp=wan action=drop
:firewall rule create chain=input index=20 srcintfgrp=wan dstintfgrp=lan action=drop
:config save
 
De ce côté cela semble être OK le port 5900 est ouvert ou closed (selon que le serveur VNC tourne ou pas), tout les autres ports sont 'stealth' et l'accès au net de l'interieur du réseau est OK (web, mail, ftp ...).
 
au niveau du nat j'ai ca :
 

 
130.1.130.60 étant biensûr l'IP de la machine ou tourne VNCserver
 
mais quand je lance un VNC viewer sur l'adresse chez dyndns, il me dit toujours qu'il ne trouve pas le serveur ...
 
merci d'avance pour votre aide !
 
A+

ajoute:  
TCP:5901
TCP:5800
TCP:5801
 
et hmmm avec 130.1.130.60, tu n'est pas dans une range d'ip local...

 
Comportement idem ... d'après le test de grc.com le 5901, 5800, 5801 sont stealth ... d'après mes règles ils devraient être closed
 
[IDEM plus haut] puis :
 
:firewall rule create chain=input index=17 prot=tcp dstintfgrp=wan dstport=5900 action accept
:firewall rule create chain=input index=18 prot=tcp dstintfgrp=lan srcport=5900 action accept
:firewall rule create chain=input index=19 prot=tcp dstintfgrp=wan dstport=5901 action accept
:firewall rule create chain=input index=20 prot=tcp dstintfgrp=lan srcport=5901 action accept
:firewall rule create chain=input index=21 prot=tcp dstintfgrp=wan dstport=5800 action accept
:firewall rule create chain=input index=22 prot=tcp dstintfgrp=lan srcport=5800 action accept
:firewall rule create chain=input index=23 prot=tcp dstintfgrp=wan dstport=5801 action accept
:firewall rule create chain=input index=24 prot=tcp dstintfgrp=lan srcport=5801 action accept
:firewall rule create chain=input index=25 srcintfgrp=lan dstintfgrp=wan action=drop
:firewall rule create chain=input index=26 srcintfgrp=wan dstintfgrp=lan action=drop
 

 
Ah bon ... Ce n'est pas moi qui est fait la numérotation du resau (IP fixes) quand c'est moi qui le fait je numerote en 192.168... mais j'avoue qu'à ce niveau je n'y connait pas grand chose, cette numérotation pourrait poser problème ou c'est juste un problème de norme ?
 
A+

ta combien de poste ?
l'ip du routeur est ?

 
une quinzaines de postes ...
 
l'ip du routeur c'est 130.1.130.1 (celle là c'est moi qui l'ai mise en rapport avec le reste de la numérotation).

OrgName:    AT&T Bell Laboratories
OrgID:      ATT
Address:    3200 Lake Emma Road
City:       Lake Mary
StateProv:  FL
PostalCode: 32746
Country:    US
 
NetRange:   130.1.0.0 - 130.10.255.255
CIDR:       130.1.0.0/16, 130.2.0.0/15, 130.4.0.0/14, 130.8.0.0/15, 130.10.0.0/16
 
ca peux posé probleme...
utilise une class C si tu a seulement 15 postes

Bon, après quelques temps où j'ai du me concentré sur autre chose je reviens sur ce problème ...
 
Je viens encore de faire des essais mais celà ne marche toujours pas ...  
 
Quelqu'un pourrait essayer de faire un VNC sur : 80.11.174.58 afin de voire si il obtient la fenêtre de login ? (Nota : ce n'est pas une IP fixe et j'en changerais dès les tests réalisés).
 
Merci d'avance,  
 
A+  

Je viens de tester et j'obtiens la fenêtre de login.

 
Merci beaucoup, le problème vient donc du fait que je test de l'interieur du resaux !
 
Mes réglages sont donc surement OK mais pas testable d'ici !
 
Encore merci, A+
 
PS : Pour les autres, plus besoin de tester, je change d'IP !