-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leonardo Pinto wrote:
>On Thu, 23 Mar 2006 10:08:54 +0100, Thiago Macieira wrote
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Significa que, se o A pode abrir uma conexão para B, então B pode
>> abrir uma conexão para A.
>
>Eu já havia entendido desta mesma forma. Porém estava questionando a
>estupidez desse tal invento. Pois se A já teria conseguido abrir o
>socket, e iniciado a conversa, para que diabos B, teria que complicar
>a situação, abrindo novamente outra conexão de volta?!!
Vejamos:
cliente FTP abre a conexão
envia o comando:
GET arquivo
por qual conexão deve vir este arquivo? A solução do FTP, lá nos idos da
Internet, foi que o *servidor* FTP abre uma conexão para o *cliente* FTP
na porta 20 e envia o arquivo. Assim, tudo que o cliente tem que fazer é
ficar ouvindo na porta 20 e vai receber o arquivo.
Simples, sem complicação, sem comando extra (PASV ou PORT).
Mas então perceberam que a solução não era muito boa, visto que você só
poderia receber um arquivo por vez. Se houvesse duas conexões FTP
abertas, poderia haver problemas!
E mais: o Unix decidiu que só o root pode abrir a porta 20 (< 1024). Então
inventaram o comando "PORT" que diz para o servidor FTP: ao invés de
conectar na porta 20, conecte-se nesta outra. E colocaram o IP junto no
comando.
Naquela época, IP não era problema. Então todo mundo tinha IP. E não havia
problemas de segurança, porque, afinal, eram apenas alguns institutos de
pesquisa que tinham Internet. Então não havia firewalls.
Conclusão: abrir uma conexão extra, no sentido contrário, não era
problemas.
Bom, logo inventaram os firewalls e começou a haver problemas de
bi-direcionalidade. Daí veio o comando PASV: nesse caso, é o servidor que
escolhe uma porta e fica escutando pela conexão do cliente. Afinal, se o
cliente conectou-se na porta 21, porque não poderia se conectar na porta
12735?
Estamos aí hoje: se o cliente conectou-se na porta 21, porque raios não
pode se conectar na outra porta?
Tire o NAT e configure o firewall para permitir isso. Ou você vai ter
problemas com servidores de FTP.
>> Isso não é mais válido na Internet, em
>> grande parte devido a proliferação não-controlada de NAT.
>
>Ainda bem que notaram tal idiotice.
Idiotice foi ter quebrado a bidirecionalidade.
Se A conversa com B, B conversa com A. Quebrar essa simples regra foi
idiotice.
Sim, NAT é uma praga. Sim, NAT deve ser abolido o quanto antes possível.
E, sim, soluções como UPnP são mais "acoxambrações" sobre o NAT e não
resolvem o problema: só nos fazem nos enterrarmos ainda mais na lama.
Quanto antes as pessoas começarem a perceber que as dificuldades que o NAT
introduz são maiores que os benefícios, tanto antes teremos uma solução
definitiva (não "acoxambrações").
IPv6 não suporta NAT. Repetindo: não existe NAT sobre IPv6. A
bidirecionalidade é restaurada.
>- Que mal lhe pergunte. O protocolo H.323 (MSN) também se utiliza dessa
>estupidez?
Sim. O H.323 utiliza várias conexões separadas para transportar áudio e
vídeo, inclusive sobre UDP.
>E é por isso que falha, ou é somente pelo que diz o RFC 2775:
>H.323, carry IP addresses at application level and fail to traverse a
> simple NAT box correctly.
Todos os protocolos que colocam o IP nos dados transmitidos falham ao ser
transmitidos por um firewall.
Quer um exemplo? Email.
"Tente pingar minha máquina. Meu IP é 10.3.0.77."
Aquele IP acima não quer dizer absolutamente nada para alguém fora da
rede. Mesmo para aqueles que eu consigo pingar.
Suponha agora que eu precise abrir uma porta para receber um arquivo. Como
eu vou descobrir qual é o meu IP externo? Como eu vou fazer para o
firewall/NAT permitir que eu receba a conexão? É exatamente esse o
problema que o servidor de FTP em modo passivo, o cliente de FTP em modo
ativo ou um programa usando H.323 enfrentam.
- --
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEIs99M/XwBW70U1gRAkkoAKC9EulJrLSJtn/wUQhSE+wJl61XwgCfXT45
GkxNLW2DmYpjLjk3ajHvCBo=
=M+w4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------------
Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br
Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br
Regras de utilização da lista: http://linux-br.conectiva.com.br
FAQ: http://www.zago.eti.br/menu.html
