Greywolf

21,22,23,80 => http://forum.zebulon.fr/index.php?showtopic=106502

le firewall de XP ne filtre que les connexions entrantes et ne sait pas gérer du suivi de connexion de protocole tel le FTP. Si tu n'arrives pas à te connecter à un FTP, c'est plus que probable que ton logiciel que tu utilises est configuré pour attendre la connexion de data en provenance du serveur FTP (connexion entrante). Si tu souhaites conserver le firewall de XP, 2 solutions: - basculer ton logiciel pour utiliser le mode passif ftp - créer une autorisation sur les connexions entrantes en provenance de TCP 20. (en espérant que ton routeur, lui, fasse le taf du suivi de session ftp)

c'est une note attribuée par les lecteurs au topic. C'est totalement subjectif et ne repose sur aucun critère quelconque de technicité, pertinence, autres .... C'est donc un non-indicateur (sauf échantillonnage statistiquement représentatif de la population zébulonienne ayant voté)

ça c'est une règle qui permet d'héberger un serveur ftp (ouverture du port 21 sur sa propre machine). Dans le cas d'un client FTP, cela ne sert strictement à rien) Vérifier le mode de transfert ftp (passif ou non) dans les options d'IE

Jana serveur fait autre chose que du proxy HTTP ? un logiciel de routage peut-être plus adapté (wooweb par exemple je crois) la clé IPenablerouter active le forwarding au niveau IP mais n'active pas de protocoles de routage (OSPF ou RIP) permettant d'échanger les tables de routage avec la livebox.

les 2 PC sont sur le même segment de réseau. Au pire, il faudra autoriser la connexion entrante sur TCP 3389 (en effet) sur le PC que l'on veut contrôler. Cependant, si l'invite d'ouverture de session interactive apparait c'est que la connexion fonctionne.

quelques liens pour se faire les dents http://www.linux-france.org/prj/inetdoc/gu...iple-links.html http://www.linux-france.org/prj/inetdoc/gu....netfilter.html (marquage des paquets ftp via la table mangle, génération de la politique de routage avec iproute via la connexion ethernet, les paquets non marqués passent par la connexion wifi)

si une session est déjà ouverte sur l'ordinateur distant, tu ne pourras pas en ouvrir une autre via rdesktop

tu évoquais le contrôle de PC, ce qui implique des outils d'administation à distance: rdesktop, vnc, radmin,... si c'est de l'échange de fichier, pourquoi ne pas utiliser les partages windows? le protocole FTP?

il faut que le PC1 se comporte comme un routeur et indiquer à la livebox que pour atteindre le réseau du PC2 il faille passer par PC1; seulement sous windows XP est-ce réalisable ?

peut-être en rapport avec ceci: http://www.lesnouvelles.net/articles/vulne...-explorer-.html http://secunia.com/Internet_Explorer_Addre...erability_Test/

http://www.microsoft.com/downloads/Search....?displaylang=fr merci google

oui mais du coup le service FTP ne serait plus joignable (à moins de raffiner la règle du pare-feu logiciel en fonction de l'adresse source, du jour, de l'heure, ...) Je ne connais plus trop les pare-feu sous windows mais j'imagine qu'un pare-feu à régles comme Jetico peut offrir ce genre de service

à partir du moment où tu "nattes" un port vers un PC, ce sera ce PC qui répondra aux sondes. en l'absence de firewall: Si un service FTP est actif sur ce PC, il y aura un TCP syn-ack de retransmis Si un service FTP est inactif sur ce PC, il y aura un TCP rst de retransmis avec un firewall d'actif et filtrant le port 21, il ne devrait y avoir aucune réponse aux sondes (i.e. port masqué)

Si le support n'a pas été compilé en dur ou en module dans le noyau du LiveCD, point de salut (sauf recompilation) Les liveCD destinés à être utilisés sur PC n'ont pas d'intérêt particulier à embarquer ce type de support (gain de place, de taille de l'image noyau) cat /proc/filesystems pour connaitre les différents FS gérés par ton liveCD

Ce conseil n'est-il pas valable uniquement sur un compte IMAP? le compactage des dossiers du client supprime réellement les mails sur le serveur IMAP à l'inverse d'une simple délétion qui les tagge au niveau du serveur edit: au temps pour moi, ça marche aussi pour un compte POP; pour info IMAP

topic original: http://forum.zebulon.fr/index.php?showtopic=133985 le titre du sous-forum Analyse, rapport HJT fait planter ton PC?

si la freebox affiche l'heure, c'est que le lien PPP a été établi avec le BAS. qui se bloque sur "lecture de l'adresse réseau" (m'étonnerait que cela soit la freebox)? comment as-tu connecté ton PC à la Freebox? disposes-tu d'un firewall actif sur ce PC?

une raison pour laquelle un PC est enregistré au niveau du routeur avec une adresse de classe C (192.168.x.y) et que le PC obtienne une adresse APIPA (169.254.x.y), c'est le déni de l'offre faite par le routeur au PC. Les causes probables sont des périphériques réseaux fantômes (multiples installations de la même carte) auxquels est associée l'adresse IP attribuée par le routeur: windows détecte un conflit d'adresse IP sur le réseau et refuse l'offre du serveur DHCP pour l'interface active (oui, c'est con windows...). On peut essayer la connectivité en attribuant manuellement une adresse du même réseau que le routeur et tester avec des pings (peut-être cela a-t-il déjà été tenté mais je n'ai pas lu l'intégralité du topic)

hotmail a blacklisté orange

IE se connecte en mode passif probablement et pas MF, c'est juste une histoire de réglage. Ceci dit utiliser un véritable client FTP est conseillé.

pourquoi rediriger UDP? pourquoi le port 23 (telnet) ? avec quoi se connectent tes amis? quel est le mode de transfert utilisé (passif ou non)? y-a-t-il des traces d'authentification dans les logs du serveur ftp?

la carte PCMCIA n'a-t-elle pas d'option de gestion d'alimentation d'activée? genre "éteindre ce périphérique quand windows le veut"

tu es chez Wanadoo/orange: serveur pop: pop.orange.fr serveur smtp: smtp.orange.fr

plus un paquet est important, plus il peut transporter de charge utile (MSS) certes mais plus il met de temps à transiter (taux de transfert en G|M|k|Bps) donc pour avoir un meilleur temps de réponse sur un paquet, il faut qu'il soit le plus petit possible. 1. un paquet icmp avec un payload de 32 octets (+ 8 header icmp + 20 header ip) font 60 octets à transmettre 2. PPPoE: un paquet icmp avec un payload de 1464 octets + 8 octets de pppoe + 8 octets icmp + 20 IP font 1500 octets à transmettre 3. PPPoA: un paquet icmp avec un payload de 1472 octets + 8 icmp + 20 IP font 1500 octets à transmettre Soit une liaison ADSL classique avec 64ko/s en upload (débit IP), pour transmettre 1. 60/64000 < 1ms 2. PPPoE: 1500 / 64000 = 0,023 s soit 23 ms 3. PPPoA: 1500 / 64000 = 0,023s soit 23 ms La différence n'est pas significative au regard de l'ordre de grandeur de transfert des paquets. Un petit mtu assure l'envoi rapide des paquets mais afin de reconstituer de l'information, il faut en envoyer plus et le nombre d'entêtes de protocole 3 et 4 devient pénalisant un gros mtu assure l'envoi plus lent de gros paquet mais contenant la quasi-totalité de l'information (optimisation au niveau de l'envoi des entêtes); sauf que si un paquet se perd en route, il faut le renvoyer en globalité. considérons une liaison à 100 bps et un payload de 1472 octets à transférer sur TCP (20 octets header IP et 20 octets header TCP) MaxMTU PPPoE, les trames ethernet sont limitées à 1500 octets, il faut décompter 8 octets de l'encapsulation PPPoE il faudra envoyer 2 paquets 1er paquet: 1452 +8 + 20 + 20 = 1500 octets = temps de transfert 15s 2eme paquet: 20 octets +8 + 20 + 20 = 60 octets soit 0.6s total 15,6 PPPoA 1er paquet: 1460 + 20 + 20 = 1500 octets (parce que nous sommes sur un LAN ethernet et non en prise directe sur ATM) 15s 2eme paquet: 12 + 20 + 20 = 52 octets soit 0.5s total 15,5 MTU 500octets PPPoE, les paquets ont un MSS limité à 500 - 48 = 452 octets pour envoyer 1472 octets, il faudra envoyer 4 paquets (3,25 exactement) PPPoA, les paquets ont une MSS limitée à 460 octets pour envoyer 1472 octets, il faudra envoyer 4 paquets (3,2 exactement) Si on considère que le dernier paquet a sa MSS de rempli avec des octets de bourrage, la différence ne sera pas flagrante A partir d'un Mo à transférer, on commence à voir des différences en terme de nombre de paquet à envoyer MaxMTU 1500 octets PPPoE 722 paquets (16,9s à 64ko/s) PPPoA 718 paquets (16,8s à 64ko/s) différence 4x23ms = 92ms MaxMTU 500 octets PPPoE 2320 paquets soit un overhead de 111ko (temps d'envoi 18,12 s à 64ko/s) PPPoA 2279 paquets soit un overhead de 91 ko (temps d'envoi 17,8 s à 64ko/s) et on ne compte pas les problèmes de congestion/routage/etc... note: ATM autorise des trames de 8192 octets contrairement à ethernet (1500) et est conçu pour le multiplexage entre audio,video, teléphonie, réseau informatique,...