Le 03/01/2015 20:41, Stephane Bortzmeyer a écrit :
> Ces résolveurs ouverts sont une très mauvaise idée, ils servent
> souvent de réflecteurs pour des attaques DoS
Ces récursifs ouverts gérés et supervisés de la moins mauvaise manière
sont un compromis entre plusieurs notions dont liberté et sécu
Le 06/01/2015 15:38, Xavier Beaudouin a écrit :
> n'est-il pas possible de faire justement un howto pour ouvrir
> proprement ce genre de résolveur
Déjà fait, lien dans le message de Vincent. Je reste preneur de toute
remarque/contribution, ici ou ailleurs.
> et aussi accessoirement les "soucis"
Bonjour à tous,
Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et
j'aimerais un avis et surtout être réconforté.
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime >
16
ine la compatibilité n'est plus au RDV
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)
Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :
> Bonjour à tous,
>
> Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et
> j'aimerais un a
> - Mail original -
> De: "Michel Py"
> À: "Daniel" , "frnog"
> Envoyé: Mardi 17 Mars 2020 01:19:26
> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Je ne vois pas pourquoi. Si le VPN marche, tou
> - Mail original -
> De: "David Ponzone"
> À: "Guillaume LUCAS"
> Cc: "frnog"
> Envoyé: Mardi 17 Mars 2020 07:34:53
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans
r 127.0.0.1" ça va pas marcher. "Viens
me causer sur 192.168.0.14" non plus. Je dis la même chose que toi quand tu
écris « problème de binding ».
- Mail original -
De: "David Ponzone"
À: "Guillaume LUCAS"
Cc: "frnog"
Envoyé: Mardi 17 Mars
> - Mail original -
> De: "frnog"
> À: "frnog"
> Envoyé: Mardi 17 Mars 2020 09:23:08
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Je pense que Linphone est à mettre en cause. Le problème n'e
> - Mail original -
> De: "frnog"
> À: "frnog"
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Tu pars du principe de ta configuration. Asterisk doit connai
> - Mail original -
> De: "Oliver varenne"
> À: "frnog-tech"
> Envoyé: Mardi 17 Mars 2020 15:52:23
> Objet: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Mais tu as mis l'option force,comedia sur tes
> - Mail original -
> De: "David Ponzone"
> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et
> APRÈS de lancer Linphone ?
Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai test
- Mail original -
De: "frnog"
> Donc session timeout: Essaye en mettant session-timers=refuse dans la config
> d'un client qui génère cette erreur
J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne
fonctionne pas, ça coupe toujours après 32 secs.
---
> - Mail original -
> De: "frnog"
Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou
> autre.
Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation
foireuse et comme ç
> - Mail original -
> De: "David Ponzone"
> Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir
> le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide
> linphone à envoyer un SDP correct ?
J'essaye de dépiler mes mails dans l'ordre.
Alors ça
> - Mail original -
> De: "frnog"
> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.
---
Liste d
> - Mail original -
> De: "Oliver varenne"
> A mon avis, linphone liste les interfaces accessibles, et du coup si ton VPN
> monte apres, linphone n'utilise pas cette interface.
Yep. Mais, comme dit : durant mes tests, j'ai bien demandé à tous les
participants d'être vigilants, de bien
> - Mail original -
> De: "frnog"
> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que
> ton rtp se perd si le client envois une IP injoignable au PABX
Tout à fait, je comprends.
Je corrige un truc : le client envoie, en SDP, une IP injoignable au PABX, mais
aussi
> - Mail original -
> De: "frnog"
> Définitivement pour moi problème de NAT ou Pare-Feu
Merci pour ce diag. :)
Quand la colère va me prendre, je vais monter un VPN OpenVPN tout neuf sur
lequel je serai sûr que y'a pas d'ACL ni rien et hop hop hop. Pas envie de
démerder un Cisco ASA.
> - Mail original -
> De: "Thierry Chich"
> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN
> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup
> avec du jitsi. Le p2p, c’est bien joli, mais bon.
À mon avis, une partie du problème es
> - Mail original -
> De: "David Ponzone"
> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans
> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et
> faisant le relais RTP.
Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn e
> - Mail original -
> De: "Michel Py"
> Installer une route vers le réseau local c'est pas une solution, car tu vas
> de retrouver avec une ribambelle de 192.168.0.0.
Et il faut ajouter ces routes chez tous les clients VPN, et donc avoir des
collisions (genre si on dit à un usager avec
> - Mail original -
> De: "David Ponzone"
> Ah non, en autolearn, il est forcément dans le path RTP.
Moi je parle de ça dans le journal :
« Strict RTP learning after remote address set to: 10.30.1.4:7078
Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »
À ce mome
- Mail original -
De: "David Ponzone"
> Ah non, en autolearn, il est forcément dans le path RTP.
Attends, attends, attends.
Il se passe quoi quand l'autolearn marche que pour l'un des deux interlocuteurs
? Ça donnerait pas une conversation où un seule interlocuteur entend l'autre,
par
> - Mail original -
> De: "David Ponzone"
> > Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> Que l’IP que présente le softphone est une IP que Asterisk a dans son
> localnet.
Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone
N'EST PAS une IP que
g pour voir. J'ai déjà vu un interlocuteur envoyer
son RTP à Asterisk et pas l'autre, du coup, ça ne fonctionnait pas.
- Mail original -
De: "David Ponzone"
À: "Guillaume LUCAS"
Cc: "frnog"
Envoyé: Mardi 17 Mars 2020 20:55:48
Objet: Re: [FR
> - Mail original -
> De: "Michel Py"
> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être
> le coup de dépenser 50 balles pour essayer un téléphone de bureau qui a
> support de VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé),
> mais les Grand
Je me suis souvenu que j'avais un PFSense de test dans un coin avec un OpenVPN
déjà tout prêt.
Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation de
TUN + un même réseau pour tous les clients. Aucun pare-feu sur les clients.
Premier test : je monte ce VPN OpenVPN, je d
> - Mail original -
> De: "Denis Fondras"
pfctl -d désactive PF donc... les règles de NAT.
J'ai été trop vite… J'ai mélangé présentation du bidule et état actuel.
Donc, au début, et jusqu'à la fin de mon premier test hier soir, PF était
activé (+ règle "tout autoriser"), il y avait du N
> - Mail original -
> De: "frnog"
> Et rajoute directmedia = no
Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si
je comprends bien ?
> - Mail original -
> De: "David Ponzone"
Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre
rport.
=> use_rport=1 dans la section sip de linphonerc = pas d'amélioration.
Pour la coupure après 31/32/36 secs de conversation, j'ai (re)mis
session-timers=refuse su
> - Mail original -
> De: "David Ponzone"
> Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus
> autour de 100 et qui sont obligatoirement relayés par l’*.
Quand RTP learning fonctionne. Sinon c'est p2p, entre le softphone/SNOM et la
passerelle T2, non ?
- Mail original -
> De: "David Ponzone"
> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que
> donc le rte-proxy….:)
Si tu savais… :D
Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le
RTP learning foire ? Fin des appels ?
Parce que l
> - Mail original -
> De: "Raphael Mazelier"
> Le rtp learning c'est une invention d'asterisk j'imagine qui doit être
> une fonctionnalité qui essaie de découvrir la topologie réseau et donc
> setter les adresses ip dans le rtp.
Ouki.
> Une bonne manière de bien comprendre c'est de d
Le 17/03/2020 à 22:04, Michel Py a écrit :
Guillaume LUCAS a écrit :
C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.
Maintenant je comprends. Je ne me doutais pas que les cl
Le 17/03/2020 à 22:21, Daniel via frnog a écrit :
. tester avec csipsimple qui est très stable
Mais plus maintenu, plus dispo sur f-droid, etc.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Le 18/03/2020 à 14:06, Raphael Mazelier a écrit :
Sinon si tu peux centraliser la conf de tes linphones ca serait aussi
pour toi le meilleur, avec pareil l'option qui va bien.
Je n'ai pas compris ? Comment centralises-tu la conf' des linphones ?
---
Liste de diffusion
Le 18/03/2020 à 14:27, Guillaume LUCAS a écrit :
Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça
validera que le VPN ASA n'est pas coupable.
Je retiens :
* OpenVPN (+ garantie d'absence de filtrage et de NAT) apporte rien
par rapport à ASA pour d
Le 18/03/2020 à 21:21, Daniel via frnog a écrit :
Essaye alors Twinkle.
Je crois que ça a été fait et que ça ne fonctionnait pas.
Je parle avant nat=yes et directmedia=no, bien entendu.
Au passage, nat=yes est déprécié, mets nat=force_rport,comedia
XiVo le fait tout seul. Je dis nat=yes po
> - Mail original -
> De: "frnog"
> pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).
C'est OK.
> Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.
J'ai ni l'u
> - Mail original -
> De: "Adrien Rivas"
> Niveau réseau, l'ASA est dgw ou pas ?
Non. Il donne assez uniquement à nos réseaux. Et les routes ajoutés sur un
client VPN Linux sont de la forme "10.10.0.0/16 dev tun0".
> Les routes de VPN sont déclarées sur l'Asterisk si ASA pas dgw ?
Bonjour tout le monde,
Nous utilisons le logiciel FOG ( https://fogproject.org/ ) pour
déployer, en multicast, des images disque sur un parc informatique.
Nous avons plusieurs VLANs. Notre serveur FOG n'est pas dans le même
VLAN que les machines du parc. Sur notre routeur actuel, un HP
HSR66
Bonjour,
À l'université d'Avignon, nous recherchons une prestation d'infogérance
(télé-supervision* + télé-exploitation** + AMOA***) pour un petit MAN
(10 sites géographiques, commutateurs HP, IMC, < 10 VLANs, QinQ, RRPP,
routage BGP sur un seul site) qui existe depuis plusieurs années à
Avig
Bonsoir,
Quelles sont, en 2019, les grandes catégories de VPN multi-systèmes permettant
de connecter des utilisateurs distants faiblement technophiles et motivés [1]
au réseau d'une entité ? Évidemment, le service info n'a pas la main sur le
terminal de l'utilisateur, sinon c'est trop facile,
Bonjour,
Le 13/12/2020 à 10:18, Raphaël Jacquot a écrit :
quelqu'un aurait une idée ?
Je n'ai pas d'idée sur la session qui ne monte pas. En revanche, voici
ce que j'ai écrit, en 2014, sur ttl-security :
« Le TTL est décrémenté uniquement en cas de forward. Un routeur reçoit
un paquet, s
44 matches
Mail list logo
