Bonsoir,
j'ai
installé tinyproxy sur mon PC pour le faire tourner sur mon ordinateur
h24. J'ai une connexion vers un VPN avec OpenVPN.
Ce que je veux c'est faire office de proxy pour ceux qui se trouvent sur
le même réseau que moi (RENATER - résidence universitaire). Le soucis
c'est que, ne sachant pas pourquoi, mais le firewall reconnait la
tentative de connexion vers le proxy et la bloque.
Tout d'abbord j'ai du changer de port (8888 -> 80) pour pas que ça
soit bloqué. Mais finalement, pourquoi je suis bloqué lorsque je mets
l'adresse local manuelement, sur le navigateur, du serveur tinyproxy sur
un autre pc? Bah oui, ne peut-il pas communiquer directement avec le
serveur (mon pc) au lieu de passer vers le routeur (il passe vers le
routeur vu que ce dernier bloque). Pourtant j'arrive bien les connexions
ssh sur le port 22, avec un réseau vers l'Internet bloquant tout sauf
80 et 443 (normal, ssh se fait sur le réseau local).
Ma question est donc, pourquoi suis-je bloquer en indiquant l'adresse
local du proxy sur mon navigateur (basé sur firefox)? Et comment faire
pour communiquer dans ce cas avec le pc directement pour utiliser le
proxy correctement? (sur le navigateur web, lorsque je mets le serveur
sur le port 8888, j'ai une page qui me dit que Abrowser (le navigateur)
ne peut réussir, et lorsque je mets le serveur sur le port 80 - car non
bloqué par LE ROUTEUR-, j'ai une page du firewall du FAI m'indiquant que
je tente une connexion vers un 'proxy server').
Merci d'avance.
Libere,
Dafp.
ps: tout les tests ont été réalisés en passant par la configuration
manuel du proxy du navigateur.
ps: est-ce que le navigateur, avec une adresse ip-local ira dirrectement
voir ce dernier? - cela dépend de la stratégie de route de
l'ordinateur, on est d'accord?
# resumons pour comprendre
Posté par NeoX . Évalué à 2.
dans ta configuration, pour que ca marche il faudrait :
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
Oui
c'est ça. Mais j'ai testé ça hier soir sur le pc d'un ami (dans le
réseau local), j'ai configuré le proxy sur le navigateur, et j'avais le
droit à un message de la part du firewal qui bloquait et qui disait que
je tentais d'accéder à la page avec un 'proxy server'. Et ça il aime pas
apparement.
Sauf que théoriquement il n'y a rien qui devrait permettre de savoir ça?
Normalement je suis censé communiqué directement avec le proxy (ma
machine qui fait tourner tinyproxy) et tout se fait discretement, non?
[^] # Re: resumons pour comprendre
Posté par NeoX . Évalué à 2.
pour la configuration du proxy sur son PC, j'imagine que tu as mis ton adresse IP locale
verifie deja que le trafic demandé par ton ami passe bien par ton PC.
wireshark, en ligne de commande par exemple devrait t'afficher des paquets en provenance de son PC.
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 1.
Alors,
je ne sais pas si c'est moi qui configure mal wireshark, mais lors de
l'analyse sur eth0, je reçois rien de la part de l'autre ordinateur :
que ça soit les tentatives de connexion au proxy tinyproxy, les lectures
de pages http sur apache2, ou des ping envoyés.
Pourtant si je fais un filtre : ip.dst == (ipv4 de l'autre pc qui veut
se connecter au proxy) - en pingant, j'ai bien la liste des paquets
envoyés.
Mais si je fais un filtre : ip.src == (ipv4 de l'autre pc qui veut se
connecter au proxy), je n'ai absolument rien.
Merci.
[^] # Re: resumons pour comprendre
Posté par NeoX . Évalué à 2.
et si tu filtres avec ip.src = celle de l'autre PC et que c'est lui qui te ping, tu vois des trucs passer ?
si oui, alors il te faut verifier que les adresses IP soient dans le meme sous reseau
des fois que l'université distribue des IPs dans des ranges séparées, et que la communication entre les machines passent forcement par leur routeur.
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 1.
Non
je ne vois rien en mettant dans le filtre : ip.src = celle de l'autre
pc qui me ping.
Non on n'est pas dans le même sous-réseau, mon pc est en 192.168.28.x et
le siens en 192.168.27.x. Et moi mon gateway est le 192.168.28.254 et
la route passe par là - je pense que le siens est le 192.168.27.254.
Quelqu'un m'a parlé de ça quand
j'avais des problèmes de routage avec openvpn.
Mais pourtant je reçois le ping, car son ordinateur dit bien qu'il les
reçoit.
Ah ça serait donc le routeur qui n'indique pas qui envoie les paquets
ICMP.
Alors comment tu expliques que je puisse faire du ssh depuis l'autre PC
vers mon PC - le routeur encore?
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
-bon
je ne sais pas pourquoi je n'arrive pas à modifier mon message.
Je vois que j'envoie quelques paquets ICMP - comment ça se fait?, ce
sont quelques adresses local mais aussi adresses public (normalement je
ne peux pas recevoir de paquets de la part des autres ne se trouvant pas
dans le même réseau que moi - pour ICMP; si?).
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
J'ai
modifié le filtre : ip.addr == mon_ip && ip.proto == ICMP; et
je reçoit bien les paquets - va savoir pourquoi, mais l'autre jour, ça
ne m'affichait rien (j'ai changé ip.src par ip.addr).
Donc rien me dit que ça passe forcement par le routeur - comment je
pourrai en être sûr?
J'ai fais un traceroute vers l'autre pc, et je n'ai aucune information
(que des ****) - pourquoi?
[^] # Re: resumons pour comprendre
Posté par NeoX . Évalué à 2. Dernière modification le 24 mai 2013 à 08:03.
soit 2 PCs, dans 2 reseaux differents
toi dans 192.168.27.X/255.255.255.0
lui dans 192.168.28.Y/255.255.255.0
avec deux passerelles differentes
la communication entre vos PC passe donc par le routeur de la residence ou de l'université.
ce routeur autorise ou non certains ports, certains protocoles.
ainsi il interdit les pings, autorise le ssh, filtre les demandent à des proxy
c'est pour cela que :
- tu ne vois pas les ping venant de l'autre PC (filtrage ip.src avec l'ip du PC distant)
- tu ne vois pas les demandes du PC vers ton proxy car ca passe d'abord par le routeur qui l'arrete
pour schematiser tu as
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
Oui
mais théoriquement ce routeur (en regardant avec nmap) ne laisse passer
que le port 80 et 443. Donc comment ça se fait que je peux faire du
ssh?
Et comme j'ai dis dans le post précédent, finalement j'arrive à voir les
paquets reçu de l'autre ordinateur, j'ai bien son adresse ip en src (va
savoir pourquoi mais quand je mets: ip.src ça marche pas) mais je ne
sais pas si FORCEMENT ça passe par le routeur (car avec traceroute je
n'ai aucune info).
Je n'ai pas réessayer de voir si je recevais la demande de connexion au
proxy, mais c'est théoriquement sûr que je ne reçois rien, vu que sur le
navigateur, le firewall bloque en mettant un message personnalisé.
Donc dans ce cas comment faire pour que le routeur ne sache pas du tout
ce que l'on veut faire, mais laisse passer tout de même?
Moi ce qui m'interesserai en priorité, c'est proposer mes services en
étant proxy.
[^] # Re: resumons pour comprendre
Posté par NeoX . Évalué à 2.
le nmap tu le fais sur le routeur, ou sur un IP externe ?
car le routeur peut tres bien refuser les connexions entrantes sur 22, 8080, etc
tout en acceptant de laisser passer les connexions vers les autres sur ces ports là.
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
En interne - et en externe ça doit être pareil (ça peut être différent?).
Vers quoi me proposezvous de regarder pour essayer de résoudre mon affaire et permettre un service proxy pour le réseau local?
[^] # Re: resumons pour comprendre
Posté par NeoX . Évalué à 2.
si le ssh entre les 2 PCs fonctionnent, il reste le tunnel ssh avec une configuration du proxy au travers du tunnel.
ton proxy ecoute sur 127.0.0.1:8080
le PC de ton pote fait un tunnel ssh avec
ssh -L8888:127.0.0.1:8080 sonuser@tamachineil configure son proxy comme etant 127.0.0.1:8888 (soit lui meme puisque c'est le tunnel ouvert juste avant)
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
Ah pas mal. Je savais qu'on pouvait faire ce genre de choses (tunnel ssh -plus ou moins) mais je ne savais ni comment faire, ni comment ça marchait.
Dans la théorie ça devrait marcher, je ne vois pas autrement, et c'est vraiment une jolie méthode.
Encore beaucoup à apprendre du coté réseau.
Merci déjà pour toutes les réponses apporter, je mettrai au courant dès que j'essaierai - mardi ou mercredi 28-29.
[^] # Re: resumons pour comprendre
Posté par dafp . Évalué à 0.
Bon finalement il n'y aura pas de test cette année.
J'ai l'intention de faire ce que je voulais, l'année prochaine.
Théoriquement ça devrai marcher, donc j'ai confiance.
Merci encore.
# Au passage...
Posté par Framasky (site web personnel) . Évalué à 2.
C'est pas un FAI que tu as manifestement, puisque tu ne peux pas accéder à tout Internet :) plutôt un FAPI (Fournisseur d'Accès Partiel à Internet — je viens de l'inventer).
Par curiosité, tu payes combien pour ce service ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Au passage...
Posté par dafp . Évalué à 1.
Un super FAPI comme tu le dis.
Non, non, je ne paie rien, c'est le FAI de la résidennce.
# OVH non ? :)
Posté par mattdaigre . Évalué à 0.
Aaaha, ça, ça sent le fournisseur OVH :) J'ai eu des centaines de fois ce problème avec la société OVH, société du ch'Nord. Mais ca s'améliore de jours en jours !
Designer du site http://www.compta-clementine.fr/
[^] # Re: OVH non ? :)
Posté par dafp . Évalué à 1.
Non, je l'ai dis au premier post : RENATER (résidence universitaire).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.