Buckminster
(usa Debian)
Enviado em 02/01/2014 - 22:16h
Da mesma forma, pacotes os gerados por processos locais também passam pelo roteamento para serem encaminhados. Logo, todos os datagramas passam, de uma forma ou de outra, pela etapa de roteamento.
Bom, se depois dessa explicação aí em cima que resume tudo, tu ainda duvida, então tu é muito cabeça dura ou está precisando estudar mais.
E o cenário nesse caso não influencia muito. Sim, "cenário" é com "c".
Veja bem, O KERNEL NÃO TEM INTELIGÊNCIA, ELE NÃO SABE PENSAR, O KERNEL É UM PROGRAMA DE COMPUTADOR, O ÚNICO IP QUE ELE SABE DISCERNIR SE ESTÁ NA MÁQUINA OU NÃO, É ALGUM IP DA FAIXA 127.0.0.0 PORQUE ELE FOI PROGRAMADO ASSIM.
OS OUTROS IPs, NESSE CASO, NÃO INTERESSAM SE ESTÁ NA PRÓPRIA MÁQUINA OU NÃO. O KERNEL FAZ A DISTINÇÃO DO ENVIO DOS PROCESSOS LOCAIS ATRAVÉS DAS PORTAS E SE UMA PORTA ESTIVER ASSOCIADA COM UM IP DE UMA DETERMINADA PLACA DE REDE, O KERNEL FARÁ A DISTINÇÃO PELA PORTA
E PELO IP.
SE O PROBLEMA ESTÁ DANDO JUSTAMENTE QUANDO VOCÊ ACRESCENTA MAIS UM LINK, O QUÊ PODE SER?
E JÁ FOI DITO AQUI QUE O ASTERISK TEM PROBLEMAS COM VÁRIOS LINKS.
E isso aqui:
"..então o kernel devera decidir ou não se ele precisa ser roteado...",
O KERNEL POR SI SÓ NÃO FAZ ROTEAMENTO, ELE PRECISA DE REGRAS EXPLÍCITAS PARA ISSO, NO CASO, IPTABLES OU OUTRO PROGRAMA QUE ATUE COMO MÓDULO DO KERNEL E FAÇA ROTEAMENTO.
E isso aqui:
"Este caso ne se aplica, não faz sentido fazer prerouting da maquina para ela mesmo."
Vou colocar DE NOVO o que está no Manuel do Iptables:
"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)."
Veja que a chain PREROUTING na tabela NAT altera os pacotes no momento que eles chegam, antes do roteamento ou compartilhamento.
E associe essa frase aí em cima com isso aqui de baixo:
Lista nat PREROUTING
"Nesta lista irão as regras que serão aplicadas no gancho PREROUTING, ou seja, para pacotes que acabaram de entrar por uma das interfaces de rede,
não importando qual será o destino dos mesmos, se para um processo local ou para ser roteado (forward).
Deve-se ter em mente que a etapa de roteamento é quem decidirá qual o caminho que o pacote irá tomar, inclusive decidindo se o mesmo será repassado ou entregue a um processo local. Para realizar o roteamento são considerados parâmetros de destino, como o IP, para saber se é desta máquina ou se deve ser repassado,
e porta, se for local para decidir para qual processo."
Mas caso tu não conseguir associar, eu explico, DE NOVO:
PARA O KERNEL É INDIFERENTE PARA ONDE ELE VAI ENVIAR O PACOTE, SE PARA FORA DA MÁQUINA OU SE PARA UM PROCESSO LOCAL, O QUE PRECISA ESTAR DEFINIDO É PARA ONDE VAI O PACOTE, SE VAI PARA FORA DA MÁQUINA OU PARA UM PROCESSO LOCAL.
E PARA A DISTRIBUIÇÃO DOS PROCESSOS LOCAIS ELE FAZ A DISTINÇÃO ATRAVÉS DA PORTA E/OU DO IP, E COMO O ASTERISK ESCUTA EM UMA PORTA E ESSA PORTA ESTÁ ASSOCIADA AO IP DA PLACA DE REDE,
PRECISA INDICAR O CAMINHO CORRETO.
E PARA INDICAR ESSE CAMINHO VOCÊ PODE FAZER PELO IPTABLES, OU PELO sysctl.conf, OU POR ONDE VOCÊ QUISER.
E SE É UMA FALHA DO ASTERISK/KERNEL NO DATAGRAMA UDP COMO TU ESTÁ DIZENDO, ONDE VOCÊ CORRIGE ESSA FALHA?
QUAL É O MÓDULO DO KERNEL ENCARREGADO DE TRATAR OS DATAGRAMAS IPs?
É O NETFILTER.
E O IPTABLES ATUA SOBRE QUEM?
SOBRE O NETFILTER.
E VEJA O QUE O MANUEL DO ASTERISK (http://cdn.oreillystatic.com/books/9780596510480.pdf) DIZ:
"Configuring a Local Firewall
If you’re running iptables on the same machine as the Asterisk box, then you can run
the following commands to open port 5060 for SIP signaling, and ports 10,000 through
20,000 for the RTP traffic. You can also narrow the range of RTP ports in the rtp.conf
file located in /etc/asterisk. An excellent book on iptables firewalls is Linux Firewalls by
Steve Suehring and Robert Ziegler (Novell Press).
# iptables -I RH-Firewall-1-INPUT -p udp --dport 5060 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT -p udp --dport 10000:20000 -j ACCEPT
# service iptables save
Be aware that this will allow all UDP traffic from any source access to ports 5060 and
10,000 through 20,000.
Most of the previous configuration may be familiar to you by now, but in case it’s not, here is a brief rundown.
By defining the type as a peer, we are telling Asterisk not to match on the [my_service_provider] name, but rather to match on the IP address in the INVITE message (when the provider is sending us a call). The host parameter is the IP address that we’ll place our calls to, and the IP address we’ll be matching on when receiving a call from the provider."
"Se você estiver executando o iptables na mesma máquina que o Asterisk, então você pode executar os seguintes comandos para abrir a porta 5060 para a sinalização SIP e portas 10.000 por 20.000 para o tráfego RTP."
E mais abaixo a explicação, "By defining the type as a peer, ...", ou seja, "Ao definir o tipo como peer, estamos dizendo ao Asterisk para não combinar o nome [my_service_provider], mas sim, para combinar
o endereço IP na mensagem INVITE (quando o provedor está nos enviando uma chamada)."
E sobre os endereços/máscaras de rede, veja isto na RFC 1519 (http://www.ietf.org/rfc/rfc1519.txt), seção 5. Example of new allocation and routing, e tu verá que, às vezes, o roteador A não enxerga uma determinada rede no roteador B. E podemos considerar o teu roteador como B e o roteador do ISP como A, portanto, precisa indicar o caminho.
E eles colocam isso devido à uma nota na seção 4.2:
"Roteamento para todos os destinos deve ser feito apenas na base de origem. Isto implica que os destinos que são multi-homed em relação a um domínio de roteamento, devem sempre ser explicitamente anunciados em qual domínio de roteamento que não podem ser resumidos (isto tem sentido intuitivo - se uma rede é multi-homed, todos os caminhos dentro de um domínio de roteamento que é "superior" na hierarquia das redes, deve ser conhecido para esta rede "superior")."
E este "conhecimento" para a rede superior é feito determinando-se o caminho de origem e de destino no datagrama do pacote.
E quem determina o caminho (origem e destino) no datagrama do pacote, qual o módulo do kernel que faz isso nesse caso?
