Re: Trou dans un firewall (iptables nftable)
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 sont capturés dès leur > arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu > ne devrais voir aucune réponse de ton asterisk Effectivement, il n'y a aucune réponse. Merci pour tout, JB
Re: Trou dans un firewall (iptables nftable)
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 arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu ne devrais voir aucune réponse de ton asterisk
Re: Trou dans un firewall (iptables nftable)
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
Re: Trou dans un firewall (iptables nftable)
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 le firewall. J'obtiens ceci : 2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) Où voit-on que ces paquets sont bloqués ? Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
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 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) Où voit-on que ces paquets sont bloqués ? Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
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 100@1.1.1.1 1 64.31.63.27:5166 192.168.15.18:5060 CALL SETUP donc pas si bloqués que cela ;-) Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
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 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 ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 (https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udpopen domain 123/udp open ntp 1/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
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 ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udpopen domain 123/udp open ntp 1/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
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 Joël wrote: 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 machine est connectée à deux réseaux : wan0 d'un côté et lan0 de l'autre. Ce qui m'inquiète : Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060 ... 12:26:54.145136 IP patient.census.internet-measurement.com.38253 > rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options [mss 1440], length 0 Là, je ne saisis pas puisque j'ai dans le fichier /var/lib/iptables/active : *filter :INPUT DROP [28:3300] :FORWARD DROP [0:0] :OUTPUT DROP [27:3120] [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -i lan0 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A INPUT -i wan0 -p icmp -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT [0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -m state --state INVALID -j DROP [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -o lan0 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT [1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT [0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A OUTPUT -m state --state INVALID -j DROP La table mangle est utilisée pour la QoS. Comment se fait-il qu'un paquet sur le port 5
Re: Configuration asterisk
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 débutants. Merci pour tout. JB
Re: Configuration asterisk
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 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 mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) Ca c'est OK rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use 0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est également mauvais, il devrait ressembler à SBSR/sip::5070 Dans [aor] rajoute contact=sip::5070 Identify ne sert à rien puisque tu t'enregistre Règle les deux premiers problèmes, cela devrait faire avancer les choses [SBSR] type=aor contact=sip:trunk-sip@:5070 max_contacts=1 remove_existing=yes Es tu sur que trunk-sip est ton contact chez le provider ? J'ai des doutes ... au mieux c'est ton username mais en général pas besoin sip:domain:5070 doit suffire. Mets max_contacts=10 pour le moment Déjà, il y a un point que je ne saisis pas. La signalisation du trunk SIP se fait en 5070/TCP, mais les paquets RTP associés sont bien en UDP : 13:38:49.281101 IP rayleigh.systella.fr.17056 > 37.97.65.116.50458: UDP, length 172 13:38:49.286130 IP 37.97.65.116.50458 > rayleigh.systella.fr.17056: UDP, length 172 Quand je lance rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 à quoi correspond udp-transport ? À la signalisation (auquel cas on devrait être en 5070/TCP) ou aux paquets RTP ? Signalisation. Ce que je ne comprends pas c'est systella2.buroticstore.eu qui est ton hostname alors que domain devrait être celui du provider et le port celui pour joindre le provider. Remplace le contact dans [aor] par contact=sip:37.97.65.186:5070 J'ai l'impression qu'il s'agit de la signalisation mais je n'en suis pas sûr. Je vais tout de même essayer de trouver le moyen de forcer un transport en TCP sur le port 5070. Comme identifiant, le fournisseur m'a juste donné trunk-sip@domaine, rien d'autre. OK mais le @domain ne me parait pas être le bon, rectifie comme donné ci dessus A primary feature of AOR objects (Address of Record) is to tell Asterisk where an endpoint can be contacted. Without an associated AOR section, an endpoint cannot be contacted. AOR objects also store associations to mailboxes for MWI requests and other data that might relate to the whole group of contacts such as expiration and qualify settings. When Asterisk receives an inbound registration, it'll look to match against available AORs pjsip show aors te donnera plus d'infos rayleigh*CLI> pjsip show aors Aor: Contact: == Aor: 6001 1 Contact: 6001/sip:6001@192.168.10.253:5060a0a76d4acb NonQual nan Aor: 6002 1 Contact: 6002/sip:6002@192.168.10.250:50616a2a034b2c NonQual nan Aor: SBSR 1 Contact: SBSR/sip:trunk-...@systella2.buroticstore.eu 5551fa2b78 NonQual nan Objects found: 3 rayleigh*CLI> pjsip list transports Transport: == Transport: tcp-transport tcp 0 0 192.168.15.18:5060 Transport: udp-transport udp 0 0 0.0.0.0:5060 Ton asterisk écoute en tcp sur l'ip 192.168.15.18 port 5060 et sur toutes les IP locales en UDP port 5060 Ex de mon asterisk écoutant et connecté en TLS chez un provider en ipv4 Transport: transport-tls tls 0 0 0.0.0.0:5061 https://wiki.asterisk.org/wiki
Re: Configuration asterisk
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 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 mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) >>> Ca c'est OK rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use 0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 >>> udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est >>> également mauvais, il devrait ressembler à >>> >>> SBSR/sip::5070 >>> >>> Dans [aor] rajoute >>> >>> contact=sip::5070 >>> >>> Identify ne sert à rien puisque tu t'enregistre >>> >>> Règle les deux premiers problèmes, cela devrait faire avancer les choses >> [SBSR] >> type=aor >> contact=sip:trunk-sip@:5070 >> max_contacts=1 >> remove_existing=yes > > Es tu sur que trunk-sip est ton contact chez le provider ? J'ai des > doutes ... au mieux c'est ton username mais en général pas besoin > sip:domain:5070 doit suffire. Mets max_contacts=10 pour le moment Déjà, il y a un point que je ne saisis pas. La signalisation du trunk SIP se fait en 5070/TCP, mais les paquets RTP associés sont bien en UDP : 13:38:49.281101 IP rayleigh.systella.fr.17056 > 37.97.65.116.50458: UDP, length 172 13:38:49.286130 IP 37.97.65.116.50458 > rayleigh.systella.fr.17056: UDP, length 172 Quand je lance rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 à quoi correspond udp-transport ? À la signalisation (auquel cas on devrait être en 5070/TCP) ou aux paquets RTP ? J'ai l'impression qu'il s'agit de la signalisation mais je n'en suis pas sûr. Je vais tout de même essayer de trouver le moyen de forcer un transport en TCP sur le port 5070. Comme identifiant, le fournisseur m'a juste donné trunk-sip@domaine, rien d'autre. > pjsip show aors te donnera plus d'infos rayleigh*CLI> pjsip show aors Aor: Contact: == Aor: 6001 1 Contact: 6001/sip:6001@192.168.10.253:5060a0a76d4acb NonQual nan Aor: 6002 1 Contact: 6002/sip:6002@192.168.10.250:50616a2a034b2c NonQual nan Aor: SBSR 1 Contact: SBSR/sip:trunk-...@systella2.buroticstore.eu 5551fa2b78 NonQual nan Objects found: 3 rayleigh*CLI> pjsip list transports Transport: == Transport: tcp-transport tcp 0 0 192.168.15.18:5060 Transport: udp-transport udp 0 0 0.0.0.0:5060 Objects found: 2 JB
Re: Configuration asterisk
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 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 mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) Ca c'est OK rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use 0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est également mauvais, il devrait ressembler à SBSR/sip::5070 Dans [aor] rajoute contact=sip::5070 Identify ne sert à rien puisque tu t'enregistre Règle les deux premiers problèmes, cela devrait faire avancer les choses [SBSR] type=aor contact=sip:trunk-sip@:5070 max_contacts=1 remove_existing=yes Es tu sur que trunk-sip est ton contact chez le provider ? J'ai des doutes ... au mieux c'est ton username mais en général pas besoin sip:domain:5070 doit suffire. Mets max_contacts=10 pour le moment pjsip show aors te donnera plus d'infos ne change rien. J'ai toujours après un redémarrage : Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 Je vais continuer à creuser après le repas, il commence à faire faim. JKB
Re: Configuration asterisk
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 circuit/channel available Renvois STP le context internal Je réponds à toutes les questions dans le même mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) Ca c'est OK rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use 0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est également mauvais, il devrait ressembler à SBSR/sip::5070 Dans [aor] rajoute contact=sip::5070 Identify ne sert à rien puisque tu t'enregistre Règle les deux premiers problèmes, cela devrait faire avancer les choses [SBSR] type=aor contact=sip:trunk-sip@:5070 max_contacts=1 remove_existing=yes Es tu sur que trunk-sip est ton contact chez le provider ? J'ai des doutes ... au mieux c'est ton username mais en général pas besoin sip:domain:5070 doit suffire. Mets max_contacts=10 pour le moment pjsip show aors te donnera plus d'infos ne change rien. J'ai toujours après un redémarrage : Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 Je vais continuer à creuser après le repas, il commence à faire faim. JKB
Re: Configuration asterisk
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 >>> >>> Renvois STP le context internal >> Je réponds à toutes les questions dans le même mail pour qu'on s'y >> retrouve plus facilement. >> >> [internal] >> exten => 6001,1,Dial(PJSIP/6001) >> exten => 6002,1,Dial(PJSIP/6002) >> exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) > Ca c'est OK >> >> >> rayleigh*CLI> pjsip show endpoint SBSR >> ... >> Endpoint: SBSR Not in >> use 0 of inf >> OutAuth: SBSR_auth/trunk-sip >> Aor: SBSR 1 >> Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 >> NonQual nan >> Transport: udp-transport udp 0 0 0.0.0.0:5060 >> Identify: SBSR/SBSR >> Match: 37.97.65.186/32 > > udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est > également mauvais, il devrait ressembler à > > SBSR/sip::5070 > > Dans [aor] rajoute > > contact=sip::5070 > > Identify ne sert à rien puisque tu t'enregistre > > Règle les deux premiers problèmes, cela devrait faire avancer les choses [SBSR] type=aor contact=sip:trunk-sip@:5070 max_contacts=1 remove_existing=yes ne change rien. J'ai toujours après un redémarrage : Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 Je vais continuer à creuser après le repas, il commence à faire faim. JKB
Trou dans un firewall (iptables nftable)
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 machine est connectée à deux réseaux : wan0 d'un côté et lan0 de l'autre. Ce qui m'inquiète : Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060 ... 12:26:54.145136 IP patient.census.internet-measurement.com.38253 > rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options [mss 1440], length 0 Là, je ne saisis pas puisque j'ai dans le fichier /var/lib/iptables/active : *filter :INPUT DROP [28:3300] :FORWARD DROP [0:0] :OUTPUT DROP [27:3120] [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -i lan0 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A INPUT -i wan0 -p icmp -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT [0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -m state --state INVALID -j DROP [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -o lan0 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT [1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT [0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A OUTPUT -m state --state INVALID -j DROP La table mangle est utilisée pour la QoS. Comment se fait-il qu'un paquet sur le port 5060/UDP puisse être envoyé à mon serveur sans qu'il ne soit jeté ? Il n'y a pas de conntrack-sip chargé... Bien cordialement, JKB
Re: Configuration asterisk
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 réponds à toutes les questions dans le même mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) Ca c'est OK rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est également mauvais, il devrait ressembler à SBSR/sip::5070 Dans [aor] rajoute contact=sip::5070 Identify ne sert à rien puisque tu t'enregistre Règle les deux premiers problèmes, cela devrait faire avancer les choses 100rel : yes accept_multiple_sdp_answers: false accountcode: acl: aggregate_mwi : true allow : (alaw|ulaw|g722|gsm) allow_overlap : true allow_subscribe: true allow_transfer : true allow_unauthenticated_options : false aors : SBSR asymmetric_rtp_codec : false auth : bind_rtp_to_media_address : false bundle : false call_group : callerid : callerid_privacy : allowed_not_screened callerid_tag : codec_prefs_incoming_answer: prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_answer: prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow connected_line_method : invite contact_acl: context: sbsr cos_audio : 0 cos_video : 0 device_state_busy_at : 0 direct_media : false direct_media_glare_mitigation : none direct_media_method: invite disable_direct_media_on_nat: false dtls_auto_generate_cert: No dtls_ca_file : dtls_ca_path : dtls_cert_file : dtls_cipher: dtls_fingerprint : SHA-256 dtls_private_key : dtls_rekey : 0 dtls_setup : active dtls_verify: No dtmf_mode : rfc4733 fax_detect : false fax_detect_timeout : 0 follow_early_media_fork: true force_avp : false force_rport: true from_domain: systella2.buroticstore.eu from_user : trunk-sip g726_non_standard : false geoloc_incoming_call_profile : geoloc_outgoing_call_profile : ice_support: false identify_by: username,ip ignore_183_without_sdp : false inband_progress: false incoming_call_offer_pref : local incoming_mwi_mailbox : language : mailboxes : max_audio_streams : 1 max_video_streams : 1 media_address : media_encryption : no media_encryption_optimistic: false media_use_received_transport : false message_context: moh_passthrough: false moh_suggest: default mwi_from_user : mwi_subscribe_replaces_unsolicited : no named_call_group : named_pickup_group : notify_early_inuse_ringing : false one_touch_recording: false outbound_auth : SBSR_auth outbound_proxy : outgoing_call_offer_pref
Re: Configuration asterisk
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 entre eux (grâce aux numéros enregistrés dans extensions.conf allant de 6001 à 6008).
Re: Configuration asterisk
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 mail pour qu'on s'y retrouve plus facilement. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) rayleigh*CLI> pjsip show endpoint SBSR ... Endpoint: SBSR Not in use0 of inf OutAuth: SBSR_auth/trunk-sip Aor: SBSR 1 Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78 NonQual nan Transport: udp-transport udp 0 0 0.0.0.0:5060 Identify: SBSR/SBSR Match: 37.97.65.186/32 100rel : yes accept_multiple_sdp_answers: false accountcode: acl: aggregate_mwi : true allow : (alaw|ulaw|g722|gsm) allow_overlap : true allow_subscribe: true allow_transfer : true allow_unauthenticated_options : false aors : SBSR asymmetric_rtp_codec : false auth : bind_rtp_to_media_address : false bundle : false call_group : callerid : callerid_privacy : allowed_not_screened callerid_tag : codec_prefs_incoming_answer: prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_answer: prefer:pending, operation:intersect, keep:all, transcode:allow codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow connected_line_method : invite contact_acl: context: sbsr cos_audio : 0 cos_video : 0 device_state_busy_at : 0 direct_media : false direct_media_glare_mitigation : none direct_media_method: invite disable_direct_media_on_nat: false dtls_auto_generate_cert: No dtls_ca_file : dtls_ca_path : dtls_cert_file : dtls_cipher: dtls_fingerprint : SHA-256 dtls_private_key : dtls_rekey : 0 dtls_setup : active dtls_verify: No dtmf_mode : rfc4733 fax_detect : false fax_detect_timeout : 0 follow_early_media_fork: true force_avp : false force_rport: true from_domain: systella2.buroticstore.eu from_user : trunk-sip g726_non_standard : false geoloc_incoming_call_profile : geoloc_outgoing_call_profile : ice_support: false identify_by: username,ip ignore_183_without_sdp : false inband_progress: false incoming_call_offer_pref : local incoming_mwi_mailbox : language : mailboxes : max_audio_streams : 1 max_video_streams : 1 media_address : media_encryption : no media_encryption_optimistic: false media_use_received_transport : false message_context: moh_passthrough: false moh_suggest: default mwi_from_user : mwi_subscribe_replaces_unsolicited : no named_call_group : named_pickup_group : notify_early_inuse_ringing : false one_touch_recording: false outbound_auth : SBSR_auth outbound_proxy : outgoing_call_offer_pref : remote_merge overlap_context: pickup_group : preferred_codec_only : false record_off_feature : automixmon record_on_feature : automixmon refer_blind_progress : true rewrite_contact: false rpid_immediate : false rtcp_mux : false rtp_engine
Re: Configuration asterisk
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 (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 J'ai laissé dans les SPA112 la configuration qui fonctionnait historiquement chez Nerim. Comment envoyer cette configuration sans tout recopier à la main (ce qui sera long et illisible) ?
Re: Configuration 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 J'ai laissé dans les SPA112 la configuration qui fonctionnait historiquement chez Nerim. Comment envoyer cette configuration sans tout recopier à la main (ce qui sera long et illisible) ?
Re: Configuration asterisk
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. 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 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 INVITE Max-Forwards: 70 Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.320230 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f CSeq: 101 INVITE WWW-Authenticate: Digest realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",opaque="5872e4ec55567b00",algorithm=MD5,qop="auth " Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.324923 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 ACK Max-Forwards: 70 Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0 2023/07/03 11:16:49.328795 192.168.10.253:5060 -> 192.168.1.1:5060 INVITE sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 INVITE Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.329462 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.366603 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Reason: Q.850;cause=34 Content-Length: 0 C'est effectivement le SPA qui a l'air de répondre par une erreur 503. 2023/07/03 11:16:49.404098 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 ACK Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0
Re: Configuration asterisk
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 arrive côté WAN et le nate. Iptables est censé faire le boulot aidé par fail2ban. Je viens de relancer le firewall pour voir.
Re: Configuration asterisk
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 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 Service Unavailable Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Reason: Q.850;cause=34 Content-Length: 0 C'est effectivement le SPA qui a l'air de répondre par une erreur 503. Ton asterisk (192.168.1.1) qui répond 503 au SPA Il faudrait la config complète du SPA
Re: Configuration asterisk
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 Service Unavailable Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Reason: Q.850;cause=34 Content-Length: 0 C'est effectivement le SPA qui a l'air de répondre par une erreur 503. Ton asterisk (192.168.1.1) qui répond 503 au SPA Il faudrait la config complète du SPA
Re: Configuration asterisk
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 donc non. Un point me chagrine. À la requête du serveur de l'opérateur : 2023/07/03 11:00:47.087935 37.97.65.186:5070 -> 192.168.15.18:40055 OPTIONS sip:s@62.212.98.88:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 37.97.65.186:5070;branch=z9hG4bKZ67rt8U6937aK Route: ;transport=TCP Max-Forwards: 70 From: ;tag=7Xp87eDtae20H To: Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 CSeq: 348219426 OPTIONS Contact: User-Agent: Sewan_TRUNKFSC15 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIF Y Supported: path, replaces Allow-Events: talk, hold, conference, refer Content-Length: 0 mpon asterisk répond : 2023/07/03 11:00:47.088564 192.168.15.18:40055 -> 37.97.65.186:5070 SIP/2.0 404 Not Found Via: SIP/2.0/TCP 37.97.65.186:5070;rport=5070;received=37.97.65.186;branch=z9hG4 bKZ67rt8U6937aK Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 From: ;tag=7Xp87eDtae20H To: ;tag=z9hG4bKZ67rt8U6937aK CSeq: 348219426 OPTIONS Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, appli cation/simple-message-summary, application/pidf+xml, application/dialog-info+xml , application/pidf+xml, application/dialog-info+xml, application/simple-message- summary, message/sipfrag;version=2.0 Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE Supported: 100rel, timer, replaces, norefersub Accept-Encoding: identity Accept-Language: en Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 C'est l'extension s qui n'existe pas dans le contexte du trunk chez toi. Il faudrait voir avec Sewan le pourquoi de la réponse. Lié au problème d'UTF8 car ton prénom est devenu Jool ... ? Je vais voir avec eux. Petite question connexe sur sngrep. Je trouve des choses comme ça : [ ] 29 OPTIONS100@1.1.1.1 100@1.1.1.1 1 [ ] 45 OPTIONScensysinsp...@censys.io test.e...@sip5060.net 1 Quand je vais voir dedans, je peux trouver : 2023/07/03 10:30:06.796424 116.12.47.142:5102 -> 192.168.15.18:5060 OPTIONS sip:100@62.212.98.88 SIP/2.0 Via: SIP/2.0/UDP 116.12.47.142:5102;branch=z9hG4bK-1203353867;rport Max-Forwards: 70 To: "sipvicious" From: "sipvicious";tag=3365643436323538313363340132313430303536 303634 User-Agent: friendly-scanner Call-ID: 681857140004342012871496 Contact: sip:100@116.12.47.142:5102 CSeq: 1 OPTIONS Accept: application/sdp Content-Length: 0 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 ? Par défaut, tout est fermé et je n'ouvre que le nécessaire. En particulier, le 5060/UDP est censé être fermé. Chain INPUT (policy DROP 18 packets, 1941 bytes) pkts bytes target prot opt in out source destination 889 99011 f2b-recidive tcp -- anyany anywhere anywhere 736 144K ACCEPT all -- lo any anywhere anywhere 739 50821 ACCEPT all -- lan0 any anywhere anywhere 12 1872 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:ssh 56 5214 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:smtp 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:domain 172 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:domain 33 4407 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:http 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:ntp 19 3508 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:https 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submissions 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submission 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:imaps 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:pop3s 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:cvspserver 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:2401 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:xmpp-client 0 0 ACCEPT tcp -- wan0 an
Re: Configuration asterisk
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 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 INVITE Max-Forwards: 70 Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.320230 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f CSeq: 101 INVITE WWW-Authenticate: Digest realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",opaque="5872e4ec55567b00",algorithm=MD5,qop="auth " Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.324923 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 ACK Max-Forwards: 70 Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0 2023/07/03 11:16:49.328795 192.168.10.253:5060 -> 192.168.1.1:5060 INVITE sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 INVITE Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.329462 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.366603 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Reason: Q.850;cause=34 Content-Length: 0 C'est effectivement le SPA qui a l'air de répondre par une erreur 503. 2023/07/03 11:16:49.404098 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 ACK Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0
Re: Configuration asterisk
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. À la requête du serveur de l'opérateur : 2023/07/03 11:00:47.087935 37.97.65.186:5070 -> 192.168.15.18:40055 OPTIONS sip:s@62.212.98.88:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 37.97.65.186:5070;branch=z9hG4bKZ67rt8U6937aK Route: ;transport=TCP Max-Forwards: 70 From: ;tag=7Xp87eDtae20H To: Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 CSeq: 348219426 OPTIONS Contact: User-Agent: Sewan_TRUNKFSC15 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIF Y Supported: path, replaces Allow-Events: talk, hold, conference, refer Content-Length: 0 mpon asterisk répond : 2023/07/03 11:00:47.088564 192.168.15.18:40055 -> 37.97.65.186:5070 SIP/2.0 404 Not Found Via: SIP/2.0/TCP 37.97.65.186:5070;rport=5070;received=37.97.65.186;branch=z9hG4 bKZ67rt8U6937aK Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 From: ;tag=7Xp87eDtae20H To: ;tag=z9hG4bKZ67rt8U6937aK CSeq: 348219426 OPTIONS Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, appli cation/simple-message-summary, application/pidf+xml, application/dialog-info+xml , application/pidf+xml, application/dialog-info+xml, application/simple-message- summary, message/sipfrag;version=2.0 Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE Supported: 100rel, timer, replaces, norefersub Accept-Encoding: identity Accept-Language: en Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 > Il faudrait voir avec Sewan le pourquoi de la réponse. Lié au problème > d'UTF8 car ton prénom est devenu Jool ... ? Je vais voir avec eux. Petite question connexe sur sngrep. Je trouve des choses comme ça : [ ] 29 OPTIONS100@1.1.1.1 100@1.1.1.1 1 [ ] 45 OPTIONScensysinsp...@censys.io test.e...@sip5060.net 1 Quand je vais voir dedans, je peux trouver : 2023/07/03 10:30:06.796424 116.12.47.142:5102 -> 192.168.15.18:5060 OPTIONS sip:100@62.212.98.88 SIP/2.0 Via: SIP/2.0/UDP 116.12.47.142:5102;branch=z9hG4bK-1203353867;rport Max-Forwards: 70 To: "sipvicious" From: "sipvicious";tag=3365643436323538313363340132313430303536 303634 User-Agent: friendly-scanner Call-ID: 681857140004342012871496 Contact: sip:100@116.12.47.142:5102 CSeq: 1 OPTIONS Accept: application/sdp Content-Length: 0 Je ne saisis pas comment ces paquets arrivent à passer le firewall. Par défaut, tout est fermé et je n'ouvre que le nécessaire. En particulier, le 5060/UDP est censé être fermé. Chain INPUT (policy DROP 18 packets, 1941 bytes) pkts bytes target prot opt in out source destination 889 99011 f2b-recidive tcp -- anyany anywhere anywhere 736 144K ACCEPT all -- lo any anywhere anywhere 739 50821 ACCEPT all -- lan0 any anywhere anywhere 12 1872 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:ssh 56 5214 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:smtp 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:domain 172 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:domain 33 4407 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:http 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:ntp 19 3508 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:https 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submissions 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submission 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:imaps 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:pop3s 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:cvspserver 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:2401 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:xmpp-client 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:git 0 0 ACCEPT icmp -- wan0 any anywhere anywhere 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:1 0 0 ACCEPT tcp -- wan0 any anywhere anywhere
Re: Configuration asterisk
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 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 03/07/2023 à 10:20, BERTRAND Joël a écrit : NoSpam a écrit : [...] 10:14:34.362739 │ 503 Service Un│Contact: "BERTRAND Jool" 10:14:34.398429 │ ACK │Expires: 240 │ │User-Agent: Cisco/SPA112-1.4.1_SR5 │ │Content-Length: 335 │ │Allow: ACK, BYE, CANCEL, INFO, INVITE, N │ │OTIFY, OPTIONS, REFER │ │Supported: replaces │ │Content-Type: application/sdp │ │ │ │v=0 │ │o=- 735811 735811 IN IP4 192.168.10.253 │ │s=- │ │c=IN IP4 192.168.10.253 │ │t=0 0 │ │m=audio 16386 RTP/AVP 8 18 0 2 100 101 │ │a=rtpmap:8 PCMA/8000 │ │a=rtpmap:18 G729a/8000 │ │a=rtpmap:0 PCMU/8000 │ │a=rtpmap:2 G726-32/8000 │ │a=rtpmap:100 NSE/8000 │ │a=fmtp:100 192-193 │ │a=rtpmap:101 telephone-event/8000 │ │a=fmtp:101 0-15 │ │a=ptime:30 │ │a=sendrecv - les appels entrants font bien sonner le bon téléphone, mais seule la voie sortante fonctionne. je ne comprends pas cette phrase ? Lorsque j'appelle par exemple de mon cellulaire vers un numéro correspondant au trunk SIP. Je ne comprends pas plus: tu appelles de ton cellulaire vers un numéro et le poste correspondant sonne. J'ai juste ? Oui. Que veut dire alors "seule la voie sortante fonctionne" alors que tu n'arrives pas à passer d'appel ? Je n'arrive pas à passer un appel sortant. Un appel entrant est acheminé, mais seule les paquets RTP asterisk vers le monde extérieur passent. Il n'y a aucun paquet RTP entrants. Il n'y a aucun paquet RTP qui provient de l'extérieur... Qu'as tu mis dans ton transport external_media_address et external_signaling_address ? [tcp-transport] type=transport protocol=tcp bind=192.168.15.18 local_net=192.168.0.0/16 external_media_address=adresse publique external_signaling_address=adresse publique tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette de ports que tu as définie est elle bien renvoyée vers asterisk ? Tout est renvoyé vers le serveur asterisk (DMZ) qui accepte tout ce qui vient du sous-réseau de l'opérateur en question quel que soit le protocole (iptables). La signalisation est faite en TCP sur le port 5070. Mais les paquets RTP doivent normalement passer en UDP. Du reste, c'est bien ce que j'observe. Dans un précédent message tu disais ne pas voir les paquets RTP ... donc tu les réceptionne bien au niveau d'asterisk ? De toute manière le message "CONGESTION" ci dessus correspond à un problème lié au signal, le RTP n'entre pas encore en ligne. Non. Je ne reçois aucun paquet RTP. En revanche, lorsqu'un appel est acheminé vers mon asterisk, j'en émets à destination du serveur asterisk de mon fournisseur. Difficile de te répondre ne connaissant pas le schéma du réseau ... WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1) | | | 192.168.1.2 +-serveur LAN 192.168.10.128 | LAN Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance fibre/4G d'un /29). Par hasard, une livebox ? Une fibre FIB Orange ? Non, réseau Axione avec un Cisco. Dans le Cisco, y a t íl mention de SIP Alg? Si oui, désactive. Désactivée (depuis le début des tests).
Re: Configuration asterisk
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 03/07/2023 à 10:20, BERTRAND Joël a écrit : NoSpam a écrit : [...] 10:14:34.362739 │ 503 Service Un│Contact: "BERTRAND Jool" 10:14:34.398429 │ ACK │Expires: 240 │ │User-Agent: Cisco/SPA112-1.4.1_SR5 │ │Content-Length: 335 │ │Allow: ACK, BYE, CANCEL, INFO, INVITE, N │ │OTIFY, OPTIONS, REFER │ │Supported: replaces │ │Content-Type: application/sdp │ │ │ │v=0 │ │o=- 735811 735811 IN IP4 192.168.10.253 │ │s=- │ │c=IN IP4 192.168.10.253 │ │t=0 0 │ │m=audio 16386 RTP/AVP 8 18 0 2 100 101 │ │a=rtpmap:8 PCMA/8000 │ │a=rtpmap:18 G729a/8000 │ │a=rtpmap:0 PCMU/8000 │ │a=rtpmap:2 G726-32/8000 │ │a=rtpmap:100 NSE/8000 │ │a=fmtp:100 192-193 │ │a=rtpmap:101 telephone-event/8000 │ │a=fmtp:101 0-15 │ │a=ptime:30 │ │a=sendrecv - les appels entrants font bien sonner le bon téléphone, mais seule la voie sortante fonctionne. je ne comprends pas cette phrase ? Lorsque j'appelle par exemple de mon cellulaire vers un numéro correspondant au trunk SIP. Je ne comprends pas plus: tu appelles de ton cellulaire vers un numéro et le poste correspondant sonne. J'ai juste ? Oui. Que veut dire alors "seule la voie sortante fonctionne" alors que tu n'arrives pas à passer d'appel ? Je n'arrive pas à passer un appel sortant. Un appel entrant est acheminé, mais seule les paquets RTP asterisk vers le monde extérieur passent. Il n'y a aucun paquet RTP entrants. Il n'y a aucun paquet RTP qui provient de l'extérieur... Qu'as tu mis dans ton transport external_media_address et external_signaling_address ? [tcp-transport] type=transport protocol=tcp bind=192.168.15.18 local_net=192.168.0.0/16 external_media_address=adresse publique external_signaling_address=adresse publique tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette de ports que tu as définie est elle bien renvoyée vers asterisk ? Tout est renvoyé vers le serveur asterisk (DMZ) qui accepte tout ce qui vient du sous-réseau de l'opérateur en question quel que soit le protocole (iptables). La signalisation est faite en TCP sur le port 5070. Mais les paquets RTP doivent normalement passer en UDP. Du reste, c'est bien ce que j'observe. Dans un précédent message tu disais ne pas voir les paquets RTP ... donc tu les réceptionne bien au niveau d'asterisk ? De toute manière le message "CONGESTION" ci dessus correspond à un problème lié au signal, le RTP n'entre pas encore en ligne. Non. Je ne reçois aucun paquet RTP. En revanche, lorsqu'un appel est acheminé vers mon asterisk, j'en émets à destination du serveur asterisk de mon fournisseur. Difficile de te répondre ne connaissant pas le schéma du réseau ... WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1) | | | 192.168.1.2 +-serveur LAN 192.168.10.128 | LAN Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance fibre/4G d'un /29). Par hasard, une livebox ? Une fibre FIB Orange ? Non, réseau Axione avec un Cisco. Dans le Cisco, y a t íl mention de SIP Alg? Si oui, désactive. Désactivée (depuis le début des tests).
Re: Configuration asterisk
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] 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 >> -- Executing [001@internal:1] Dial("PJSIP/6001-0008", >> "PJSIP/01@SBSR") in new stack >> -- Called PJSIP/01@SBSR >> == Everyone is busy/congested at this time (1:0/1/0) >> -- Auto fallthrough, channel 'PJSIP/6001-0008' status is >> 'CONGESTION' > > En cli, pjsip set logger host Jul 3 10:14:34] WARNING[32621]: 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 3 10:14:34] WARNING[32621]: res_pjsip.c:2497 set_id_from_hdr: CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8 characters which were replaced -- Executing [001@internal:1] Dial("PJSIP/6001-", "PJSIP/0148069873@SBSR") in new stack -- Called PJSIP/01@SBSR == Everyone is busy/congested at this time (1:0/1/0) -- Auto fallthrough, channel 'PJSIP/6001-' status is 'CONGESTION' <--- Received SIP request (651 bytes) from TCP:37.97.65.186:5070 ---> OPTIONS sip:s@62.212.98.88:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 37.97.65.186:5070;branch=z9hG4bKF13grv1tvD7va Route: ;transport=TCP Max-Forwards: 70 From: ;tag=a3r2eB8ge69Dp To: Call-ID: 4a0ef4d5-4ac8-48f1-a551-e61277fe9753_4747c3c2-355c-4604-be14-d88ac29d8948 CSeq: 348033221 OPTIONS Contact: User-Agent: Sewan_TRUNKFSC15 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY Supported: path, replaces Allow-Events: talk, hold, conference, refer Content-Length: 0 > En parallèle, dans un terminal, lance sngrep Une seule transaction : │INVITE sip:00148069873@192.168.1.1 SIP/2 192.168.10.253:5060│.0 ──┬─│Via: SIP/2.0/UDP 192.168.10.253:5060;bra 10:14:34.308815 │INVITE (S│nch=z9hG4bK-e51ba7a4;rport +0.000602 │ │From: "BERTRAND Jool" ;tag=d0c01f1f32fe402fo0 +0.005262 │ <───│To: 10:14:34.314679 │ ACK │Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling 10:14:34.317965 │INVITE (S│Call-ID: 57d1fddf-fd97f06f@192.168.10.25 +0.000737 │ │3 10:14:34.318702 │ 100 Tryi│CSeq: 101 INVITE +0.044037 │ <───│Max-Forwards: 70 10:14:34.362739 │ 503 Service Un│Contact: "BERTRAND Jool" 10:14:34.398429 │ ACK │Expires: 240 │ │User-Agent: Cisco/SPA112-1.4.1_SR5 │ │Content-Length: 335 │ │Allow: ACK, BYE, CANCEL, INFO, INVITE, N │ │OTIFY, OPTIONS, REFER │ │Supported: replaces │ │Content-Type: application/sdp │ │ │ │v=0 │ │o=- 735811 735811 IN IP4 192.168.10.253 │ │s=- │ │c=IN IP4 192.168.10.253 │ │t=0 0 │ │m=audio 16386 RTP/AVP 8 18 0 2 100 101 │ │a=rtpmap:8 PCMA/8000 │ │a=rtpmap:18 G729a/8000 │ │a=rtpmap:0 PCMU/8000 │ │a=rtpmap:2 G726-32/8000 │ │a=rtpmap:100 NSE/8000 │ │a=fmtp:100 192-193 │ │a=rtpmap:101 telephone-event/8000 │ │a=fmtp:101 0-15 │ │a=ptime:30 │ │a=sendrecv >> >> - les appels entrants font bien sonner le bon téléphone, mais >> seule la >> voie sortante fonctionne. > je ne comprends pas cette phrase >>> ? >> Lorsque j'appelle par exemple de mon cellulaire vers un numéro >> correspondant au trunk SIP. > Je ne comprends pas plus: tu appelles de ton cellulaire vers un numéro > et le poste correspondant sonne. J'ai juste ? Oui. > Que veut dire alors "seule > la voie sortante fonctionne" alors que tu n'arrives pas à passer d'appel ? Je n'arrive pas à passer un appel sortant. Un appel entrant est acheminé, mais seule les paquets RTP asterisk vers le monde extérieur passent. Il n'y a aucun paquet RTP entrants. >> Il n'y a aucun paquet
Re: Configuration asterisk
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 un appel en copie les logs ici Pas de logs ... Oui, journée difficile... 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] 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 -- Executing [001@internal:1] Dial("PJSIP/6001-0008", "PJSIP/01@SBSR") in new stack -- Called PJSIP/01@SBSR == Everyone is busy/congested at this time (1:0/1/0) -- Auto fallthrough, channel 'PJSIP/6001-0008' status is 'CONGESTION' En cli, pjsip set logger host En parallèle, dans un terminal, lance sngrep - les appels entrants font bien sonner le bon téléphone, mais seule la voie sortante fonctionne. je ne comprends pas cette phrase ? Lorsque j'appelle par exemple de mon cellulaire vers un numéro correspondant au trunk SIP. Je ne comprends pas plus: tu appelles de ton cellulaire vers un numéro et le poste correspondant sonne. J'ai juste ? Que veut dire alors "seule la voie sortante fonctionne" alors que tu n'arrives pas à passer d'appel ? Il n'y a aucun paquet RTP qui provient de l'extérieur... Qu'as tu mis dans ton transport external_media_address et external_signaling_address ? [tcp-transport] type=transport protocol=tcp bind=192.168.15.18 local_net=192.168.0.0/16 external_media_address=adresse publique external_signaling_address=adresse publique tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette de ports que tu as définie est elle bien renvoyée vers asterisk ? Tout est renvoyé vers le serveur asterisk (DMZ) qui accepte tout ce qui vient du sous-réseau de l'opérateur en question quel que soit le protocole (iptables). La signalisation est faite en TCP sur le port 5070. Mais les paquets RTP doivent normalement passer en UDP. Du reste, c'est bien ce que j'observe. Dans un précédent message tu disais ne pas voir les paquets RTP ... donc tu les réceptionne bien au niveau d'asterisk ? De toute manière le message "CONGESTION" ci dessus correspond à un problème lié au signal, le RTP n'entre pas encore en ligne. Difficile de te répondre ne connaissant pas le schéma du réseau ... WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1) | | | 192.168.1.2 +-serveur LAN 192.168.10.128 | LAN Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance fibre/4G d'un /29). Par hasard, une livebox ? Une fibre FIB Orange ? Non, réseau Axione avec un Cisco. Dans le Cisco, y a t íl mention de SIP Alg? Si oui, désactive. [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR) Ne connaissant pas la config de SBSR. Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui commence par 0 plus un caractère minimum à ton opérateur, il risque de ne pas aimer ;) [internal] exten => 6001,1,Dial(PJSIP/6001) exten => 6002,1,Dial(PJSIP/6002) exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR) exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR) Depuis le 01/01/2023 les 06 et 07 sont interdits pour la prospection commerciale, les numéros géographiques ne le sont plus, les 09 sont les numéros en vogue Ton opérateur ne publie t'il pas d'exemple de configuration ? J'ai un accès internet pour les ploucs. J'ai déjà eu du mal à obtenir une fibre avec un /29 IPv4 et un /48 IPv6 et un routage MPLS... Je n'ai pas accès aux opérateurs pro classiques, il faut que ces opérateurs aient un contrat de partenariat avec la région et ce sont souvent des gens qui sont à trois ou quatre dans une boîte...