[RESOLU] problème VNC entre 2 LAN à travers passerelle

ReNzO_08 · Février 20, 2016, 5:43pm

Bonjour,

Ce que je cherche à faire :

prendre la main sur un pc windows XP qui se trouve sur le réseau 192.168.2.0/24 (@ip:192.168.2.200) depuis mon pc portable sous DEBIAN qui se trouve sur le réseau 192.168.1.0/24 (@ip:192.168.1.13).
Ces 2 réseaux sont séparés par un PC passerelle sous IPCOP dont la patte réseau 192.168.1.0/24 est 192.168.1.2 et l’autre patte 192.168.2.1

Ce que j’ai fais :

=> PC Windows XP (192.168.2.200)

installé la partie serveur VNC et configuré pour écouter sur le port 5900/accès limité à 192.168.1.13 puis lancé en mode user (j’ai ouvert le port 5900 sur le “parefeu” windows)

=> PC portable DEBIAN (192.168.1.13)

installé la partie cliente VNC sur mon pc portable sous DEBIAN
ajouté la route pour aller sur le réseau 192.168.2.0/24 avec la commande suivante :
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.2
lancé le client avec la commande xvnc4viewer 192.168.2.200 (j’ai essayé aussi en ajoutant “:0”, “:1” pour le display mais je ne connais pas ce numéro car le vnc server de windows ne l’indique pas et en ajoutant l’option “-listen 5900”* pour préciser que le server écoute sur ce port)
*:avec cette commande (xvnc4viewer 192.168.2.200:0 -listen 5900)il n’y a aucun retour (même pas d’erreur ni de retour au prompt de bash)

=> IPCOP
-translation (NAT) de ports
adresse source : 192.168.1.13 port source : ?(ça change toujours mais je peux pas laisser vide pour autoriser n’importe quel port) adresse de destination : 192.168.2.200 port desination : 5900

Résultat :
ça marche pas

Je me pose plusieurs questions :

comment forcer l’utilisation d’un port de sortie particulier au client VNC?(celui-ci change tout le temps normal pour une application cliente mais moi IPCOP voudrait un port source défini…)
à priori ma route vers le réseau 192.168.2.0/24 est bonne (route -n le confirme et un traceroute me donne bien 192.168.1.2 en premier routeur) mais je n’arrive pas à pinguer l’@ip du pc windows (192.168.2.200) est-ce la commande indiqué au dessus vous semble correct?

si vous avez de plus d’information dites-le

merci

PascalHambourg · Février 20, 2016, 5:43pm

Pas besoin de translation de port.
Note : bien que ne connaissant pas IPCop je pense qu’il y a une confusion entre adresse/port “source” et adresse/port destination originels (avant la translation).
Il faut une route de retour sur le serveur afin qu’il puisse répondre au client. Ou alors il faut qu’IPCop fasse du masquerading (NAT source) sur l’interface ayant l’adresse 192.168.2.1, ainsi le serveur ne verra que cette adresse et pourra répondre sans route supplémentaire.
Il faut évidemment que les règles de filtrage iptables d’IPCop autorisent au minimum les connexions TCP depuis l’adresse du client vers l’adresse du serveur sur le port VNC.

themorice · Février 20, 2016, 5:43pm

Pour IPCOP.

Dans le NAT :

Le port source est le port sur lequel tu arrive .

Concretement, pour rediriger ton ssh :
port source : 22
port destination : 22

ReNzO_08 · Février 20, 2016, 5:43pm

Merci pour vos réponses

En attendant, j’ai ajouté la route vers le réseau 192.168.1.0 sur la machine windows (route add 192.168.1.0 mask 255.255.255.0 192.168.2.1) au cas où puisque effectivement j’avais pas penser au retour (réponse vers le client) mais même le ping passe pas sniff IPCOP à l’air restrictif bien que par défaut

voici un schéma pour vous aidez à m’aider ( ) le tant que je retrouve le mot de passe root pour l’accès ssh à Ipcop et vous donne les règles iptables qui nous permettra surement d’en savoir plus.

schéma :

PC DEBIAN(client VNC)
192.168.1.13/port sortie client VNC:5000
|
192.168.1.2 (patte coté 192.168.1.0/24)
IPCOP
192.168.2.1 (patte coté 192.168.2.0/24)
|
192.168.2.200/port d’écoute serveur VNC: 5900
PC WINDOWS XP (server VNC)

ReNzO_08 · Février 20, 2016, 5:43pm

Après avoir miséré avec scp voici les règles iptables de IPCOP

[code]Chain BADTCP (2 references)
pkts bytes target prot opt in out source destination
0 0 PSCAN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29
0 0 PSCAN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
0 0 PSCAN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x01
0 0 PSCAN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06
0 0 PSCAN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03
446 59577 NEWNOTSYN tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW

Chain CUSTOMFORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain CUSTOMINPUT (1 references)
pkts bytes target prot opt in out source destination

Chain CUSTOMOUTPUT (1 references)
pkts bytes target prot opt in out source destination

Chain DHCPBLUEINPUT (1 references)
pkts bytes target prot opt in out source destination

Chain DMZHOLES (1 references)
pkts bytes target prot opt in out source destination

Chain GUIINPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp – !eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 8

Chain INPUT (policy DROP pkts bytes target prot opt in 874K 52M ipac~o all – * * 874K 52M BADTCP all – * * 874K 52M CUSTOMINPUT all – * 874K 52M GUIINPUT all – * * 181K 13M ACCEPT all – * * 693K 39M IPSECVIRTUAL all – * 693K 39M OPENSSLVIRTUAL all – * 6 410 ACCEPT all – lo * 0 0 DROP all – * * 0 0 DROP all – * * 226K 18M ACCEPT !icmp – eth0 * 467K 21M DHCPBLUEINPUT all – * 467K 21M IPSECPHYSICAL all – * 467K 21M OPENSSLPHYSICAL all – * 467K 21M WIRELESSINPUT all – * 467K 21M REDINPUT all – * * 467K 21M XTACCESS all – * * 1854 176K LOG all – * * 467K packets, 21M bytes)
out source destination
0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0
* 0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
* 0.0.0.0/0 0.0.0.0/0
* 0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 state NEW
127.0.0.0/8 0.0.0.0/0 state NEW
0.0.0.0/0 127.0.0.0/8 state NEW
0.0.0.0/0 0.0.0.0/0 state NEW
* 0.0.0.0/0 0.0.0.0/0
* 0.0.0.0/0 0.0.0.0/0
* 0.0.0.0/0 0.0.0.0/0
* 0.0.0.0/0 0.0.0.0/0 state NEW
0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 state NEW
0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `INPUT ’

Chain FORWARD (policy DROP 3725 packets, 171K bytes)
pkts bytes target prot opt in out source destination
8950K 6203M ipac~fi all – * * 0.0.0.0/0 0.0.0.0/0
8950K 6203M ipac~fo all – * * 0.0.0.0/0 0.0.0.0/0
8950K 6203M BADTCP all – * * 0.0.0.0/0 0.0.0.0/0
156K 7858K TCPMSS tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
8949K 6203M CUSTOMFORWARD all – * * 0.0.0.0/0 0.0.0.0/0
8671K 6183M ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
278K 21M IPSECVIRTUAL all – * * 0.0.0.0/0 0.0.0.0/0
278K 21M OPENSSLVIRTUAL all – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all – * * 127.0.0.0/8 0.0.0.0/0 state NEW
0 0 DROP all – * * 0.0.0.0/0 127.0.0.0/8 state NEW
275K 21M ACCEPT all – eth0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all – eth2 eth2 0.0.0.0/0 0.0.0.0/0 state NEW
3753 173K WIRELESSFORWARD all – * * 0.0.0.0/0 0.0.0.0/0 state NEW
3757 173K REDFORWARD all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DMZHOLES all – eth2 * 0.0.0.0/0 0.0.0.0/0 state NEW
3753 173K PORTFWACCESS all – * * 0.0.0.0/0 0.0.0.0/0 state NEW
164 9008 LOG all – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `OUTPUT ’

Chain IPSECPHYSICAL (1 references)
pkts bytes target prot opt in out source destination

Chain IPSECVIRTUAL (2 references)
pkts bytes target prot opt in out source destination

Chain LOG_DROP (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain LOG_REJECT (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
0 0 REJECT all – * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain NEWNOTSYN (1 references)
pkts bytes target prot opt in out source destination
364 56294 LOG all – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? '
446 59577 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain OPENSSLPHYSICAL (1 references)
pkts bytes target prot opt in out source destination

Chain OPENSSLVIRTUAL (2 references)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 191K packets, 16M bytes)
pkts bytes target prot opt in out source destination
191K 16M ipac~i all – * * 0.0.0.0/0 0.0.0.0/0
191K 16M CUSTOMOUTPUT all – * * 0.0.0.0/0 0.0.0.0/0

Chain PORTFWACCESS (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – eth1 * 192.168.1.13 192.168.2.200 tcp dpt:5900

Chain PSCAN (5 references)
pkts bytes target prot opt in out source destination
0 0 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix TCP Scan? ' 0 0 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefixUDP Scan? '
0 0 LOG icmp – * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix ICMP Scan? ' 0 0 LOG all -f * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefixFRAG Scan? '
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0

Chain REDFORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – eth2 eth1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp – eth2 eth1 0.0.0.0/0 0.0.0.0/0

Chain REDINPUT (1 references)
pkts bytes target prot opt in out source destination

Chain WIRELESSFORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain WIRELESSINPUT (1 references)
pkts bytes target prot opt in out source destination

Chain XTACCESS (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 192.168.1.2 tcp dpt:113
0 0 ACCEPT tcp – eth1 * 192.168.1.13 192.168.1.2 tcp dpt:445
5 300 ACCEPT tcp – eth1 * 192.168.1.13 192.168.1.2 tcp dpt:222

Chain ipac~fi (1 references)
pkts bytes target prot opt in out source destination
0 0 all – eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 all – eth2 * 0.0.0.0/0 0.0.0.0/0
0 0 all – eth1 * 0.0.0.0/0 0.0.0.0/0

Chain ipac~fo (1 references)
pkts bytes target prot opt in out source destination
0 0 all – * eth0 0.0.0.0/0 0.0.0.0/0
0 0 all – * eth2 0.0.0.0/0 0.0.0.0/0
0 0 all – * eth1 0.0.0.0/0 0.0.0.0/0

Chain ipac~i (1 references)
pkts bytes target prot opt in out source destination
32 2016 all – * eth0 0.0.0.0/0 0.0.0.0/0
0 0 all – * eth2 0.0.0.0/0 0.0.0.0/0
178 52796 all – * eth1 0.0.0.0/0 0.0.0.0/0

Chain ipac~o (1 references)
pkts bytes target prot opt in out source destination
81 5993 all – eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 all – eth2 * 0.0.0.0/0 0.0.0.0/0
227 20215 all – eth1 * 0.0.0.0/0 0.0.0.0/0 [/code]

J’espère que ça vous permettra de savoir pourquoi rien ne passe entre les 2 réseaux et éventuellement me proposer une solution ou un piste

précisions :
eth0: patte 192.168.2.1
eth1: patte 192.168.1.2
eth2: sert pas (DMZ prévue)

ReNzO_08 · Février 20, 2016, 5:43pm

[quote=“PascalHambourg”]- Pas besoin de translation de port.
Note : bien que ne connaissant pas IPCop je pense qu’il y a une confusion entre adresse/port “source” et adresse/port destination originels (avant la translation).

Il faut une route de retour sur le serveur afin qu’il puisse répondre au client. Ou alors il faut qu’IPCop fasse du masquerading (NAT source) sur l’interface ayant l’adresse 192.168.2.1, ainsi le serveur ne verra que cette adresse et pourra répondre sans route supplémentaire.
Il faut évidemment que les règles de filtrage iptables d’IPCop autorisent au minimum les connexions TCP depuis l’adresse du client vers l’adresse du serveur sur le port VNC.[/quote]

Je pense que ta solution d’ip masquerade conviendrait bien : ça me permettrait d’utiliser la patte d’Ipcop qui se trouve sur le même réseau que mon pc portable comme adresse ip pour mon client VNC et IPCOP lui transmettrait cette requête au pc 192.168.2.200 qui se trouve sur l’autre patte/réseau.

Quelle serait la syntaxe iptables?je commence à m’emmêler un peu les pinceaux entre le port forwarding, le NAT et l’ ip masquerading je crois mais c’est complémentaire il me semble, c’est pas les mêmes chaines

themorice · Février 20, 2016, 5:43pm

A mon avis : sur Ipcop, évite de trop éditer les règles iptables à la main, passe plutôt par leur interface.

Ton portable est sur l’interface Green ? et ton serveur sur l’interface Orange ?

Edit : Un bon plugin IPCOP pour bien comprendre les stratégies par défaut et les modifier : Block Out Traffic

PascalHambourg · Février 20, 2016, 5:43pm

Si tu as ajouté la route qui va bien sur le serveur Windows (avec éventuellement l’option -p pour la rendre persistante après un reboot), tu n’as pas besoin de masquerade. D’autre part ce n’est pas l’adresse de la patte côté portable (client) mais l’adresse de la patte côté serveur (Windows) qu’il faudrait utiliser dans la règle de masquerade. De toute façon la cible MASQUERADE se débrouille pour trouver elle-même l’adresse à utiliser.

Par contre il faut autoriser le trafic, et je n’ai pas encore regardé les règles existantes. Cependant je suis d’accord avec themorice, il vaudrait mieux autoriser le trafic avec l’outil de configuration d’IPCop (que je ne connais pas) plutôt qu’en ajoutant directement des règles iptables.

Le NAT, c’est la translation d’adresse et de port en général.
Le “port forwarding” est une forme de NAT qui modifie l’adresse et/ou le port destination d’une connexion, grâce à la cible DNAT ou REDIRECT dans la chaîne PREROUTING (pour les connexions entrantes) ou OUTPUT (pour les connexions émises par la machine elle-même) de la table ‘nat’. L’“IP masquerading” est une autre forme de NAT qui modifie l’adresse et parfois le port source d’une connexion, grâce à la cible SNAT ou MASQUERADE dans la chaîne POSTROUTING de la table ‘nat’.

PascalHambourg · Février 20, 2016, 5:43pm

Bon, j’ai regardé les règles iptables. Normalement il y a ce qu’il faut pour autoriser les connexions VNC du portable vers le serveur :

Chain FORWARD (policy DROP 3725 packets, 171K bytes)
pkts bytes target     prot opt in     out     source               destination         
8671K 6183M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3753  173K PORTFWACCESS  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW

Chain PORTFWACCESS (1 references)
pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  eth1   *       192.168.1.13         192.168.2.200       tcp dpt:5900

Par contre on ne voit que le contenu de la table filter, que donne iptables-save ?

ReNzO_08 · Février 20, 2016, 5:43pm

[quote=“themorice”]A mon avis : sur Ipcop, évite de trop éditer les règles iptables à la main, passe plutôt par leur interface.

Ton portable est sur l’interface Green ? et ton serveur sur l’interface Orange ?
[/quote]
Le portable (VNC server)coté interface red et le pc windows coté interface green.Mon portable debian ayant les régles iptables qui vont bien en local (je n’accepte les connexions en entrée que si elles proviennent de réponse à des requêtes de connexions sortantes que j’ai moi même établie) que j’ai j’ai pas besoin qui soit derrière Ipcop il est directement derrière ma livebox mais le pc windows vu que le parefeu filtre qu’en entrée et qu’il se situe au niveau application du système je l’ai mis derrière Ipcop pr faire le boulot

c’est bizar que ça passe pas même le ping ne passe pas de l’un à l’autre (mais ça c petet une règles pour l’icmp)

[quote]Chain PORTFWACCESS (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- eth1 * 192.168.1.13 192.168.2.200 tcp dpt:5900
[/quote]
ça c’est une règle que j’ai ajouté avec l’interface d’administration web

[quote=“PascalHambourg”]
Par contre on ne voit que le contenu de la table filter, que donne iptables-save ?[/quote]

ah ui désolé je n’ai pas précisé la table donc c’est juste les règles de filter en effet je vais de ce pas rémédier à ça

merci à tout les 2

ReNzO_08 · Février 20, 2016, 5:43pm

mince iptables-save n’existe pas sur Ipcop mais voici ce que me donne un iptables -t nat -L -v -n

[code]Chain PREROUTING (policy ACCEPT 719K packets, 40M bytes)
pkts bytes target prot opt in out source destination
719K 40M CUSTOMPREROUTING all – * * 0.0.0.0/0 0.0.0.0/0
719K 40M SQUID all – * * 0.0.0.0/0 0.0.0.0/0
719K 40M PORTFW all – * * 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 182 packets, 44447 bytes)
pkts bytes target prot opt in out source destination
240K 18M CUSTOMPOSTROUTING all – * * 0.0.0.0/0 0.0.0.0/0
240K 18M REDNAT all – * * 0.0.0.0/0 0.0.0.0/0
0 0 SNAT all – * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x1 to:192.168.2.1
0 0 SNAT all – * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x3 to:172.16.0.1

Chain OUTPUT (policy ACCEPT 1556 packets, 131K bytes)
pkts bytes target prot opt in out source destination

Chain CUSTOMPOSTROUTING (1 references)
pkts bytes target prot opt in out source destination

Chain CUSTOMPREROUTING (1 references)
pkts bytes target prot opt in out source destination

Chain PORTFW (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp – * * 0.0.0.0/0 192.168.1.2 tcp dpt:5000 to:192.168.2.200:5900

Chain REDNAT (1 references)
pkts bytes target prot opt in out source destination
240K 18M MASQUERADE all – * eth1 0.0.0.0/0 0.0.0.0/0

Chain SQUID (1 references)
pkts bytes target prot opt in out source destination [/code]

et iptables -t mangle -L -v -n

[code]Chain PREROUTING (policy ACCEPT 10M packets, 6415M bytes)
pkts bytes target prot opt in out source destination
10M 6415M PORTFWMANGLE all – * * 0.0.0.0/0 0.0.0.0/0

Chain INPUT (policy ACCEPT 952K packets, 58M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 9180K packets, 6357M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 226K packets, 19M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 9618K packets, 6380M bytes)
pkts bytes target prot opt in out source destination

Chain PORTFWMANGLE (1 references)
pkts bytes target prot opt in out source destination
0 0 MARK tcp – * * 192.168.2.0/24 192.168.1.2 tcp dpt:5000 MARK set 0x1
0 0 MARK tcp – * * 172.16.0.0/24 192.168.1.2 tcp dpt:5000 MARK set 0x3 [/code]

et la table de routage (toujours de Ipcop)

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1

note : ne pas faire attention au réseau 172.16.0.0 je m’en sers pas pour le moment c’était au cas où (dmz)

(Je me demande si ça serait pas plus simple de partir de rien et faire ses propres règles en partant d’une Debian pour remplacer Ipcop pour savoir exactement quelle règle fait quoi parceque là c’est compliqué)

PascalHambourg · Février 20, 2016, 5:43pm

Je ne vois rien dans les tables ‘nat’ et ‘mangle’ qui pose problème. Par contre c’est normal que le ping ne passe pas, seules les connexions TCP sur le port 5900 de 192.168.2.200 depuis 192.168.1.13 sont autorisées. Tu peux tester depuis 192.168.1.13 avec tcptraceroute :

Pour vérifier que c’est bien un problème de règles iptables et pas autre chose (route, firewall sur la machine Windows…), tu peux temporairement insérer en début de chaîne FORWARD une règle qui accepte tout :

Pour la supprimer ensuite :

Remplacer IPCop par une Debian, c’est ce que je ferais mais c’est parce que j’ai une connaissance suffisante d’iptables.

ReNzO_08 · Février 20, 2016, 5:43pm

Ayé ça marche

c’était tout con dans le parefeu de windows j’avais voulu affiner la règle du coup le port 5900 était filtré (j’avais rajouté comme étendue réseau 192.168.2.0/255.255.255.0 :s)en l’ouvrant juste sans modifier l’étendue ça passe.

En tout cas c’est grâce à ton aide, avant que tu m’assure que les règles étaient bonnes j’étais persuadé que c’était elles qui empêchaient la connexion, et j’ai même essayé la règle pour accepter tout en forward et comme ça marchait toujours pas j’ai vérifié le parefeu de la machine windows et c’était effectivement ce qui n’allait pas

Sinon je connaissais pas tcptraceroute, ça peut rendre des services mais je sais pas pour quelle(s) raison(s) il ne m’indique que la patte 192.168.1.2 et ensuite plus rien (des ****) traceroute pareil et ce même vers une cible sur internet (je vois mon routeur et plus rien après) tu aurais une idée comme tu as l’air bien calé en réseau?

merci

themorice · Février 20, 2016, 5:43pm

traceroute est basé sur des pings il me semble. Donc si le ping est bloqué ça doit poser problème.

PascalHambourg · Février 20, 2016, 5:43pm

traceroute envoie des paquets UDP par défaut, ou des ICMP “echo request” (comme ping) avec l’option -I. L’ennui, c’est qu’il n’est pas rare que ces paquets soient filtrés par les firewalls. tcptraceroute fonctionne sur le même principe mais envoie des paquets TCP de demande de connexion (SYN) sur le port spécifié (80 par défaut). Il est donc utile pour tester la connectivité avec un serveur dont on sait qu’il écoute sur un port TCP quelconque (80 pour un serveur web, 5900 pour un serveur VNC…).

Les deux programmes ont pour principe d’incrémenter à partir de 1 le TTL des paquets émis pour recevoir un paquet ICMP “TTL exceeded” de chaque noeud traversé, donc il ne faut pas bloquer ces paquets en entrée de la machine émettrice. Comme ils sont dans l’état RELATED, il suffit d’avoir la classique règle en début de chaîne :

Si tu ne vois aucun noeud intermédiaire, je pencherais pour cette hypothèse. Mais si une connexion TCP avec la cible réussit, alors tcptraceroute sur le même port devrait au moins afficher le dernier noeud qui est la machine cible. Une explication pourrait être que les paquets SYN de tcptraceroute diffèrent légèrement des paquets SYN classiques (notamment ils ne contiennent pas d’option MSS), et que certains firewalls trop zélés les bloquent pour cette raison.

ReNzO_08 · Février 20, 2016, 5:46pm

Je réponds un peu tard (j’étais pas chez moi ces derniers jours) mais je voulez vous remercier pour ses informations.

Je pense que c’est le parefeu de ma livebox qui bloc puisque quand je fais un traceroute vers n’importe quelle cible sur internet je n’obtiens que sa patte coté interne (192.168.1.1) et après plus rien et si je passe par un site internet qui propose traceroute et que j’essaie un traceroute vers une cible là ça marche sans problème vu que ça part de leur serveur vers la cible et non de chez moi vers la cible.

Enfin c’est pas très grave.

Merci à vous 2