¿Es posible utilizar direcciones IP globales sin Internet?

Question 1

Es absolutamente posible: no hay nada mágico en el espacio IPV4 y todo funciona de la misma manera. Los dolores de cabeza llegarán muchos años después, cuando esta red se integre a Internet.

Answer

Es absolutamente posible: no hay nada mágico en el espacio IPV4 y todo funciona de la misma manera. Los dolores de cabeza llegarán muchos años después, cuando esta red se integre a Internet.

Question 2

Sí, es posible, pero no recomendado.

En su lugar, debe utilizar los bloques asignados por RFC1918 y una red lo más pequeña posible. Evite usar 10.0.0.0/8 para su red doméstica con un puñado de dispositivos.

Más detalles enhttps://www.rfc-editor.org/rfc/rfc1918y su reemplazohttps://www.rfc-editor.org/rfc/rfc6761

Una buena regla general es utilizar un tamaño de red de 4 veces la cantidad máxima de dispositivos que puede ejecutar en esa red, o un /24 (254 hosts), lo que sea mayor. A /24 también simplifica la creación de subredes.

Así que usa 10.yourstreetnumber.yourbirthyear.0 o 192.168.yourheightincm.0 ¡Sea creativo!

Si es probable que cree una VPN de sitio a sitio, considere el rango 172.16 a 31.0.0 como candidato, porque es un poco más complicado y, por lo tanto, se usa menos.

Otra razón para no utilizar un rango público existente es que el almacenamiento en caché de DNS podría estropear los dispositivos que cambian de red. Las computadoras portátiles, teléfonos y tabletas con IE pueden almacenar en caché "dns.google.com" como 8.8.8.8 y seguir usando ese registro una vez que se conectan a su LAN. O alguien va a casa y su nombre de host "fileserver.local" que se resuelve en 8.8.8.8 podría almacenarse en caché hasta por el TTL del registro.

Ejemplo de estúpida reutilización de IP: en los días de la estación de trabajo vmware intenté usar 127.99.99.0/24 como red IP, basándose en que era más específico que el 127.0.0.0/8 aplicado a las interfaces de bucle invertido.

Esto funcionó perfectamente para vmware y para máquinas virtuales Linux. Pero Windows (¿xp?) dijo "Detente, no" tan pronto como ingresaste 127 para el primer octeto de la dirección IP. Nunca intenté asignar direcciones IP a través de DHCP en ese momento.

Las posibilidades de consecuencias no deseadas son enormes.

Y a veces, rara vez, el networking con clase te confunde. Solía ejecutar una red que era 192.168.0.0/16 y tenía muchas cosas coexistiendo felizmente, Windows 95, XP, NT4, Linux, Mac, impresoras, etc.

Luego obtuvimos un montón de AP Linksys WRT54GL, y no aceptaban una máscara de red mayor que /24 cuando se usaba con 192.168. Esto se debe a que originalmente 192.168.0.0 se definió como

256 redes contiguas clase C

Por lo tanto, la red tenía que tener 256 hosts o menos. Esto solo apareció con algún kit de Linksys, y un flash con OpenWRT estaba feliz de usar la red /16 completa.

El resultado de esto es que /24 es más que suficiente para la mayoría de los usuarios. Un /8 o /16 es tontamente demasiado grande.

Answer

Sí, es posible, pero no recomendado.

En su lugar, debe utilizar los bloques asignados por RFC1918 y una red lo más pequeña posible. Evite usar 10.0.0.0/8 para su red doméstica con un puñado de dispositivos.

Más detalles enhttps://www.rfc-editor.org/rfc/rfc1918y su reemplazohttps://www.rfc-editor.org/rfc/rfc6761

Una buena regla general es utilizar un tamaño de red de 4 veces la cantidad máxima de dispositivos que puede ejecutar en esa red, o un /24 (254 hosts), lo que sea mayor. A /24 también simplifica la creación de subredes.

Así que usa 10.yourstreetnumber.yourbirthyear.0 o 192.168.yourheightincm.0 ¡Sea creativo!

Si es probable que cree una VPN de sitio a sitio, considere el rango 172.16 a 31.0.0 como candidato, porque es un poco más complicado y, por lo tanto, se usa menos.

Otra razón para no utilizar un rango público existente es que el almacenamiento en caché de DNS podría estropear los dispositivos que cambian de red. Las computadoras portátiles, teléfonos y tabletas con IE pueden almacenar en caché "dns.google.com" como 8.8.8.8 y seguir usando ese registro una vez que se conectan a su LAN. O alguien va a casa y su nombre de host "fileserver.local" que se resuelve en 8.8.8.8 podría almacenarse en caché hasta por el TTL del registro.

Ejemplo de estúpida reutilización de IP: en los días de la estación de trabajo vmware intenté usar 127.99.99.0/24 como red IP, basándose en que era más específico que el 127.0.0.0/8 aplicado a las interfaces de bucle invertido.

Esto funcionó perfectamente para vmware y para máquinas virtuales Linux. Pero Windows (¿xp?) dijo "Detente, no" tan pronto como ingresaste 127 para el primer octeto de la dirección IP. Nunca intenté asignar direcciones IP a través de DHCP en ese momento.

Las posibilidades de consecuencias no deseadas son enormes.

Y a veces, rara vez, el networking con clase te confunde. Solía ejecutar una red que era 192.168.0.0/16 y tenía muchas cosas coexistiendo felizmente, Windows 95, XP, NT4, Linux, Mac, impresoras, etc.

Luego obtuvimos un montón de AP Linksys WRT54GL, y no aceptaban una máscara de red mayor que /24 cuando se usaba con 192.168. Esto se debe a que originalmente 192.168.0.0 se definió como

256 redes contiguas clase C

Por lo tanto, la red tenía que tener 256 hosts o menos. Esto solo apareció con algún kit de Linksys, y un flash con OpenWRT estaba feliz de usar la red /16 completa.

El resultado de esto es que /24 es más que suficiente para la mayoría de los usuarios. Un /8 o /16 es tontamente demasiado grande.

Question 3

Si, esto se puede hacer. No, no quieres. A diferencia de otras respuestas que veo, estoy a punto de profundizar en más detalles del por qué (particularmente en mi segunda oración).

Digamos que controlas una computadora y puedes configurar su dirección IP. Y entonces escribe una dirección IP de 8.8.8.8. ¿Puedes hacer eso? Sí.

Ahora bien, el "enrutamiento" podría ser un problema (como lo explicaré más adelante en esta respuesta). Sin embargo, puede haber formas de evitarlo. Entonces, digamos que un extremo remoto se comunicó con su servidor ICMP y ejecutó "ping 8.8.8.8". ¿Respondería su servidor ICMP (normalmente integrado en componentes de software de "pila TCP/IP")? Sí. Ningún problema.

Digamos que inicia un servidor en esta computadora, como un servidor DNS. Si su computadora estuviera ejecutando un servidor DNS y recibiera la respuesta, ¿podría responder y todo podría funcionar? Sí. Ningún problema.

Digamos que inicia un servidor HTTP. Si otra computadora abrió un navegador web y terminó comunicándose con su computadora con la dirección IP, ¿podría su computadora responder y todo funcionar? Um... bueno... solía ser que la respuesta era "Sí". Pero ahora las cosas se han complicado un poco más debido a HPKP. Para más detalles, puedes verPágina web de Wikipedia sobre fijación de clave pública HTTP]. Entonces, es posible que eso no funcione tan bien. Para resumir: los navegadores web populares consideraron esto como un estilo de ataque y brindaron algunos detalles sobre los certificados/conexiones HTTPS adecuados para algunos de los principales sitios del mundo. Otra técnica relacionada puede ser la "precarga HSTS", que está relacionada con HSTS ("HTTP Strict Transport Security"). Entonces, cuando las personas instalan versiones modernas de navegadores web, esos navegadores pueden incluir algunos detalles sobre algunos sitios web. Si su sitio falso "Google" no cumple con las expectativas, el navegador puede intervenir (y presumiblemente informar al usuario final sobre un problema).

Y, como sugirió, si hace este tipo de cosas, no se podrá contactar al sitio legítimo en esta dirección IP.

Ahora, ¿por qué digo que no quieres hacer esto?

Primero, hay una solución mejor. Haga que los dispositivos dependan de DHCP. Luego, en su red local, tenga un servidor DHCP que indique lugares para usar sus servidores DNS locales, en una dirección sensible (por ejemplo, FEC0:0:0:ffff::/126 o una dirección IPv6 que comience con fd o quizás fec0: , o IPv4 utilizando los rangos de direcciones de IETF BCP 5 ("RFC 1918")). Si estandariza eso para las máquinas cliente, entonces los sistemas móviles probablemente funcionarán de forma remota y en su red local según lo desee.

El gran desafío de hacer las cosas como se espera es el enrutamiento. Si configura una dirección en 192.168.55.3/24 y otra computadora en 192.168.55.105/24 intenta comunicarse con usted, entonces las computadoras reconocerán el /24 (también conocido como máscara de subred de 255.255.255.0) y descubrirán que algo que coincida con los primeros tres octetos (que comiencen con "192.168.55.") está en la red local e intentará una comunicación directa.

Si un cliente DNS está en 192.168.55.105/24 e intenta comunicarse con 8.8.8.8, entonces la computadora reconocerá que 8.8.8.8 no coincide con los primeros tres octetos, por lo que la computadora intentará enviar el tráfico a un dispositivo de puerta de enlace. , más comúnmente una "puerta de enlace predeterminada" que envía información a Internet. (Este dispositivo de "puerta de enlace" debe estar en la red local. En términos más técnicos, la puerta de enlace debe estar en la misma subred).

Entonces, hay tres enfoques que se pueden hacer para que sus computadoras aún se comuniquen con 8.8.8.8

Podría hacer que los sistemas de sus clientes utilicen ilegítimamente el rango 8.8.8.0/24. Entonces 8.8.8.8 parecería cercano. Tenga en cuenta que esto interrumpiría las comunicaciones válidas con 8.8.8.8 y no podría usar esta estrategia simultáneamente para que sus computadoras locales también estén en el mismo rango de IP cercano que una dirección diferente.
Podrías hacer que tu sistema local use 192.168.55.105/0 en lugar de 192.168.55.105/24. Esto significa que está utilizando una máscara de subred de 0.0.0.0, por lo que ahora ha convencido efectivamente a su computadora de que 8.8.8.8 es una dirección local. Por lo tanto, las comunicaciones no irán a su "puerta de enlace predeterminada", sino que intentarán llegar a 8.8.8.8 directamente en su red local. Si tanto el cliente como el servidor están haciendo esto, probablemente funcionará.
- Sin embargo, utilizando el ejemplo extremo que se muestra aquí, lo que efectivamente ha hecho es convencer a su computadora de que todas las direcciones IP son parte de su red local. Así, este método ilegítimo ha convencido al ordenador afectado de que Internet debe ser tratado como si fuera su red local. Ahora, en lugar de interrumpir las comunicaciones con el sitio legítimo de Google en 8.8.8.8, efectivamente ha interrumpido las comunicaciones con todas las direcciones IP legítimas en Internet. Ay. Malo.
Puede configurar algún enrutamiento personalizado en su dispositivo de "puerta de enlace predeterminada", de modo que la información enviada a 8.8.8.8 sea redirigida a la dirección IP local que desee, en lugar de pasar a su proveedor de servicios de Internet.

Si bien, en teoría, el tercer enfoque podría funcionar sin demasiados problemas o efectos secundarios no deseados, el mayor inconveniente es que requiere que juegues con el enrutamiento del tráfico. Si vas a jugar con algo, te sugiero que primero lo entiendas bien.

Como alguien que entiende el enrutamiento del tráfico, sugeriría que es posible que necesite cierta experiencia para romper con éxito las conexiones legítimas que desea (al 8.8.8.8 real) y al mismo tiempo no romper las conexiones legítimas que no desea que se rompan. Y si tiene tanta experiencia para lograrlo, entonces probablemente también tenga algo de experiencia para simplemente ejecutar un servidor DNS en una dirección privada establecida. Entonces, ¿por qué no hacer las cosas de forma estandarizada, que es menos probable que cause efectos secundarios raros y raros que sean más difíciles de prever y solucionar?

En respuesta a lo que preguntaste y cómo lo preguntaste, sí, técnicamente algo como esto podría ser posible. Pero también tenga en cuenta que si la comunicación no va a donde debería ir, eso a menudo se describe como un ataque "Man In The Middle" ("MITM"). Las conexiones de los navegadores web ya han evolucionado para ayudar a HKPK a derrotar tales travesuras. Un hecho menos conocido es que DNS ha sido reemplazado en gran medida por el uso de EDNS (usando "mecanismos de extensión para DNS"), y un hecho más conocido es que existen algunas mejoras más nuevas en la seguridad de DNS llamadas DNSSec. Si no estaba al tanto de esto, entonces tenga en cuenta que los mantenedores actuales de códigos de software populares basados en Internet podrían estar ya muy por delante de usted, por lo que es posible que desee tener esto en cuenta antes de intentar incluir un "ataque MITM" como una parte fundamental de algún tipo de diseño nuevo y elegante de cualquier red que supervise.

Entonces, para resumir, la razón principal por la que creo que no desea hacer esto para una red real (en lugar de un laboratorio de pruebas donde está explorando posibilidades) es simplemente que, para lograr objetivos legítimos útiles, existe una mejor manera. . Es decir, cuando intentas diseñar cómo se comporta tu red, haz las cosas de la manera correcta. Es probable que experimentes menos dolor en general.

Para volver a aclarar en caso de que esto se haya olvidado, la "forma correcta" a la que me refiero es simplemente operar su servidor DNS local en una dirección privada, sin engañar a nadie, y alentar a las computadoras a usar la dirección privada local o confiar en DHCP. y haga que sus servidores DHCP locales le indiquen a los dispositivos que confíen en su servidor DNS local. Es un estilo de diseño más honesto que no interrumpe la capacidad de comunicarse con un sitio público y cuenta con un amplio respaldo, por lo que es menos probable que quienes mantienen los estándares de Internet hagan algo que rompa un diseño tan legítimo en muchas redes locales utilizadas en todo el mundo. mundo.

Answer

Si, esto se puede hacer. No, no quieres. A diferencia de otras respuestas que veo, estoy a punto de profundizar en más detalles del por qué (particularmente en mi segunda oración).

Digamos que controlas una computadora y puedes configurar su dirección IP. Y entonces escribe una dirección IP de 8.8.8.8. ¿Puedes hacer eso? Sí.

Ahora bien, el "enrutamiento" podría ser un problema (como lo explicaré más adelante en esta respuesta). Sin embargo, puede haber formas de evitarlo. Entonces, digamos que un extremo remoto se comunicó con su servidor ICMP y ejecutó "ping 8.8.8.8". ¿Respondería su servidor ICMP (normalmente integrado en componentes de software de "pila TCP/IP")? Sí. Ningún problema.

Digamos que inicia un servidor en esta computadora, como un servidor DNS. Si su computadora estuviera ejecutando un servidor DNS y recibiera la respuesta, ¿podría responder y todo podría funcionar? Sí. Ningún problema.

Digamos que inicia un servidor HTTP. Si otra computadora abrió un navegador web y terminó comunicándose con su computadora con la dirección IP, ¿podría su computadora responder y todo funcionar? Um... bueno... solía ser que la respuesta era "Sí". Pero ahora las cosas se han complicado un poco más debido a HPKP. Para más detalles, puedes verPágina web de Wikipedia sobre fijación de clave pública HTTP]. Entonces, es posible que eso no funcione tan bien. Para resumir: los navegadores web populares consideraron esto como un estilo de ataque y brindaron algunos detalles sobre los certificados/conexiones HTTPS adecuados para algunos de los principales sitios del mundo. Otra técnica relacionada puede ser la "precarga HSTS", que está relacionada con HSTS ("HTTP Strict Transport Security"). Entonces, cuando las personas instalan versiones modernas de navegadores web, esos navegadores pueden incluir algunos detalles sobre algunos sitios web. Si su sitio falso "Google" no cumple con las expectativas, el navegador puede intervenir (y presumiblemente informar al usuario final sobre un problema).

Y, como sugirió, si hace este tipo de cosas, no se podrá contactar al sitio legítimo en esta dirección IP.

Ahora, ¿por qué digo que no quieres hacer esto?

Primero, hay una solución mejor. Haga que los dispositivos dependan de DHCP. Luego, en su red local, tenga un servidor DHCP que indique lugares para usar sus servidores DNS locales, en una dirección sensible (por ejemplo, FEC0:0:0:ffff::/126 o una dirección IPv6 que comience con fd o quizás fec0: , o IPv4 utilizando los rangos de direcciones de IETF BCP 5 ("RFC 1918")). Si estandariza eso para las máquinas cliente, entonces los sistemas móviles probablemente funcionarán de forma remota y en su red local según lo desee.

El gran desafío de hacer las cosas como se espera es el enrutamiento. Si configura una dirección en 192.168.55.3/24 y otra computadora en 192.168.55.105/24 intenta comunicarse con usted, entonces las computadoras reconocerán el /24 (también conocido como máscara de subred de 255.255.255.0) y descubrirán que algo que coincida con los primeros tres octetos (que comiencen con "192.168.55.") está en la red local e intentará una comunicación directa.

Si un cliente DNS está en 192.168.55.105/24 e intenta comunicarse con 8.8.8.8, entonces la computadora reconocerá que 8.8.8.8 no coincide con los primeros tres octetos, por lo que la computadora intentará enviar el tráfico a un dispositivo de puerta de enlace. , más comúnmente una "puerta de enlace predeterminada" que envía información a Internet. (Este dispositivo de "puerta de enlace" debe estar en la red local. En términos más técnicos, la puerta de enlace debe estar en la misma subred).

Entonces, hay tres enfoques que se pueden hacer para que sus computadoras aún se comuniquen con 8.8.8.8

Podría hacer que los sistemas de sus clientes utilicen ilegítimamente el rango 8.8.8.0/24. Entonces 8.8.8.8 parecería cercano. Tenga en cuenta que esto interrumpiría las comunicaciones válidas con 8.8.8.8 y no podría usar esta estrategia simultáneamente para que sus computadoras locales también estén en el mismo rango de IP cercano que una dirección diferente.
Podrías hacer que tu sistema local use 192.168.55.105/0 en lugar de 192.168.55.105/24. Esto significa que está utilizando una máscara de subred de 0.0.0.0, por lo que ahora ha convencido efectivamente a su computadora de que 8.8.8.8 es una dirección local. Por lo tanto, las comunicaciones no irán a su "puerta de enlace predeterminada", sino que intentarán llegar a 8.8.8.8 directamente en su red local. Si tanto el cliente como el servidor están haciendo esto, probablemente funcionará.
- Sin embargo, utilizando el ejemplo extremo que se muestra aquí, lo que efectivamente ha hecho es convencer a su computadora de que todas las direcciones IP son parte de su red local. Así, este método ilegítimo ha convencido al ordenador afectado de que Internet debe ser tratado como si fuera su red local. Ahora, en lugar de interrumpir las comunicaciones con el sitio legítimo de Google en 8.8.8.8, efectivamente ha interrumpido las comunicaciones con todas las direcciones IP legítimas en Internet. Ay. Malo.
Puede configurar algún enrutamiento personalizado en su dispositivo de "puerta de enlace predeterminada", de modo que la información enviada a 8.8.8.8 sea redirigida a la dirección IP local que desee, en lugar de pasar a su proveedor de servicios de Internet.

Si bien, en teoría, el tercer enfoque podría funcionar sin demasiados problemas o efectos secundarios no deseados, el mayor inconveniente es que requiere que juegues con el enrutamiento del tráfico. Si vas a jugar con algo, te sugiero que primero lo entiendas bien.

Como alguien que entiende el enrutamiento del tráfico, sugeriría que es posible que necesite cierta experiencia para romper con éxito las conexiones legítimas que desea (al 8.8.8.8 real) y al mismo tiempo no romper las conexiones legítimas que no desea que se rompan. Y si tiene tanta experiencia para lograrlo, entonces probablemente también tenga algo de experiencia para simplemente ejecutar un servidor DNS en una dirección privada establecida. Entonces, ¿por qué no hacer las cosas de forma estandarizada, que es menos probable que cause efectos secundarios raros y raros que sean más difíciles de prever y solucionar?

En respuesta a lo que preguntaste y cómo lo preguntaste, sí, técnicamente algo como esto podría ser posible. Pero también tenga en cuenta que si la comunicación no va a donde debería ir, eso a menudo se describe como un ataque "Man In The Middle" ("MITM"). Las conexiones de los navegadores web ya han evolucionado para ayudar a HKPK a derrotar tales travesuras. Un hecho menos conocido es que DNS ha sido reemplazado en gran medida por el uso de EDNS (usando "mecanismos de extensión para DNS"), y un hecho más conocido es que existen algunas mejoras más nuevas en la seguridad de DNS llamadas DNSSec. Si no estaba al tanto de esto, entonces tenga en cuenta que los mantenedores actuales de códigos de software populares basados en Internet podrían estar ya muy por delante de usted, por lo que es posible que desee tener esto en cuenta antes de intentar incluir un "ataque MITM" como una parte fundamental de algún tipo de diseño nuevo y elegante de cualquier red que supervise.

Entonces, para resumir, la razón principal por la que creo que no desea hacer esto para una red real (en lugar de un laboratorio de pruebas donde está explorando posibilidades) es simplemente que, para lograr objetivos legítimos útiles, existe una mejor manera. . Es decir, cuando intentas diseñar cómo se comporta tu red, haz las cosas de la manera correcta. Es probable que experimentes menos dolor en general.

Para volver a aclarar en caso de que esto se haya olvidado, la "forma correcta" a la que me refiero es simplemente operar su servidor DNS local en una dirección privada, sin engañar a nadie, y alentar a las computadoras a usar la dirección privada local o confiar en DHCP. y haga que sus servidores DHCP locales le indiquen a los dispositivos que confíen en su servidor DNS local. Es un estilo de diseño más honesto que no interrumpe la capacidad de comunicarse con un sitio público y cuenta con un amplio respaldo, por lo que es menos probable que quienes mantienen los estándares de Internet hagan algo que rompa un diseño tan legítimo en muchas redes locales utilizadas en todo el mundo. mundo.

Question 4

En teoría, eso debería estar bien.

En la práctica:

Puede romper los supuestos de terceros.
Es posible que utilice software/hardware que asuma que se cumplirán ciertas convenciones de IP bien conocidas, lo que provocará comportamientos no deseados cuando infrinja estas suposiciones.
Puede desencadenar errores ocultos.
Algunos programas con errores funcionan bien en la mayoría de los casos, pero detalles extraños pueden desencadenarlos. Estos errores pueden corregirse cuando se detectan, pero si utiliza una configuración no estándar, puede aumentar la posibilidad de encontrar errores que nadie más ha tenido la oportunidad de encontrar antes.
Puede confundir a otras personas que trabajan con su red.
Incluso si te parece bien recordar que eso 8.8.8.8significa algo más en tu red interna, esto podría confundir a los demás. Los compañeros de trabajo, el soporte técnico, las personas que leen un registro que podrías compartir en un foro de ayuda, etc., pueden tener problemas con él.
Puede crear contradicciones en los cachés.
Si algún dispositivo en su red estuvo previamente conectado a Internet global, es posible que tenga direcciones IPv4 almacenadas en su configuración, reglas de firewall, etc., lo que podría causar colisiones no deseadas cuando se unan a la red local.

En teoría, es posible que los errores y los diseños deficientes de terceros no sean culpa suya. Pero en la práctica,Podrías empezar a creer en fantasmas..

Answer

En teoría, eso debería estar bien.

En la práctica:

Puede romper los supuestos de terceros.
Es posible que utilice software/hardware que asuma que se cumplirán ciertas convenciones de IP bien conocidas, lo que provocará comportamientos no deseados cuando infrinja estas suposiciones.
Puede desencadenar errores ocultos.
Algunos programas con errores funcionan bien en la mayoría de los casos, pero detalles extraños pueden desencadenarlos. Estos errores pueden corregirse cuando se detectan, pero si utiliza una configuración no estándar, puede aumentar la posibilidad de encontrar errores que nadie más ha tenido la oportunidad de encontrar antes.
Puede confundir a otras personas que trabajan con su red.
Incluso si te parece bien recordar que eso 8.8.8.8significa algo más en tu red interna, esto podría confundir a los demás. Los compañeros de trabajo, el soporte técnico, las personas que leen un registro que podrías compartir en un foro de ayuda, etc., pueden tener problemas con él.
Puede crear contradicciones en los cachés.
Si algún dispositivo en su red estuvo previamente conectado a Internet global, es posible que tenga direcciones IPv4 almacenadas en su configuración, reglas de firewall, etc., lo que podría causar colisiones no deseadas cuando se unan a la red local.

En teoría, es posible que los errores y los diseños deficientes de terceros no sean culpa suya. Pero en la práctica,Podrías empezar a creer en fantasmas..

¿Es posible utilizar direcciones IP globales sin Internet?

Respuesta1

Respuesta2

Respuesta3

Respuesta4

información relacionada