He estado ignorando en gran medida el protocolo STUN como ruido por un tiempo, pero lo sigo encontrando aquí y allá, y me pregunto sobre su usabilidad general.
Si lo entiendo bien, STUN solo es útil si la NAT más externa permite paquetes enviados desde addr:portun par que el que utilizó la fuente al establecer el mapeo.
Obviamente tenía una idea delirante de que una NAT sensata solo permitirá devolver paquetes del mismo addr:portpar con el que se estableció una conexión (filtrado dependiente del punto final). No hacer cumplir esto parece ser un problema de seguridad grave en sí mismo. Crear protocolos completos y RFC además de eso parece una locura.
Preguntas:
- ¿Existen realmente muchas NAT que solo realizan filtrado independiente del punto final?
- ¿Existe alguna buena razón para realizar un filtrado independiente del punto final en una NAT además de ser perezoso, poner en peligro los sistemas detrás de él y cobrar $$ extra por una función "compatible con p2p"?
Respuesta1
NAT no pretende ser una característica de seguridad: es un truco para evitar quedarse sin direcciones IPv4, como un recurso provisional hasta que IPv6 esté completamente implementado. Como tal, tiene sentido implementarlo de manera que maximice la utilidad en lugar de la seguridad.
Como tal, la premisa de su pregunta número 2 es incorrecta, ya que NAT no pretende ser un dispositivo de seguridad. Si exigir que el punto final remoto sea siempre el mismo interrumpe incluso una aplicación, consideraría más sensato no imponer el mismo punto final remoto, dados los objetivos de la tecnología.
La telefonía IP punto a punto (como Skype) sería un ejemplo notable de una aplicación legítima que no funcionaría bien sin la capacidad de perforar agujeros en los NAT, ya sea mediante STUN o tecnologías similares que explotan el comportamiento de NAT:s, o mediante tecnologías como UPnP.