NoSpam a écrit :
>
> Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
>>> nat et filter
>> D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
> Tout comme iptables et tcpdump, les paquets
Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :
NoSpam a écrit :
Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
nat et filter
D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
Tout comme iptables et tcpdump, les paquets sont capturés dès leur
NoSpam a écrit :
> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
> nat et filter
D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
JB
Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
nat et filter
Le 03/07/2023 à 15:00, BERTRAND Joël a écrit :
Thomas Trupel a écrit :
C'est un comportement normal à mes yeux.
L'ajout d'une règle avec la target TRACE devrait te confirmer que les
paquets sont bloqués par
Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
>
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.
J'obtiens ceci :
2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE:
raw:PREROUTING:policy:2
Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
>
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.
Dans le cas de SIP, ils sont tout de même récupérés par sngrep :
[ ] 359 INVITE 100@1.1.1.1
C'est un comportement normal à mes yeux.
L'ajout d'une règle avec la target TRACE devrait te confirmer que les
paquets sont bloqués par le firewall.
|Cordialement, Thomas|
On 7/3/23 14:14, BERTRAND Joël wrote:
C'est même pire que ça !
Si je fais un nmap depuis l'extérieur sur le serveur
C'est même pire que ça !
Si je fais un nmap depuis l'extérieur sur le serveur en question,
j'obtiens bien :
legendre# nmap 192.168.15.18
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00078s latency).
Not shown: 987 filtered tcp
Bonjour Joël,
As-tu essayé d'approfondir l'analyse avec la target TRACE ?
|iptables -t raw -A PREROUTING -p udp --dport 5060 -j TRACE Par
ailleurs, tcpdump semble indiquer que le serveur reçoit un paquet sur le
port TCP/5060 et non UDP/5060. Cordialement, Thomas |
On 7/3/23 12:41, BERTRAND
Je l'ai...
Il fallait mettre l'IP du serveur dans contact.
Je pense que la doc d'asterisk est parfaite pour quelqu'un qui sait déjà
exactement de quoi il retourne, mais pour quelqu'un qui en est à sa
première installation, c'est un peu galère. Je vais essayer de rédiger
quelque chose pour les
Le 03/07/2023 à 13:44, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 03/07/2023 à 12:57, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
NoSpam a écrit :
Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
Si c'est le cas, cela veut
NoSpam a écrit :
>
> Le 03/07/2023 à 12:57, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
NoSpam a écrit :
> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
> Si c'est le cas, cela veut dire qu'asterisk ne sait
Aussi, pjsip list transports
Le 03/07/2023 à 13:09, NoSpam a écrit :
Le 03/07/2023 à 12:57, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
NoSpam a écrit :
Stop: n'as tu pas dit que les postes en interne arrivent à
s'appeler ?
Si c'est le cas, cela
Le 03/07/2023 à 12:57, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
NoSpam a écrit :
Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
l'appel.
34. No
NoSpam a écrit :
>
> Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
>>> Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
>>> l'appel.
>>>
>>> 34. No circuit/channel available
>>>
Bonjour à tous,
Je suis en train de configurer (péniblement) un serveur asterisk qui
est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce
serveur, protégé par un firewall iptables et fail2ban. Il s'agit
d'iptables et non d'iptables-legacy.
Cette
Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
NoSpam a écrit :
Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
l'appel.
34. No circuit/channel available
Renvois STP le context internal
Je
NoSpam a écrit :
> Je me suis mal exprimé: le SPA arrive bien à appeler les autres postes
> ou l'écho test d'Asterisk (extension 600 par défaut si activer) ?
>
> Si oui, le problème est au niveau d'asterisk, vois mon dernier courriel.
Il n'y a que des SPA et ils peuvent tous s'appeler
NoSpam a écrit :
> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
> Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
> l'appel.
>
> 34. No circuit/channel available
>
> Renvois STP le context internal
Je réponds à toutes les questions dans le même
Je me suis mal exprimé: le SPA arrive bien à appeler les autres postes
ou l'écho test d'Asterisk (extension 600 par défaut si activer) ?
Si oui, le problème est au niveau d'asterisk, vois mon dernier courriel.
Le 03/07/2023 à 11:54, BERTRAND Joël a écrit :
NoSpam a écrit :
Ton asterisk
NoSpam a écrit :
> Ton asterisk (192.168.1.1) qui répond 503 au SPA
>
> Il faudrait la config complète du SPA
J'ai bien une sauvegarde de la configuration, mais ce n'est pas un
fichier texte :
hilbert:[~] > file SPA112_1.4.1.cfg
SPA112_1.4.1.cfg: dBase III DBT, version number 0
Poste également la sortie cli de
pjsip show endpoint SBSR
ainsi que la config complète PJSIP de ce dernier.
Le 03/07/2023 à 11:21, BERTRAND Joël a écrit :
NoSpam a écrit :
On peut avoir les logs "lisibles", je me demande si ce n'est pas le SPA
qui envoit cette erreur ...
On va réessayer.
NoSpam a écrit :
>> Je ne saisis pas comment ces paquets arrivent à passer le firewall.
> Ce sont les attaques dont je parlais précédemment. Il semble qu'il y ai
> un trou dans le FW. Y'a pas du nat sur le Cisco pour le wan => lan ?
Le serveur est en DMZ donc récupère tout ce qui
Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
l'appel.
34. No circuit/channel available
Renvois STP le context internal
Le 03/07/2023 à 11:35, NoSpam a écrit :
Le 03/07/2023 à 11:21, BERTRAND
Le 03/07/2023 à 11:21, BERTRAND Joël a écrit :
NoSpam a écrit :
On peut avoir les logs "lisibles", je me demande si ce n'est pas le SPA
qui envoit cette erreur ...
On va réessayer.
Bien plus clair :)
[...]
2023/07/03 11:16:49.366603 192.168.1.1:5060 -> 192.168.10.253:5060
SIP/2.0 503
Le 03/07/2023 à 11:12, BERTRAND Joël a écrit :
NoSpam a écrit :
Ton problème: error 503 Service Unavailable
Es tu sûr que le service est fonctionnel ?! Es tu sûr de la qualité de
ton lien ? Peux tu basculer en UDP pour tester ?
Le serveur en face ne répond pas en UDP. La réponse est
NoSpam a écrit :
> On peut avoir les logs "lisibles", je me demande si ce n'est pas le SPA
> qui envoit cette erreur ...
On va réessayer.
2023/07/03 11:16:49.319643 192.168.10.253:5060 -> 192.168.1.1:5060
INVITE sip:0052@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP
NoSpam a écrit :
> Ton problème: error 503 Service Unavailable
>
> Es tu sûr que le service est fonctionnel ?! Es tu sûr de la qualité de
> ton lien ? Peux tu basculer en UDP pour tester ?
Le serveur en face ne répond pas en UDP. La réponse est donc non.
Un point me chagrine. À
On peut avoir les logs "lisibles", je me demande si ce n'est pas le SPA
qui envoit cette erreur ...
Le 03/07/2023 à 10:50, NoSpam a écrit :
Ton problème: error 503 Service Unavailable
Es tu sûr que le service est fonctionnel ?! Es tu sûr de la qualité de
ton lien ? Peux tu basculer en UDP
Ton problème: error 503 Service Unavailable
Es tu sûr que le service est fonctionnel ?! Es tu sûr de la qualité de
ton lien ? Peux tu basculer en UDP pour tester ?
Il faudrait voir avec Sewan le pourquoi de la réponse. Lié au problème
d'UTF8 car ton prénom est devenu Jool ... ?
Le
NoSpam a écrit :
>> rayleigh*CLI> core set verbose 3
>> Console verbose was OFF and is now 3.
>> [Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
>> CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
>> characters which were replaced
>> [Jul 2 23:11:18]
Le 02/07/2023 à 23:17, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 02/07/2023 à 19:36, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
[...]
- tous les appels sortants échouent lamentablement ;
Poste les logs. En cli, core set verbose 3 puis passe
32 matches
Mail list logo
