Há algum tempo que tenho ignorado amplamente o protocolo STUN como ruído, mas continuo encontrando-o aqui e ali e estou me perguntando sobre sua usabilidade geral.
Se bem entendi, STUN só é útil se o NAT mais externo permitir pacotes enviados de addr:portpar diferente do que a fonte usou ao estabelecer o mapeamento.
Eu tive uma compreensão obviamente delirante de que um NAT sensato só permitirá pacotes de retorno do mesmo addr:portpar ao qual uma conexão foi estabelecida (Filtragem Dependente de Endpoint). Não fazer cumprir isso parece ser um sério problema de segurança por si só. Construir protocolos e RFCs inteiros em cima disso parece uma loucura.
Questões:
- Existem realmente muitos NATs que fazem apenas filtragem independente de endpoint?
- Existe alguma boa razão para fazer a filtragem independente de endpoint em um NAT além de ser preguiçoso, colocar em risco os sistemas por trás dele e cobrar $$ extras por um recurso "compatível com p2p"?
Responder1
O NAT não pretende ser um recurso de segurança - é um hack para evitar a falta de endereços IPv4, como um paliativo até que o IPv6 seja totalmente implantado. Como tal, faz sentido implementá-lo de uma forma que maximize a utilidade em vez da segurança.
Como tal, a premissa da sua pergunta número 2 está errada, uma vez que o NAT não se destina a ser um dispositivo de segurança. Se impor que o endpoint remoto seja sempre o mesmo interrompe até mesmo um aplicativo, eu consideraria mais sensato não impor o mesmo endpoint remoto, dados os objetivos da tecnologia.
A telefonia IP peer-to-peer (como o Skype) seria um exemplo notável de um aplicativo legítimo que não funcionaria bem sem a capacidade de perfurar NAT:s, seja por STUN ou tecnologias similares que exploram o comportamento de NAT:s, ou através de tecnologias como UPnP.