Asterisk atrás de um firewall

Asterisk atrás de um firewall

temos um problema complicado em nosso servidor Asterisk, que estamos lutando para resolver. Espero que alguém com mais conhecimento do que eu possa ajudar.

Estamos executando o Asterisk 1.8.23.0 no Centos 6.4 e nossos telefones e servidor Asterisk estão dentro de um firewall e nossos provedores de serviços VoIP estão do lado de fora. O firewall é configurado e gerenciado por uma empresa externa.

Atualmente, temos dois provedores de serviços VoIP, Aque lidam com a maior parte do tráfego de entrada e todo o nosso tráfego de saída, e Bque lida com parte do nosso tráfego de entrada, que é roteado para nossa central de atendimento por meio de um IVR externo.

Em uma auditoria de segurança recente, fomos informados de que deveríamos ter todo o nosso tráfego VoIP passando por um firewall, e foi decidido que deveríamos fazer isso em duas fases.

A primeira fase é colocar o tráfego de entrada que recebemos Batravés de um firewall e, em seguida, na fase dois, enviar o tráfego de entrada e saída Atambém através do firewall. No momento, estamos presos na fase um.

Inicialmente, tentamos configurar externipe localnetna [general]seção de nosso sip.confarquivo, mas isso interrompeu o tráfego VoIP em nosso provedor de serviços VoIP primário A, então tentamos configurá-los na entrada específica em nosso sip.confarquivo para nosso provedor de serviços VoIP secundário, Bassim :

[A]
type=friend
disallow=all
allow=alaw
allow=g729
context=fromneotel
host=aaa.aaaa.aaa.aaa
insecure=port,invite
nat=no
directmedia=no

[B]
type=friend
disallow=all
allow=g711
allow=g729
allow=alaw
context=fromis1
host=bbb.bbb.bbb.bbb
insecure=port,invite
nat=yes
directmedia=no
externip=ccc.ccc.ccc.ccc
localnet=192.68.20.0/255.255.252.0

onde aaa.aaa.aaa.aaaestá o ip de A e bbb.bbb.bbb.bbbé o ip de B e ccc.ccc.ccc.cccé o ip externo do firewall.

Com essas configurações definidas, a central de atendimento pode receber chamadas por meio do IVR, mas assim que as chamadas forem conectadas, o chamador externo poderá ouvir o agente da central de atendimento, mas o agente da central de atendimento não poderá ouvir o chamador.

Nosso provedor de serviços VoIP nos informa que na 200 OK SIPresposta da ccc.ccc.ccc.cccparte SDP está fornecendo o ddd.ddd.ddd.dddendereço IP para o qual enviar mídia.

ddd.ddd.ddd.dddé o ip do nosso servidor asterisk ao qual Bnormalmente se conectaria quando não estamos tentando passar o tráfego pelo firewall. esta é a informação que recebemos deles:

Via: SIP/2.0/UDP bbb.bbb.bbb.bbb:5060;branch=z9hG4bKmm63qe00d8ogcio100k0.1;received=bbb.bbb.bbb.bbb     
From: "Anonymous"<sip:<originating number from IVR>@bbb.bbb.bbb.bbb:5060;user=phone>;tag=1641833502-1377756054727-
To: "<call centre number>"<sip:<call centre number>@ccc.ccc.ccc.ccc:5060>;tag=as43201e45
Call-ID: [email protected]
CSeq: 609518180 INVITE
Server: Asterisk PBX 1.8.23.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:<call centre number>@ccc.ccc.ccc.ccc>
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
s=Asterisk PBX 1.8.23.0
c=IN IP4 ddd.ddd.ddd.ddd
t=0 0
m=audio 11064 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

de acordo com Bnosso provedor de serviços VoIP secundário, esta é a linha que está causando o problema:o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd

eee.eee.eee.eeeé um endereço IP que não reconheço e sobre o qual não sei nada.

Qualquer ajuda é muito apreciada.

Responder1

Chamadas sem áudio ou unidirecionais são um problema comum durante o NAT VOIP. Obviamente você já localizou a origem do problema: que os pacotes que transportam voz estão sendo enviados para o endereço incorreto.

Primeiro, eu verificaria com as pessoas que mantêm seu firewall. Se o firewall vale a pena, sem dúvida há algo que eles podem fazer para resolver o problema ou facilitar o diagnóstico.

Caso contrário, pergunte aos seus provedores se eles suportam troncos IAX2. IAX2 não sofre dos problemas de NAT do SIP.

Boa sorte.

informação relacionada