¿Cómo evito el reenvío de puertos al exponer dispositivos IoT a Internet externo?

15

Recibí algunas buenas respuestas en la pregunta ¿Qué necesito para crear mi propia nube personal para dispositivos IoT? y una de las cosas que entendí desde allí es que necesito "exponer" mi HUB o GATEWAY a internet externo. La solución propuesta para eso es el reenvío de puertos .

Creé esto como una pregunta separada porque sería difícil hacer un seguimiento adecuado solo con comentarios sobre todas las respuestas, alguien podría perderse. Además, esta información puede ser útil para alguien con una pregunta similar.

No me gusta la idea de tener que ir a la configuración de mi enrutador y configurar el reenvío de puertos porque eso significa que tengo que configurar un dispositivo que, a pesar de ser parte de la infraestructura de IoT, no es uno de "mis" dispositivos. Tiene que ser lo menos perjudicial posible para la red doméstica ya existente. Además, he tenido casos en los que no conozco la contraseña de administrador de un enrutador en particular y ha sido realmente difícil obtenerla.

Estoy seguro de que hay una forma de evitarlo, incluso si eso significa tener un IoT HUB más poderoso que tal vez ejecute Linux, simplemente no sé qué podría ser eso. Está bien tener un HUB un poco más complejo si esa forma "alternativa" permite evitar esa configuración de reenvío de puertos.

Digo que estoy seguro de que hay una manera de pensar acerca de cómo las aplicaciones como el visor de equipos no necesitan configurar el reenvío de puertos.

Entonces, la pregunta es, ¿alguien conoce una forma de "exponer" un dispositivo integrado de IoT a Internet externo para acceder a él desde cualquier parte del mundo que no implique el reenvío de puertos?

smart-home networking m4l490n
fuente

Respuestas:

10

Si no puede reenviar su enrutador, puede que tenga que recurrir a la perforación :

La perforación de agujeros es una técnica en redes de computadoras para establecer una conexión directa entre dos partes en las que uno o ambos están detrás de firewalls o enrutadores que usan traducción de direcciones de red (NAT). Para perforar un agujero, cada cliente se conecta a un servidor de terceros sin restricciones que almacena temporalmente la dirección externa e interna y la información del puerto para cada cliente. El servidor luego transmite la información de cada cliente al otro, y utilizando esa información cada cliente intenta establecer una conexión directa; Como resultado de las conexiones que utilizan números de puerto válidos, los firewalls o enrutadores restrictivos aceptan y reenvían los paquetes entrantes en cada lado.

El NAT en su enrutador significa que los clientes fuera de su red no pueden conectarse a puertos abiertos de dispositivos dentro de su red, pero no restringe la conexión de los dispositivos en su red a un 'intermediario'. Usando un poco de indirección , puede establecer una conexión directa entre dos dispositivos sin abrir ningún puerto; esto es esencialmente lo que hacen servicios como Skype y Hamachi.

Por supuesto, esto requiere un servidor externo para coordinar la conexión, y probablemente desee confiar en el servidor que estaba realizando la perforación.

La comunicación entre pares a través de traductores de direcciones de red por Bryan Ford, Pyda Srisuresh y Dan Kegel es una lectura interesante para obtener más información sobre los mecanismos de perforación y cuán confiable es.

Aurora0001
fuente
¡Maravilloso! Una pregunta, sin embargo, ¿puede ese servidor de terceros o "corredor" también estar dentro de mi casa? ¿Y ser, por ejemplo, una placa Linux integrada? Porque de lo contrario, este enfoque introduciría un problema aún mayor al hablar de tener elementos externos de terceros en la implementación de IoT. Si una placa Linux integrada no puede ser esto, entonces ¿cuál sería?
m4l490n
3
@ m4l490n: Tendría que estar fuera de su red de alguna manera. Me imagino que podría ser un servidor en la nube en algún lugar, o podría usar la placa Linux si ese fuera el puerto reenviado. La perforación de agujeros UDP solo funciona cuando tiene un servidor / dispositivo que es accesible públicamente en Internet en algún lugar. No es lo ideal, pero no puede evitar el hecho de que algo debe estar en Internet públicamente para conectarse. Sospecho que una placa Linux integrada en su red doméstica no ofrecería ninguna ventaja; solo tiene que reenviar eso en lugar de su dispositivo IoT.
Aurora0001
1
¡Excelente! ¡Aunque no fue la intención directa de su respuesta y no la intención original de mi pregunta, finalmente entiendo el papel de un servidor en la nube en una infraestructura de IoT !.
m4l490n
Si entiendo, el agujero es virtual, a diferencia del reenvío de puertos donde se modifica el estado del enrutador. ¿Cada extremo del enlace solo se comunica con el servidor? Entonces, este sería el modelo típico para IoT, creo, ya que la red general es de muchos a muchos.
Sean Houlihane
7

En el mundo de IoT, donde los dispositivos tienen pocos recursos para manejar el tráfico no deseado de conexiones externas y, por supuesto, la necesidad de manejar cualquier reenvío de puertos y problemas de firewall con enrutadores ha llevado al siguiente enfoque que puede ver en muchas soluciones de back-end de IoT:

Los dispositivos no aceptarán ninguna información de red no solicitada. Todas las conexiones y rutas serán establecidas por el dispositivo solo de manera saliente. Por lo tanto, el dispositivo abrirá conexiones salientes, por lo que no se necesitarán ajustes de firewall / enrutador y mantendrá el canal abierto todo el tiempo que sea necesario.

Un buen artículo sobre los problemas y soluciones de comunicación en el mundo de IoT.

shachar
fuente
Para MQTT, el dispositivo es un cliente (editor o suscriptor o ambos) e inicia la conexión con el agente (servidor).
Gambit Support
"los dispositivos tienen pocos recursos para manejar el tráfico no deseado de las conexiones salientes " ???? Eso no tiene sentido en absoluto. Las conexiones salientes solo pueden iniciarse dentro de la red.
Chris Stratton
@ChrisStratton, las conexiones salientes se pueden dirigir directamente a los dispositivos mediante el reenvío de puertos si se está utilizando NAT. También pueden tener su propia IP y se puede acceder directamente desde Internet.
shachar
Parece que está malinterpretando el significado de la palabra "saliente" y usándolo erróneamente donde lo que realmente quiere decir es "entrante". Y la conexión saliente es un dispositivo IoT que llega a un servidor en la nube. Una conexión entrante es algo que está fuera de su red doméstica (por ejemplo, su teléfono, mientras camina por la calle) que intenta conectarse a un dispositivo dentro de su red.
Chris Stratton
@ ChrisStratton, Tienes razón, cuando escribí saliente me refería al tráfico del exterior, que es básicamente la conexión "Entrante" para el sensor. He editado mi respuesta, gracias
shachar
3

Intenta tocar el puerto . Todavía tiene que reenviar el puerto, pero el puerto solo se abre después de enviar una combinación secreta (que elija) de pings. Luego puede cerrar el puerto con otro combo secreto de pings. Puede ejecutarse en Linux integrado, como un enrutador wifi con OpenWrt.

GusGorman402
fuente
3

Si bien no puedo recomendar que permita que cualquier dispositivo IoT sea accesible desde Internet público, puede lograrlo de forma nativa utilizando IPv6.

Si su ISP y su red local están configurados para IPv6, y sus dispositivos IoT lo admiten, pueden obtener automáticamente una dirección IPv6 que se puede enrutar desde cualquier lugar en Internet (IPv6 elimina la necesidad de NAT y reenvío de puertos). Solo debe asegurarse de que los firewalls con estado (su enrutador) estén configurados para permitir el tráfico a cada dispositivo. Algunos pueden permitir esto (de forma insegura) por defecto.

multithr3at3d
fuente
2

Configure un servidor VPN en casa, luego conéctese a él desde cualquier lugar. Creo que esto sería mucho más seguro que exponer cualquier tipo de dispositivo IoT a Internet abierto.

Maurice
fuente
¿No es solo una especie de puerta de enlace?
Helmar
hm? Una VPN es una conexión punto a punto (generalmente encriptada) entre un dispositivo y una red. hace que el dispositivo de conexión actúe como si fuera parte de la red. Supongo que podrías pensar en ello como una puerta de enlace ... pero es un servicio.
Maurice
Claro, pero ese servicio todavía tiene que pasar el enrutador doméstico, generalmente a través del reenvío de puertos o conexiones salientes sin parar.
Helmar
sí, aún necesitarías reenviar el puerto en el que se ejecuta la VPN. pero es más seguro que exponer dispositivos individuales (aunque potencialmente menos conveniente, dependiendo de lo que intente lograr)
Maurice