A flag dynaddr


[Home] [Dissertação] [Biba] [Linux] [Conjugue] [br.ispell] [axw3] [uplink]

Gracas ao Adriano estou entendendo melhor o problema com a
conexao inicial que faz o diald levantar o link, e agora acho que
sei tambem resolver o problema.

Na pratica, o que acontece e' que a tentativa de conexao (email,
netscape, telnet, etc) que levanta o link nao se completa, o que
causa um certo desconforto para o usuario. A alteracao da
variavel ip_dynaddr do kernel resolve o problema:

    # echo 1 >/proc/sys/net/ipv4/ip_dynaddr

Note que esse problema teoricamente so' ocorre quando o link e'
ativado por um pacote TCP. Quando ele e' ativado por UDP
(e.g. query de nameserver), em principio o problema nao e'
sentido.

Os testes que fiz foram com o kernel 2.0.31, kernels mais antigos
podem talvez nao possuir esse feature. Segue uma explicacao
teorica um pouco longa do assunto, que presume que o gateway
esteja mascarando IPs.

Quando o pacote que vai levantar o link chega na interface eth0
do gateway, as rotinas de mascaramento trocam o IP de origem pelo
IP da interface destino, e jogam-no nessa interface. Como nesse
momento o link esta' down, a interface destino e' a sl0, criada
pelo diald, e nesse momento referida pela rota default.

Mesmo quando o link torna-se up, os pacotes provenientes daquela
aplicacao continuam a ser mascarados com o endereco da sl0. Isso
ocorre porque o endereco de mascaramento de uma conexao nao pode
mudar ao longo dessa conexao, sob pena de confundir o
servidor. Assim, a aplicacao nunca obtera' resposta, porque nas
nossas hipoteses o IP da sl0 e' nao-oficial.

As tentativas de conexao subsequentes, no entanto, funcionam sem
problemas, porque o link ja' esta' up, e a interface para a qual
aponta a rota default e' a ppp0, que possui endereco oficial.

Ha' pelo menos duas solucoes para o problema. A primeira,
sugerida pelo Adriano, e' solicitar ao provedor um IP fixo e
atribui-lo `a interface sl0. Tecnicamente e' perfeita, so' tem o
problema do eventual custo adicional.

A segunda e' um truque. Nessa situacao e' possivel trocar o
endereco de mascaramento, porque a conexao ainda nao se
estabeleceu. Assim, teoricamente seria possivel, no momento em
que o link se torna up, avisar o kernel para trocar o endereco de
mascaramento de todas as conexoes em curso do IP da sl0 para o IP
da ppp0.

Quando fui olhar o fonte do kernel (o meu e' 2.0.31) para avaliar
o quao dificil seria fazer isso, percebi que isso ja' foi
feito. O modulo ip_masq.c inclui esse codigo, e no inicio dele
ha' ate' uma saudacao: "You are welcome, diald".

No entanto esse codigo so' e' ativado quando a flag ip_dynaddr do
kernel nao contem zero (default: 0). Curiosamente nao encontrei
no fonte do diald (atualmente na versao 0.16.5) codigo para
trocar o valor dessa flag (deveria haver uma chamada ao sysctl).

No entanto, o filesystem /proc permite ler e alterar o valor
dessa flag, conforme indicado no inicio do mail (para ler, basta
dar um "cat").

Note que essa solucao depende do mascaramento de IP estar
ativado. Habitualmente nao se usa mascaramento quando se tem
apenas uma maquina (situacao domestica tipica), mas mesmo nesse
caso, para que a conexao que levanta o link do diald se
completar, e' necessario ativar o mascaramento.

Se voces testarem esse feature, por favor mandem-me um
feedback. Um abraco,