Asterisk não funciona com 2 links com CentOS 6.3 [RESOLVIDO]

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 11:34h

"Não estou te entendendo. A rede 192.168.0.0 tem mascara 255.255.252.0 como você pode ver acima.
a rede 10.2.0.0 tem mascara 255.255.255.0.

O ip da eth0 é 192.168.0.254 isto não da para se ver no route -n, mesmo não, eu esqueci de postar no primeira post.

A conexão do telefone no ip 200.150.10.99 que esta na eth1, esta sendo respondida pelo ip 10.2.0.254 que esta na eth2 como você pode ver no primeiro post, então hora nenhuma a eth0 entra em cena.

O servidor asterisk esta dentro da maquina que tem os 2 links, não preciso de nat para isto."



Se a rede 192.168.0.0 tem máscara 255.255.252.0 então alguma coisa está errada. A rede é classe C e a máscara é classe A.
A rede 10.2.0.0 aceita a máscara 255.255.255.0, mas a rede 192.168.0.0 não aceita a máscara 255.255.252.0.

E sim, a princípio você não precisaria de NAT para o Asterisk, mas como você tem dois links se você não fez um nat ou um direcionamento no Iptables informando qual placa responderá pelo IP do Asterisk (200.150.10.99) o servidor pode estar se confundindo.

Além disso, soma-se o problema das máscaras estarem erradas (não estou dizendo que estão), mas dessa maneira causa confusão.

Faça um teste, mude essa linha

bindaddr=200.150.10.99

para

bindaddr=0.0.0.0

E teste assim, somente com essa modificação e com os dois links.

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 11:47h

Não tem nada de errado em você usar uma mascara de 22 bits em uma rede 192, isto e para você poder ter mais de 256 hosts, no meu caso a rede 192.168.0.0 = servidores e o restante uso para 380 computadores, já faço uso disto a mais de 5 anos, se você pegar uma calculadora de ips você vê isto melhor.

Com relação a fazer o nat, fico sem saber, se o asterisk esta dentro do servidor onde ele é dono do ip 200.150.10.99, 192.168.0.254 e 10.2.0.254 qual o sentido disto? Nem imagino como seria esta linha de comando?

Meu asterisk por default é bindaddr=0.0.0.0, mudei a configuração para ver se ele obedecia somente ao ip 200.150.10.99, ou seja, se mudar não vai faze diferença no problema.

A pergunta que não quer se calar e funciona sem nat!

Porque os pacotes TCP com destino a 200.150.10.99 eth1, gerados pelo ssh saem corretamente pela eth1, e os pacotes gerados pelo ssh com destino eth2 (10.2.0.254, externo = 201.17.255.228) também saem corretamente.

E os pacotes UDP não tem o mesmo comportamento?

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 13:53h

Pacotes UDP não fazem verificação, ou seja, o pacote é enviado, se chegou... chegou, se não chegou quem enviou não tem como saber se chegou o pacote.
Se tem problema de conexão o pacote UDP pode chegar pela metade, ou pode nem chegar, ou pode se desviar no caminho, etc.

Pacotes TCP fazem verificação e tem precedência sobre pacotes UDP.
Um bom exemplo é quando tem VOIP no mesmo link de dados, ou seja, pacotes UDP VOIP e internet no mesmo link, se o link não é bom às vezes dá uma "cortada" na ligação de telefone, pois os pacotes TCP tem precedência. Esse comportamento é padrão da pilha de protocolos TCP/IP do qual o UDP e o TCP fazem parte, além de outros.

Por isso que é bom ter um link dedicado somente para VOIP ou, se não for possível, destinar uma parte da banda somente para VOIP.

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 14:08h

Sim, entendo o precedentes do udp, ate citei em postes anteriores sobre a duvida do handsheik, mas o foco é porque os udp estão entrando por um link e saindo por outro link? Não chegar ou atrasar por causa da preferencia do tcp eu entendo, mas sair por outro link!

Duvida, mesmo o iptables estando com tudo liberado, como é o comportamento do chain output, olhando pelo ângulo que o pacote de resposta nasce dentro do servidor onde tem as três placas, como o daemon é orientado a entregar para a interface que originou a resposta do pacote?

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 14:26h

OUTPUT na tabela filter, que é a padrão (para pacotes gerados localmente, pacotes oriundos da própria máquina com destino para fora dela).

OUTPUT na tabela nat (para alterar pacotes gerados localmente antes do roteamento ou compartilhamento).

Porém, como são pacotes UDP e estão sem tratamento nenhum, eles podem se perder no caminho, pois o servidor simplesmente envia eles. Com dois links é bem mais fácil se perder.


Faça outro teste com o Iptables aberto ainda:
mude
nat=yes

para

nat=no

E em externip estou em dúvida, mas acredito que com o nat=yes deveria ir seu IP externo que deve ser diferente do IP colocado em bindaddr. Mas teste mudando somente nat para no.

Fiz um exemplo de regras de NAT com as portas sugeridas no Manuel do Asterisk (5060 e 10000:20000):

iptables -A FORWARD -p udp --sport 5060 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --dport 5060 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --sport 10000:20000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --dport 10000:20000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -p udp --dport 5060 -d 200.150.10.99 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -i eth1 --dport 5060 -j DNAT --to 200.150.10.99
iptables -t nat -A POSTROUTING -p udp --dport 10000:20000 -d 200.150.10.99 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -i eth1 --dport 10000:20000 -j DNAT --to 200.150.10.99

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 14:52h

não deu certo!

achei este trecho em um link ainda pouco procurando o problema veja a afirmação deste cara


Re: Asterisk, duas subinterfaces, IP de origem

Post por david55 »terça fev 26, 2013 8:27

O problema não é o roteamento de nível 3, é o contato: cabeçalho, etc, na camada de aplicação.

Asterisk assume um sistema corretamente multi-homed, ou seja, que todos os seus endereços IP são igualmente válidos em qualquer lugar que pode alcançá-lo. Ele não fornece um mecanismo para escolher entre os endereços em que a camada, exceto no contexto de, no máximo, um endereço natted.

A escolha real da interface de saída é feita pelo kernel, não pelo Asterisk.

http://translate.google.com.br/translate?hl=pt-BR&sl=en&u=http://forums.digium.com/viewtopic...

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 15:04h

Então você deverá fazer NAT, pois o Iptables atua no kernel.
Ou definir rotas bem distintas, talvez com ip-route.
Eu optaria pelo NAT.

Você está usando somente SIP ou também algum outro protocolo tipo IAX, H.323, etc?

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 15:14h

Estou usando somente sip. Seguindo a dica do link do post anterior, eu deixei o nat=yes e localnet, externip, deixei vazio, também não funcionou, mas a conexão vinda do ip 200.150.10.99 não esta sendo mais respondida pela eth2

mudei de novo o bindaddr=0.0.0.0 mas também não tive sucesso.


veja a dubug do tcpdump em ascii


15:16:00.089191 IP 200.164.152.156.56005 > 200.150.10.99.sip: SIP, length: 713
E.....@.;.........
c........REGISTER sip:200.150.10.99:5060 SIP/2.0
Via: SIP/2.0/UDP 200.164.152.156:5060;branch=z9hG4bK0a95d61b3aac5f2db1ccc953b538c68b
Via: SIP/2.0/UDP 192.168.1.4:5065;branch=z9hG4bK4ba4de993f4249299
From: "1001" <sip:1001@200.150.10.99:5060>;tag=4737629d3d
To: "1001" <sip:1001@200.150.10.99:5060>
Call-ID: 12f8bf44438e9acd
CSeq: 858785144 REGISTER
Contact: <sip:1001@200.164.152.156:5060>;expires=120
max-forwards: 69
allow-events: refer
user-agent: Media5-fone/3.7.1.1118
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE, UPDATE
Accept: application/reginfo+xml, application/sdp, application/simple-message-summary, message/sipfrag, multipart/mixed, multipart/related
Content-Length: 0

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 15:42h

Veja no link que você enviou:

"No entanto, em qualquer caso, o Asterisk não tem nenhum problema com os sistemas muti-homed. Ele tem problemas é com sistemas com duas redes separadas."

Faz um tempinho que não mexo no Asterisk, mas com dois links sempre se fazia NAT ou se definia bem as rotas.

Você tem dois links, cada um com uma placa de rede (eth1 e eth2) e mais a placa da rede interna (eth0).
Sugiro você escolher um link para VOIP e destinar o outro para internet. Daí você faz os respectivos NATs.

Ou, se os dois links forem muito bons e não tem necessidade de destinar um link inteiro para VOIP, daí deverá ter um controle de banda destinando tantos MB ou KB para o Asterisk através das portas e/ou do IP.

192.168.1.4:5065 << aqui está usando a porta 5065 na rede interna, o firewall está aberto ainda suponho.

Somente se deixa o nat=yes quando o Asterisk está por trás de um firewall.

"The address 0.0.0.0 tells Asterisk to listen on all interfaces."
O endereço 0.0.0.0 diz ao Asterisk para escutar em todas as interfaces.
bindaddr=0.0.0.0
bindport=5060

"Estes parâmetros opcionais permitem que você controle a interface IP e a porta na qual
você deseja aceitar conexões SIP. Se forem omitidos, a porta será definida para 5060, e todos os endereços IP em seu sistema Asterisk aceitarão receber conexões SIP. Se vários endereços de ligação estiverem configurados, apenas as interfaces desses IPs escutarão as conexões."

Ou seja, se você colocar um IP em bindaddr e uma porta em bindport, é somente nesse IP e nessa porta que o Asterisk escutará.
E como estava assim antes, o teu problema é nas rotas. Faça o NAT ou defina rotas bem distintas para cada link.

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 15:56h

É isto que estou tentando fazer deste o inicio, deixar apenas o asterisk no link1 = eth1, mas estou vendo que isto só vai funcionar se eu colocar o asterisk em outra maquina, dentro da maquina dos links não vai ter como.


Sinceramente, descolheço regra de iptables para pacotes que nascem dentro da maquina!

Buckminster
(usa Debian)

Enviado em 30/12/2013 - 16:03h

Teste essas:

iptables -A FORWARD -p udp --sport 5060 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --dport 5060 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --sport 10000:20000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --dport 10000:20000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -p udp --dport 5060 -d 200.150.10.99 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -i eth1 --dport 5060 -j DNAT --to 200.150.10.99
iptables -t nat -A POSTROUTING -p udp --dport 10000:20000 -d 200.150.10.99 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -i eth1 --dport 10000:20000 -j DNAT --to 200.150.10.99

E sete bindaddr=200.150.10.99 e bindport=5060, nat=yes.

Para pacotes gerados na própria máquina no Iptables é na chain OUTPUT, mas nesse caso acredito não ser necessário.
O pacote será gerado pelo Asterisk e as chains POSTROUTING e PREROUTING da tabela nat trabalharão eles antes de sair e/ou chegar de acordo com as regras.

nat :: Esta tabela é consultada quando for encontrado um pacote que criou uma nova conexão. É composta de três built-ins: PREROUTING (para alterar pacotes no momento que eles chegam, antes do roteamento ou compartilhamento.), OUTPUT (para alterar pacotes gerados localmente antes do roteamento ou compartilhamento), POSTROUTING (para alterar pacotes quando eles estão prestes a sair, depois do roteamento ou compartilhamento).

filter :: Esta é a tabela padrão (se a opção "-t" não definir outra tabela, será utilizada esta tabela). Ela contém a chain "built-in INPUT" (entrada - para pacotes destinados a sockets locais, pacotes destinados para a própria máquina), FORWARD (para pacotes sendo roteados através da máquina, pacotes que passam pela máquina) e OUTPUT (para pacotes gerados localmente, pacotes oriundos da própria máquina com destino para fora dela).


Mas lembre-se que você deverá colocar também uma regra de NAT para a internet na placa eth2 (acho), daí é com você decidir como vai fazer, se vai dedicar um link somente para VOIP.
Você pode criar uma regra MASQUERADE para a eth1 também, mas se o link não for bom ocorrerá aquela "cortada" de voz que te falei antes.
E essa(s) regra(s) de MASQUERADE para internet devem vir depois das regras acima.

Ou, como já falei, crie rotas distintas, talvez com iproute.

stefaniobrunhara
(usa CentOS)

Enviado em 30/12/2013 - 16:26h

Não deu certo, tentei! Como você mesmo disse, meus pacotes estão no chain output, pois são as resposta do chain input, então e como falei no meu tópico anterior, não vejo como fazer as regras, para mim as regras forward e postrouting e prerouting não faz sentido.


Eu lanço regras com o ip route nas tabelas auxiliares, na tabela main, que é a usando pelo kernel, ele mesmo cria automático, que gerencia melhor do que eu.