Re: [FRnOG] [TECH] Impédance ligne ana Pologne
Bonjour, Au vu de la description du problème, pour de l'analogique, je m'orienterais sur des tonalités mal détectées par le PABX ( les tonalités d'occupation, déconnexion, sonnerie en cours..), dont les valeurs peuvent varier selon les pays. J'ai déjà eu des galères de ce type, plutôt sur des boitiers FXS=IP, et j'avais dû modifier ces valeurs, ou bien tout simplement choisir le bon pays dans la partie configuration du port FXS. Exemple de tonalité qui diffère selon les pays: https://supportforums.cisco.com/discussion/11817151/spa-3201-disconnect-tone-wav-file-and-tone-script En espérant que ca te donne des pistes pour résoudre le problème. Denis Le 3 mars 2015 14:04, David Ponzone david.ponz...@gmail.com a écrit : Le monde de l’analogique est loin d’être simple (ground-start, loop-start, etc…). J’ai cependant du mal à croire que la Pologne soit sur un standard très différent de nous, étant donné que leur réseau repose sur les mêmes équipements Siemens/Alcatel/Ericsson qu’Orange et qu’Orange est actionnaire de Poland Telecom à plus de 50%. Il y a des petites subtilités, donc tu devrais plutôt poser la question à Aastra…ahem..pardon…Mitel, car j’imagine que le 5000 est distribué en Pologne. Il y a peut-être une autre version de la carte LR. Le 3 mars 2015 à 13:40, Thomas Frezouls tfrezo...@azatelecom.com a écrit : Salut à tous, La question du jour : Un PABX branché en Pologne sur une ligne analogique ne fonctionne pas comme il faut (problème de détection de décroché, et autres bugs dans le genre). Tout fonctionnait bien sur ligne ana en France. Je soupçonne un différence de tension, impédance ou autre sur la ligne. (la pabx est un Aastra 5000) Quelqu’un aurait une idée ? Cordialement, Thomas Frezouls http://www.azatelecom.com/lib/img/signature_mail_logo.png tel fax email 01 83 62 40 39 01 83 62 40 40 tfrezo...@azatelecom.com http://www.azatelecom.fr/lib/img/signature_mail_trait.png Provider National SDSL et Fibre Optique Solutions d’entreprises --- 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/
Re: [FRnOG] [TECH] Appliance de sécurité reverse proxy SSL, Load Balancing et IPS
Bonjour, Les solutions de F5 (Big IP) ou Citrix (Netscaler) sont très répandues. Cela fait d'ailleurs bien + que simple Reverse-Proxy+Offloading SSL+inspection. On peut faire plein de choses avec et s'adapter à tous les environnements, même complexes. Ça existe en boitier ou en VM. De mémoire; F5 reste très cher, et Citrix est plus compétitif avec le Netscaler qui est quand même un très bon produit. Par contre, je pense que ça sera sur une tranche tarifaire au dessus de Fortinet. Le 30 avril 2015 12:09, Richard Paré richard.pare...@gmail.com a écrit : Bonjour, Je cherche un appliance de sécurité pour protéger un site Web de la manière suivante : - Le site Web fonctionne en HTTP - L'appliance de sécurité fait office de reverse Proxy avec d'un côté, des communications chiffrées HTTPS avec les clients et de l'autre des communications en clair HTTP avec le serveur Web - Une inspection de paquets est effectuée et des blocages ont lieux sur le trafic suspect (IPS) J'ai essayé d'utiliser un Stormshield mais sans succès. Leur proxy SSL est plutôt fait pour déchiffrer et rechiffrer les communications SSL. Avez vous une suggestion ? (mis à part un Apache avec mod_security ou autre). Merci. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Équipement 4g-data/voix/sms to IP?
Bonjour, Je cherche un équipement qui aurait les fonctionnalités suivantes, pour exploiter au maximum un ou plusieurs abonnements mobile 4g: * possibilité de fonctionnement en routeur 4G pour la data * possibilité d'utilisation en gateway SMS (idéalement avec une api webservices simple pour l'envoi de messages, et qui saurait contacter une api webservices sur le lan pour router les messages reçus) * avec la possibilité de traiter des appels voix, avec passage en SIP/RTP coté LAN * éventuellement multi-sim * Qui ne prenne pas trop de place et ne fasse pas trop de bruit si possible * Avec interfaces LAN ethernet et wifi (les 2 ou bien au choix) * si on pouvait coller une VIP VRRP sur la conf IP ça serait encore mieux Voila pour la liste au Père Noel, connaissez vous des équipements qui feraient ca ? ou une partie du job ? Sinon, avez vous des idées pour le faire soi-même sous linux (en ajoutant des cartes ou des peripheriques USB) ? Autant pour la partie data, je vois très bien comment faire avec un dongle usb chinois quelconque qui sera reconnu comme un modem, autant pour la partie voix, beaucoup moins. Par ailleurs, je suis bien conscient que, avec l'utilisation d'une seule sim, le débit data risque de prendre cher pendant l'appel voix (d'ailleurs c'est toujours d'actualité de nos jours que le device bascule en 3G pour effectuer un appel voix ?). Si c'est bien averé, dans le cas d'une utilisation mono-sim, le data serait utilisée plutot en secours d'une autre connexion. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Bonjour, On peut quand même voir le FQDN contacté dans la requête CONNECT envoyée au proxy, tu peux te baser la dessus. Une solution courante consiste à utiliser du filtrage d'URL par catégories: * tu bloques bien sur la catégorie contenant les VPNs ou proxys distants, pour les services de VPN connus. * ensuite il faut bloquer tout ce qui n'est pas catégorisé, ce qui permet de ne pas autoriser le vpn ssl "maison" qu'un de tes utilisateurs aurait monté sur son serveur dédié ou à la maison. Par contre, du coup, ça oblige à gérer les autorisations de sites non catégorisés. C'est consommateur en temps et cela peut être gênant pour les utilisateurs. L'analyse des logs est plus compliquée à faire et il va être difficile de dissocier un gros téléchargement qui a pris du temps et un tunnel à partir de la durée de connexion ou du nombre d'octets transférés. Le 8 mars 2016 à 10:44, Jocelyn Lagarennea écrit : > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais ce > n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" et > de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple > gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner > cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, > -- > Jocelyn Lagarenne > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Occupation vers notre tranche SDA OBS depuis mobiles SFR
Bonjour, Depuis ce matin (à priori), tous les numéros de notre tranche SDA sont injoignables depuis des mobiles SFR (l'appel est raccroché immédiatement). Aucun soucis n'est détecté depuis les autres opérateurs. Ces numéros arrivent sur des T2 OBS. Le support front OBS a du mal à comprendre le problème et nous dit que les appelants doivent ouvrir des tickets chez SFR: comme si on allait demander aux clients de contacter leur support grand public pour ouvrir des tickets ! Nous ne sommes pas clients SFR, sauriez vous comment faire dans ces situations (hormis harceler OBS) ? Merci par avance, Denis --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Occupation vers notre tranche SDA OBS depuis mobiles SFR
Il n'y a pas eu de portabilité, les SDA sont chez OBS depuis la nuit des temps à priori ! :) Visiblement l'incident est aussi depuis les lignes fixes SFR. Leur service client annonce un incident global Ile de France sur leur numéro service client pro fixe mais pas sur celui mobile... Donc on ne sait pas si c'est lié. Bref merci pour l'info on lache rien avec OBS et on leur donne des traces, même si, des traces d'appels qui n'arrivent pas, c'est compliqué. Le 13 mai 2016 à 11:51, sofiane JALID <sofiane.ja...@gmail.com> a écrit : > Les ndi routés sur du full isdn ou du isdn ip. > En d'autres termes les numeros appartiennent à orange ou viennent il d'un > autre OPA exemple sfr? > > Les numeros sur l'apnf sont sur le prefixe orange... y'a t'il eu une porta > faite oû en cours vers sfr ? > > Il faut ouvrir un ticket aupres de la cellule de bron afin qu'il corrige > le pb si tu n'est pas operateur il faut des timestamp (horodatage verbeux) > et tu remontes cela à orange et il se debrouille en ouvrant un ticket sur > l'ihm de sfr. > > My 2 cents > Le 13 mai 2016 11:19, "Denis VINCIGUERRA" <de...@vinciguerra.fr> a écrit : > >> Bonjour, >> >> Depuis ce matin (à priori), tous les numéros de notre tranche SDA sont >> injoignables depuis des mobiles SFR (l'appel est raccroché immédiatement). >> Aucun soucis n'est détecté depuis les autres opérateurs. >> >> Ces numéros arrivent sur des T2 OBS. Le support front OBS a du mal à >> comprendre le problème et nous dit que les appelants doivent ouvrir des >> tickets chez SFR: comme si on allait demander aux clients de contacter >> leur >> support grand public pour ouvrir des tickets ! >> >> Nous ne sommes pas clients SFR, sauriez vous comment faire dans ces >> situations (hormis harceler OBS) ? >> >> Merci par avance, >> Denis >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Pertes de paquets en UDP depuis SFR/NC vers ONLINE-DC3 depuis 1 semaine
Bonjour, Depuis 1 semaine (plus précisément depuis le 26/01 entre 22h et 0h), j'ai remarqué des gros problèmes entre mon bureau (connexion SFR thd) et l’hébergeur ONLINE, et ce toute la journée et toute la nuit. En faisant divers tests, j'ai pu remarquer que seul le trafic UDP était impacté dans le sens SFR => ONLINE. Pas de chance, j'utilise UDP pour monter un VPN entre les 2. J'ai remarqué un problème similaire sur des cameras "cloud" qui montent un VPN sur UDP vers l'infra du constructeur qui est... chez Online également. Après avoir envoyé différents résultats de tests à Online, ils me disent que le problème a été remonté par plusieurs clients mais est chez SFR/NC et me renvoient vers leur support, sans vouloir donner + de précisions, malgré avoir insisté. J'ai contacté le support SFR mais j'attends encore leur retour et je désespère d'avance face au fait qu'on va me demander de rebooter mon ordinateur, de faire un reset to factory defaults de la box, etc etc... Quelqu'un de la ML serait chez SFR/NC (ou chez ONLINE d'ailleurs) et pourrait regarder ? Sinon que me conseillez-vous de faire dans ce genre de cas (hormis tunnelliser sur TCP en attendant des jours meilleurs :) ) Voici ci joint des MTR d'un site à l'autre, en ICMP et UDP. Si je ne me trompe pas, on voit les pertes de paquet au niveau de entre 172.19.132.118 (wtf?) et numericable.bb1.dc3.poneytelecom.eu dans le sens SFR => ONLINE, et seulement en UDP. SFR -> ONLINE: aucune probleme sur ICMP mais 20% de pertes sur UDP # mtr -c 50 -s 1300 --report 212.83.x.x # IP Online HOST: firewall-bureau Loss% Snt Last Avg Best Wrst StDev 1.|-- box0.0%500.4 0.4 0.3 0.4 0.0 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 8.0 6.7 11.3 1.0 4.|-- 172.19.132.118 0.0%50 11.7 11.3 8.3 15.1 1.5 5.|-- numericable.bb1.dc3.poney 0.0%509.9 11.3 9.9 16.7 1.1 6.|-- 45x-s43-1-a9k1.dc3.poneyt 0.0%50 14.6 13.3 10.2 19.7 2.4 7.|-- 212.83.x.x 0.0%50 11.3 10.7 9.5 11.6 0.6 # mtr -c 50 -s 1300 -u --report 212.83.x.x # IP Online HOST: firewall-bureau Loss% Snt Last Avg Best Wrst StDev 1.|-- box0.0%500.4 0.4 0.4 0.9 0.1 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 7.9 6.7 9.8 0.8 * 4.|-- 172.19.132.118 0.0%50 12.3 11.5 9.1 17.8 1.6* * 5.|-- numericable.bb1.dc3.poney 16.0%50 10.4 11.3 10.0 15.3 1.0* 6.|-- 45x-s43-1-a9k1.dc3.poneyt 18.0%50 15.8 14.0 10.3 33.9 4.4 7.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 ONLINE => SFR: quasiment aucune perte sur ICMP et quasiment aucune perte sur UDP # mtr -c 50 -s 1300 --report 109.12.x.x # IP SFR HOST: serveur Loss% Snt Last Avg Best Wrst StDev 1.|-- firewall-hebergeur 0.0%500.1 0.1 0.1 0.3 0.0 2.|-- 62-210-188-1.rev.poneytel 0.0%501.3 2.5 0.7 7.2 1.7 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.7 0.8 0.7 2.0 0.3 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.3 0.4 0.3 1.3 0.1 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.6 0.7 0.6 2.2 0.3 6.|-- sfr.std-1.rt.hopus.net 0.0%504.8 2.9 1.0 5.0 1.2 7.|-- 226.122.3.109.rev.sfr.net 0.0%505.2 5.4 3.5 7.6 1.1 8.|-- 241.122.3.109.rev.sfr.net 0.0%505.7 4.7 3.0 6.7 1.2 9.|-- 193.224.65.86.rev.sfr.net 0.0%503.3 3.4 3.1 4.6 0.2 10.|-- 195-132-10-228.rev.numeri 2.0%502.9 2.9 2.8 3.1 0.0 11.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 # mtr -c 50 -s 1300 -u --report 109.12.x.x # IP SFR HOST: serveur Loss% Snt Last Avg Best Wrst StDev 1.|-- firewall-hebergeur 0.0%500.2 0.1 0.1 0.2 0.0 2.|-- 62-210-188-1.rev.poneytel 0.0%505.0 3.4 0.7 15.3 3.2 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.8 0.9 0.7 2.2 0.4 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.4 0.4 0.3 0.7 0.1 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.8 0.8 0.6 2.9 0.5 6.|-- sfr.std-1.rt.hopus.net 0.0%503.0 2.9 0.9 5.2 1.2 7.|-- 226.122.3.109.rev.sfr.net 0.0%503.7 5.3 3.3 7.2 1.1 8.|-- 241.122.3.109.rev.sfr.net 0.0%504.7 4.8 2.8 6.8 1.2 9.|-- 193.224.65.86.rev.sfr.net 0.0%503.6 3.4 3.2 5.4 0.3 10.|-- 195-132-10-228.rev.numeri 2.0%503.0 2.9 2.8 3.0 0.1 11.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 --- Liste de diffusion du FRnOG http://www.frnog.org/