¿Por qué se dice que es difícil ejecutar servidores en casa debido a la traducción de direcciones de red?

El diseño original de los protocolos de Internet supone que cada nodo tiene una dirección IP única (algo así como un número de teléfono). Sin embargo, debido a la forma en que se asignaron las direcciones IP, y debido a que el número de direcciones disponibles es menor que el número de hosts en la red, se hizo necesario que varios hosts compartieran una dirección IP. Una red doméstica típica se alquila una sola Dirección IP por su ISP. Esta dirección es visible para todo internet. Dentro de la red doméstica, las direcciones se asignan a nodos individuales de un grupo de direcciones que Internet no reenvía. Estas se llaman direcciones privadas y se puede usar el mismo conjunto de direcciones IP en cualquier red privada sin crear un conflicto de direcciones. Para que este esquema funcione, el enrutador de la casa (dispositivo orientado a ISP) debe traducirse entre la dirección externa y las direcciones locales. Esto se realiza monitoreando los números de puerto TCP y UDP de origen y destino y sustituyendo las direcciones IP internas correctas por los paquetes entrantes y reemplazando las direcciones internas con la dirección externa por los paquetes salientes. Este sistema de sustitución se llama NAT (traducción de direcciones de red). Para los paquetes salientes, el proceso es sencillo. Para los paquetes entrantes destinados a un servicio en particular, es necesario informar a la configuración NAT qué direcciones IP internas están acopladas con números de puerto específicos. Por ejemplo, los paquetes destinados a una dirección xx.xx.xx.xx: 80 normalmente se enviarían a un host que escucha en el puerto 80 las solicitudes HTTP (solicitudes web). Si hay un servidor SSH (shell seguro), estaría escuchando en el puerto 22. Tener dichos servidores disponibles en una red privada requiere la configuración manual del servicio NAT. Finalmente, dado que la traducción que utiliza puertos bien conocidos dirige el tráfico a una máquina específica, es posible tener solo una instancia de un servicio específico, es decir, un número de puerto, para acceso externo en la red local.

Eso se dice por error. NAT casi nunca es un problema al ejecutar un servidor doméstico porque su enrutador se puede configurar para reenviar, pero luego, defina “servidor”: si es solo un servidor web o un intercambio de correo, no es un problema, pero si desea pasar RTP de ida y vuelta, o use cualquier tipo de túnel, algunas formas de NAT pueden ser difíciles de penetrar.

Lo que es un pequeño problema para un servicio web doméstico (o algo confiable) es el direccionamiento dinámico utilizado por la mayoría de los proveedores residenciales en estos días. Eso significa que debe poder descubrir qué dirección tiene su enrutador cuando desea conectarse a él. La única forma de hacerlo es haciendo que su servidor (o el enrutador, o cualquier cosa en su red doméstica) envíe actualizaciones periódicas a una máquina externa que pueda reenviar esas actualizaciones a un DNS público o proporcionar un mecanismo de consulta que pueda utilícelo en caso de que no desee que esa información sea pública. El problema de mantener su dirección actual externamente es casi siempre que necesita usar el recurso de otra persona y que alguien quiere cobrarle por ello. Usé DynDNS durante muchos años, hasta que mataron a su servicio gratuito; ahora uso NoIP, tolerando solicitudes de confirmación mensuales para cada una de las tres ubicaciones que administro, acompañadas de ofertas de servicio sin hostigamiento por una tarifa. Cuando se haya ido, no sé qué haré. No estoy de humor para pagar a terceros por algo que mi proveedor de “internet” me quitó.

De todos modos, eso es solo una pequeña molestia, y si puede solucionarlo, no habrá problemas para hablar. Múltiples servidores: no es un problema, ya sea que desee ejecutarlos como varios servicios en la misma máquina o en máquinas diferentes. Configura algo como nginx como proxy inverso para todos ellos y hace que estas configuraciones estén basadas en nombres. De esa manera, puede direccionar todos sus servicios en el mismo puerto, independientemente del puerto en el que realmente escuchen dónde se ejecutan. Tengo un par de docenas de servicios web en mi máquina doméstica; Son discriminados por su nombre.

No es particularmente difícil, lo he hecho durante años. No escala bien porque la mayoría de las conexiones residenciales son muy asimétricas (mayor ancho de banda de descarga que carga), y eso está integrado en el hardware, no solo en su plan de pago: los módems de cable usan una banda de frecuencia diferente para cada uno, por ejemplo. Ese es el camino equivocado para un servidor: significa que el ancho de banda de descarga total para todos los usuarios conectados es de solo 500 kbps o la velocidad de carga.

(Utilizo una caja de Linux con una dirección de Internet pública como servidor, y también la uso como un enrutador NAT / DHCP / DNS para mi red local, pero eso es en parte porque no podía comprar enrutadores domésticos cuando me conecté por primera vez en línea con ISDN hace 20 años y no puedo molestarme en cambiar. El reenvío de puertos funciona lo suficientemente bien como para ejecutar un servidor web)

Solo que cualquier cosa en el extremo LAN de un NAT no tiene una dirección IP “verdadera”. El enrutador es lo único conectado directamente a Internet. El reenvío de puertos es el mecanismo normal para colocar un servidor detrás de un NAT en Internet. Entonces, por ejemplo, reenvía el puerto 80 (HTTP) a su servidor web. Cuando alguien navega a la dirección IP de su enrutador, continúa y lo entrega a su servidor web que luego responde.

El problema con eso es, por ejemplo, decir que quiere poner dos servidores web en Internet. Básicamente, debe hacer algo como el puerto hacia adelante 80 a web1: 80 y (por ejemplo) 8080 a web2: 80. No es muy elegante: esencialmente ha cambiado una IP para apuntar a tres cajas diferentes según el puerto utilizado. Sin mencionar que las IP en el extremo de la LAN no son lo mismo que el extremo de la WAN (en el ejemplo en su red local, iría a web2: 80 en lugar de 8080).

IPv6, por supuesto, resuelve estos problemas, pero quién sabe cuándo será realmente frecuente …