Re: [FRnOG] [ALERT] FREE HS? (78)

2015-01-28 Par sujet Benjamin BILLON
Constaté aussi à Saint Quentin ...

Un moyen de forcer le reboot des freebox, pour les mettre à jour suite à
Ghost?

--
Benjamin

Le 28 janvier 2015 11:54, Mr CIANFARANI Matthieu 
cianfaranimatth...@gmail.com a écrit :

 Bonjour,

 http://www.free-reseau.fr/ le constate aussi

 Matthieu. http://www.viadeo.com/fr/profile/matthieu.cianfarani

 Support a French Startup - *LINKIO* - on KickStarter : goo.gl/mTz9hp
 Linkio : goo.gl/5bzjt1
 http://www.viadeo.com/fr/profile/matthieu.cianfarani
 http://www.viadeo.com/fr/profile/matthieu.cianfarani

 Le 28 janvi
 er 2015 11:46, Sylvain Busson sbu12...@gmail.com a écrit :

  Hello,
  Depuis 10 minutes j'ai une dizaines de freebox qui sont HS (au moins dans
  le 78 Saint Quentin en Yvelines)
  D'autres constate le souci?
  SBU
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet Eugène Ngontang
Bonjour les experts,

En fait dans mon taf je travail avec le web proxy squid, et même si je
parviens techniquement à manipuler l'outil, en cas de souci, erreur ou
autres j'ai des questions qui me viennent très souvent à l'esprit, sur
l'aspect purement fonctionnel des proxies.

Autant je comprends le firewalling, autant le proxying m'emmène souvent à
de petites remises en question.

Je ne demande à comprendre l'architecture des proxies, mais à comprendre le
fonctionnement au sens protocolaire je dirais, même si je sais que le
proxy n'est pas un protocole.

Ce que j'aimerais savoir :
 - Peut-on se passer (le client, disons un wget par exemple) du proxy si
l'on connais l'url de destination?
 - le proxy est censé masquer l'existence du client sur le réseau pour le
serveur, seulement dans certains cas, même si une ACL est créée sur le
proxy pour autoriser l'url en question, ce dernier ne parvient pas à
établir la connexion pour le client, qui tombe en timeout. Et une tentative
de connexion directe sans passer par le proxy marche. Dans ce cas qu'est ce
qu'il ne fallait pas ou qu'est ce qu'il faut faire?
- le point précédent m'emmène à poser la question de savoir si le serveur
auquel on tente de se connecter doit être configuré pour ou pour ne pas
recevoir des requêtes d'un proxy???
- On peut partir sur le cas concret qui m'a poussé à créer ce thread :

  * J'ai autorisé une URL sur mon proxy pour un flux https, verx un
serveur
  * En testant la connexion avec un wget sur l'url, après avoir
setté la variable https_proxy depuisma console, je ne réussi. Le client
tente indéfiniment et tombe en erreur, typiquement avec une trace du genre :
  wget https://server_url
--2015-01-28 08:37:20--  https://server_url
Resolving proxy_fqdn... proxy_ip
Connecting to proxy_fqdn|proxy_ip|:8000... connected.
Proxy tunneling failed: Service UnavailableUnable to establish SSL
connection.

* En unsettant le proxy et en réessayant j'y arrive bien. Alors
je vais sur mon proxy en question et refais la même requête, et je me rend
compte qu'effectivement le proxy n'est pas autorisé à parler en SSL au
serveur en question, sur les firewall, et je déduis que c'est là le souci.
  - D'après ce dernier exemple, cela veut-il bien dire que le fait de
passer par un proxy ou non est un choix qui n'est pas obligatoire, et que
tout dépend des accès autorisés pour le proxy en question?
  - Elles pilulent sur la toile, mais je suis preneur de toute bonne doc
couvrant en détail les différentes architectures et façon de mettre en
place les proxies.

Merci pour votre attention.

Cordialement,
Eugène NG

-- 
ngont...@epitech.net
sympav...@gmail.com

*Aux hommes il faut un chef, et au*

* chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te
voit on te juge!*

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet David Ponzone
 On peut aussi n'autoriser que le proxy à sortir et du coup si tu modifies tu 
 peux pas faire grand chose ;-)
 

Barbare :)

 En dehors de ça, on peut toujours contourner la configuration de
 l’application (même sous Windows, Chrome n’utilise pas la
 configuration de proxy d’IE).
 
 
 Pas d'accord sur ce point, voilà ce que j'ai dans les propriétés avancées de 
 Chrome
 
 Google Chrome utilise les paramètres proxy du système pour se connecter au 
 réseau.
 

Mea Culpa : c’est Firefox qui permet les 2.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet jean-yves

Le 2015-01-28 10:06, David Ponzone a écrit :

Rapidement, d’autres plus pointus que mois sur le sujet, complèteront
probablement:

Le 28 janv. 2015 à 09:13, Eugène Ngontang sympav...@gmail.com a 
écrit :



Ce que j'aimerais savoir :
- Peut-on se passer (le client, disons un wget par exemple) du proxy 
si

l'on connais l'url de destination?


Ca dépend da la personne qui gère le réseau.
Au niveau réseau (routeur), on peut forcer les clients à passer par
le proxy(+cache), sans qu’il ait le choix.
Il a rien à configurer sur son navigateur/shell.
Ca s’utilisait beaucoup à l’époque des FAI gratuits (HOL,
LibertySurf, etc…) parce que ça permettait de limiter le coût en
transit par client connecté.


On peut aussi n'autoriser que le proxy à sortir et du coup si tu 
modifies tu peux pas faire grand chose ;-)




En dehors de ça, on peut toujours contourner la configuration de
l’application (même sous Windows, Chrome n’utilise pas la
configuration de proxy d’IE).



Pas d'accord sur ce point, voilà ce que j'ai dans les propriétés 
avancées de Chrome


Google Chrome utilise les paramètres proxy du système pour se 
connecter au réseau.



Cdlt,

JYL


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [ALERT] FREE HS? (78)

2015-01-28 Par sujet Mr CIANFARANI Matthieu
Bonjour,

http://www.free-reseau.fr/ le constate aussi

Matthieu. http://www.viadeo.com/fr/profile/matthieu.cianfarani

Support a French Startup - *LINKIO* - on KickStarter : goo.gl/mTz9hp
Linkio : goo.gl/5bzjt1
http://www.viadeo.com/fr/profile/matthieu.cianfarani
http://www.viadeo.com/fr/profile/matthieu.cianfarani

Le 28 janvi
er 2015 11:46, Sylvain Busson sbu12...@gmail.com a écrit :

 Hello,
 Depuis 10 minutes j'ai une dizaines de freebox qui sont HS (au moins dans
 le 78 Saint Quentin en Yvelines)
 D'autres constate le souci?
 SBU

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet Radu-Adrian Feurdean
On Wed, Jan 28, 2015, at 09:13, Eugène Ngontang wrote:
 Ce que j'aimerais savoir :
  - Peut-on se passer (le client, disons un wget par exemple) du proxy si
 l'on connais l'url de destination?

Pour un proxy cote client, il faut de toute facon connaitre l'URL
destination. Et dans la plupart des cas, il n'y a pas vraiment de choix
laisse a l'utilisateur.

Pour un reverse proxy (cote serveur), si le backend est accessible a
tout le monde, le RP ne sert pas a grand chose (lire a rien).

  - le proxy est censé masquer l'existence du client sur le réseau pour le
 serveur, seulement dans certains cas, même si une ACL est créée sur le
 proxy pour autoriser l'url en question, ce dernier ne parvient pas à
 établir la connexion pour le client, qui tombe en timeout. Et une tentative
 de connexion directe sans passer par le proxy marche. Dans ce cas qu'est
 ce qu'il ne fallait pas ou qu'est ce qu'il faut faire?

Tu as un probleme la-bas.
- soit il s'agit d'un proxy-cache a utilisation volontaire, qui en
plus semble mal-configure.
- soit il s'agit d'un proxy obligatoire (pas d'acces a Internet pour
les clients, uniquement sur le proxy), dans quel cas tu as plusieurs
choses mal-configures.

 - le point précédent m'emmène à poser la question de savoir si le serveur
 auquel on tente de se connecter doit être configuré pour ou pour ne pas
 recevoir des requêtes d'un proxy???

Generalement, je diai que non. De toute facon, si le serveur sait que
les clients passent via un proxy, c'est que le proxy lui laisse cette
indication, generalement en ajoutant des headers dans les requetes HTTP
(pas HTTPS).

 - On peut partir sur le cas concret qui m'a poussé à créer ce thread :
   * J'ai autorisé une URL sur mon proxy pour un flux https, verx un 
 serveur
   * En testant la connexion avec un wget sur l'url, après avoir
 setté la variable https_proxy depuisma console, je ne réussi. Le client
 tente indéfiniment et tombe en erreur, typiquement avec une trace du
 genre :
   wget https://server_url
 --2015-01-28 08:37:20--  https://server_url
 Resolving proxy_fqdn... proxy_ip
 Connecting to proxy_fqdn|proxy_ip|:8000... connected.
 Proxy tunneling failed: Service UnavailableUnable to establish SSL
 connection.
 
 * En unsettant le proxy et en réessayant j'y arrive bien.

Est-ce que le proxy autorise la methode CONNECT (qui est normalement
reserve aux proxys) ?
Le HTTPS ne passe pas en clair sur les proxy, mais via CONNECT
(tunnel HTTP, vois-la comme TCP over HTTP). Pour faire passer le SSL en
clair c'est une toute autre usine a gas, associe plutot au hijacking
qu'a la securite, et qu'il fout mieux eviter (je dirai meme a tout
prix).

 Alors
 je vais sur mon proxy en question et refais la même requête, et je me
 rend
 compte qu'effectivement le proxy n'est pas autorisé à parler en SSL au
 serveur en question, sur les firewall, et je déduis que c'est là le
 souci.

Voila l'erreur.

   - D'après ce dernier exemple, cela veut-il bien dire que le fait de
 passer par un proxy ou non est un choix qui n'est pas obligatoire, et que
 tout dépend des accès autorisés pour le proxy en question?

Generalement, si. Au niveau du navigateur il y a generalement 3 options:
 - pas de proxy, connexion directe a 100% du temps
 - proxy 100% du temps
 - fichier .pac qui definit vers quels URL il faut putiliser un proxy,
 et lequel. Le fichier est interprete par les navigateurs et DOIT etre
 disponible hors proxy (generalement en HTTP).

   - Elles pilulent sur la toile, mais je suis preneur de toute bonne doc
 couvrant en détail les différentes architectures et façon de mettre en
 place les proxies.

La meilleure : ne pas mettre de proxy. Des que les clients sont un
minimum mobiles, ca devient source d'ennuis.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet David Ponzone
Rapidement, d’autres plus pointus que mois sur le sujet, complèteront 
probablement:

Le 28 janv. 2015 à 09:13, Eugène Ngontang sympav...@gmail.com a écrit :

 Ce que j'aimerais savoir :
 - Peut-on se passer (le client, disons un wget par exemple) du proxy si
 l'on connais l'url de destination?

Ca dépend da la personne qui gère le réseau.
Au niveau réseau (routeur), on peut forcer les clients à passer par le 
proxy(+cache), sans qu’il ait le choix.
Il a rien à configurer sur son navigateur/shell.
Ca s’utilisait beaucoup à l’époque des FAI gratuits (HOL, LibertySurf, etc…) 
parce que ça permettait de limiter le coût en transit par client connecté.
En dehors de ça, on peut toujours contourner la configuration de l’application 
(même sous Windows, Chrome n’utilise pas la configuration de proxy d’IE).

 - le proxy est censé masquer l'existence du client sur le réseau pour le
 serveur, seulement dans certains cas, même si une ACL est créée sur le
 proxy pour autoriser l'url en question, ce dernier ne parvient pas à
 établir la connexion pour le client, qui tombe en timeout. Et une tentative
 de connexion directe sans passer par le proxy marche. Dans ce cas qu'est ce
 qu'il ne fallait pas ou qu'est ce qu'il faut faire?

Il peut y avoir un certain nombre de choses qui peuvent conduire à ce résultat 
et il n’y a de réponse générique.

 - le point précédent m'emmène à poser la question de savoir si le serveur
 auquel on tente de se connecter doit être configuré pour ou pour ne pas
 recevoir des requêtes d'un proxy???

Le serveur peut en effet comprendre assez facilement que la requête vient d’un 
proxy, mais côté proxy, on peut se faire oublier avec le paramètre tproxy je 
crois.

 - On peut partir sur le cas concret qui m'a poussé à créer ce thread :
 
  * J'ai autorisé une URL sur mon proxy pour un flux https, verx un
 serveur
  * En testant la connexion avec un wget sur l'url, après avoir
 setté la variable https_proxy depuisma console, je ne réussi. Le client
 tente indéfiniment et tombe en erreur, typiquement avec une trace du genre :
  wget https://server_url
 --2015-01-28 08:37:20--  https://server_url
 Resolving proxy_fqdn... proxy_ip
 Connecting to proxy_fqdn|proxy_ip|:8000... connected.
 Proxy tunneling failed: Service UnavailableUnable to establish SSL
 connection.
 
* En unsettant le proxy et en réessayant j'y arrive bien. Alors
 je vais sur mon proxy en question et refais la même requête, et je me rend
 compte qu'effectivement le proxy n'est pas autorisé à parler en SSL au
 serveur en question, sur les firewall, et je déduis que c'est là le souci.
  - D'après ce dernier exemple, cela veut-il bien dire que le fait de
 passer par un proxy ou non est un choix qui n'est pas obligatoire, et que
 tout dépend des accès autorisés pour le proxy en question?
  - Elles pilulent sur la toile, mais je suis preneur de toute bonne doc
 couvrant en détail les différentes architectures et façon de mettre en
 place les proies.

Alors, HTTPS et proxy, c’est un peu compliqué, on peut facilement comprendre 
pourquoi.
En gros, la solution est la technique du Connect Tunnel:
http://wiki.squid-cache.org/Features/HTTPS

Bon courage :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [ALERT] FREE HS? (78)

2015-01-28 Par sujet Sylvain Busson
Hello,
Depuis 10 minutes j'ai une dizaines de freebox qui sont HS (au moins dans le 78 
Saint Quentin en Yvelines)
D'autres constate le souci?
SBU

---
Liste de diffusion du FRnOG
http://www.frnog.org/


RE: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

2015-01-28 Par sujet Xavier ROCA
Bonjour,

En parlant de proxy ca m'a fait pensé a la fonction Turbo d'Opera.

Pour le filtrage http via le proxy du réseau c'est raté si on reste uniquement 
sur du filtrage d'URL.

Certains on trouver comment rétablir l'ordre ?
On a des étudiants malins sur des écoles qui ont pigeonné leur prof avec Opera

Interdire les IP des serveurs proxy utilisé par Opéra pour compresser ?
Je suis preneur d'autres idées bien passantes ou d'une liste d'IP à jour.

Pas besoin de débat sur la neutralité du web ici, on n'a pas vraiment à y 
réfléchir.

Merci et bonne journée

Xavier


-Message d'origine-
De : Radu-Adrian Feurdean [mailto:fr...@radu-adrian.feurdean.net] 
Envoyé : mercredi 28 janvier 2015 12:13
À : Eugène Ngontang; frnog@frnog.org
Objet : Re: [FRnOG] [TECH]Design et aspect protocolaire des Proxies

On Wed, Jan 28, 2015, at 09:13, Eugène Ngontang wrote:
 Ce que j'aimerais savoir :
  - Peut-on se passer (le client, disons un wget par exemple) du proxy 
 si l'on connais l'url de destination?

Pour un proxy cote client, il faut de toute facon connaitre l'URL destination. 
Et dans la plupart des cas, il n'y a pas vraiment de choix laisse a 
l'utilisateur.

Pour un reverse proxy (cote serveur), si le backend est accessible a tout le 
monde, le RP ne sert pas a grand chose (lire a rien).

  - le proxy est censé masquer l'existence du client sur le réseau pour 
 le serveur, seulement dans certains cas, même si une ACL est créée sur 
 le proxy pour autoriser l'url en question, ce dernier ne parvient pas 
 à établir la connexion pour le client, qui tombe en timeout. Et une 
 tentative de connexion directe sans passer par le proxy marche. Dans 
 ce cas qu'est ce qu'il ne fallait pas ou qu'est ce qu'il faut faire?

Tu as un probleme la-bas.
- soit il s'agit d'un proxy-cache a utilisation volontaire, qui en plus 
semble mal-configure.
- soit il s'agit d'un proxy obligatoire (pas d'acces a Internet pour les 
clients, uniquement sur le proxy), dans quel cas tu as plusieurs choses 
mal-configures.

 - le point précédent m'emmène à poser la question de savoir si le 
 serveur auquel on tente de se connecter doit être configuré pour ou 
 pour ne pas recevoir des requêtes d'un proxy???

Generalement, je diai que non. De toute facon, si le serveur sait que les 
clients passent via un proxy, c'est que le proxy lui laisse cette indication, 
generalement en ajoutant des headers dans les requetes HTTP (pas HTTPS).

 - On peut partir sur le cas concret qui m'a poussé à créer ce thread :
   * J'ai autorisé une URL sur mon proxy pour un flux https, verx un 
 serveur
   * En testant la connexion avec un wget sur l'url, après 
 avoir setté la variable https_proxy depuisma console, je ne réussi. Le 
 client tente indéfiniment et tombe en erreur, typiquement avec une 
 trace du genre :
   wget https://server_url
 --2015-01-28 08:37:20--  https://server_url Resolving proxy_fqdn... 
 proxy_ip Connecting to proxy_fqdn|proxy_ip|:8000... connected.
 Proxy tunneling failed: Service UnavailableUnable to establish SSL 
 connection.
 
 * En unsettant le proxy et en réessayant j'y arrive bien.

Est-ce que le proxy autorise la methode CONNECT (qui est normalement reserve 
aux proxys) ?
Le HTTPS ne passe pas en clair sur les proxy, mais via CONNECT
(tunnel HTTP, vois-la comme TCP over HTTP). Pour faire passer le SSL en clair 
c'est une toute autre usine a gas, associe plutot au hijacking qu'a la 
securite, et qu'il fout mieux eviter (je dirai meme a tout prix).

 Alors
 je vais sur mon proxy en question et refais la même requête, et je me 
 rend compte qu'effectivement le proxy n'est pas autorisé à parler en 
 SSL au serveur en question, sur les firewall, et je déduis que c'est 
 là le souci.

Voila l'erreur.

   - D'après ce dernier exemple, cela veut-il bien dire que le fait de 
 passer par un proxy ou non est un choix qui n'est pas obligatoire, et 
 que tout dépend des accès autorisés pour le proxy en question?

Generalement, si. Au niveau du navigateur il y a generalement 3 options:
 - pas de proxy, connexion directe a 100% du temps
 - proxy 100% du temps
 - fichier .pac qui definit vers quels URL il faut putiliser un proxy,  et 
lequel. Le fichier est interprete par les navigateurs et DOIT etre  disponible 
hors proxy (generalement en HTTP).

   - Elles pilulent sur la toile, mais je suis preneur de toute bonne 
 doc couvrant en détail les différentes architectures et façon de 
 mettre en place les proxies.

La meilleure : ne pas mettre de proxy. Des que les clients sont un minimum 
mobiles, ca devient source d'ennuis.


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Problème SIP SFR ?

2015-01-28 Par sujet Sebastien Lesimple

LOL!!!
Ca a été migré chez Completel ca doit etre pour ça!
A moins que ce ne soit une bouillie a base de Cirpack?
Des vieux restes de kaptech qui traînent encore dans un coin peut etre...

Attend voir, SIP c'est pas supposé etre un protocole implémenté dans le 
style SS7?
Sig et Trans séparées = SIP et RTP séparé, avec multiples interco comme 
pour les upstream d'un AS?


Bon j’arrête de faire ma LDP ;)


Le 28/01/2015 17:14, David Ponzone a écrit :

Apparemment, SFR aurait un problème d’acheminement des appels (problème sur les 
SBC), qui impacterait certains opérateurs qui ont eu l’idée bizarre d’être 
client chez eux.

Quelqu’un a plus d’infos ?

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH] Problème SIP SFR ?

2015-01-28 Par sujet David Ponzone
Apparemment, SFR aurait un problème d’acheminement des appels (problème sur les 
SBC), qui impacterait certains opérateurs qui ont eu l’idée bizarre d’être 
client chez eux.

Quelqu’un a plus d’infos ?

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/