1. Introducción
Un problema muy frecuente a la hora de montar nuestros propios servidores (web,ftp…) es, que la acceder a ellos desde dentro de la LAN pongamos nuestra IP pública… y nos salga al página de configuración del router.
¿Que es lo que se trata en este tutorial? Como solucionar la situación en la que, teniendo un servidor en nuestra red de área local, podemos acceder a él perfectamente desde fuera de la LAN mediante la IP pública o un dominio registrado, pero desde dentro de la LAN no.
Como el tema se postea periodicamente y la respuesta es relativamente larga edito esta mini-guía medio teórica medio práctica para uso y consumo del personal.
En una red como la siguiente:
code:
<<<------------------------------ NAT: El router redirige puertos solo en este sentido. <<<------------------------------
[PC_A]—-| [Router]—-(inet) [PC_B]—-| ^ ^ | | | Router: LAN_IP = 192.168.2.1 | WAN_IP = 1.2.3.4 PC A = 192.168.2.2 PC B = 192.168.2.3
El fallo habitual es pensar “esto lo arreglo yo con NAT”, cosa que NO funcionará:
NAT es el acrónimo de Network Address Translation: traducción de direcciones. Esto es, adapta las peticiones entrantes desde la interfaz WAN al plan de direccionamiento de nuestra LAN. Por lo tanto, no afecta en absoluto a peticiones de conexión que tengan su origen en la LAN.
Otro error muy común: “bueno, pues tocando otra cosilla del router seguro que tira bien”. Tampoco vale.
Vamos a ver como solucionar esto. Las soluciones se muestran en orden de complejidad. Que cada uno decida cual se ajusta mejor a sus necesidades.
2. Solución #1: usando un Proxy
El problema es que, tal y como está nuestra red, solo funcionan las peticiones al servidor desde el exterior… entonces accedamos desde fuera, mediante un proxy.
Lo primero es buscar uno que funcione. Ver los siguientes enlaces:
1- Proxy4Free
2- Antiproxy.Proxy search
Y configurarlo como proxy en nuestro navegador, cliente FTP… Esto hará que el esquema de conexión sea:
code:
[PC]----------->[Router]-------->| [Proxy] [Server]<-------[Router]<--------|
Todas las peticiones se envían al proxy, y es este el que se conecta al extremo final. Por lo que el router ahora sí que realizará NAT correctamente hacia nuestro servidor local.
Si nos paramos a pensar un poco, esto es muy ineficiente:
– Estamos consumiendo ancho de banda de nuestra línea ADSL para una página que está alojada en nuestra red local.
– Además es más lento (mucho más lento), menos seguro (salvo que usemos la versión cifrada de http, https) y, si nuestra red es grande, un auténtico engorro para configurarlo en cada equipo.
3. Un nivel más de abstracción: registro DNS
Las siguiente soluciones requieren que tengamos registrado un dominio o nombre DNS. Esto cuesta dinero pero podemos hacer un apaño mediante DDNS, registrandonos de manera gratuita en DynDNS,No-IP,freedns,…
Se requerirá que instalemos un software cliente en nuestro equipo que informe al servidor DDNS de nuestra nueva IP pública cada vez que cambie.
La mayor diferencia entre un auténtico dominio registrado (midominio.com) y uno DDNS (usuario.dyndns.org) es que , mientras que con nuestro dominio podemos hacer consultas del tipo:
dominio -> IP (resolución típica del nombre)
IP -> dominio (reverse)
con DDNS, en principio, solo podremos hacer:
nombre -> IP.
4. Solución #2: Archivo HOSTS
Una vez hecho lo anterior, editamos el archivo :
%windir%\system32\drivers\etc\HOSTS
añadiendo la siguiente entrada:
code:
ip_local_servidor dominio
P.ej, servidor local en 192.168.2.2, dominio registrado usuario.dyndns.org Añadimos:
code:
192.168.2.2 usuario.dyndns.org
Idem. para linux y /etc/hosts
De esta manera, y solo en la máquina donde hemos hecho la modificación, esa url es resuelta a la IP local del servidor (en realidad no se lanza petición DNS siquiera).
La ventaja que esta solución tiene sobre la del proxy es que ya no consumimos ancho de banda en la línea ADSL. Sin embargo, sigue resultando una solución incómoda para redes relativamente grandes y poco escalable ante la incorporación de equipos.
5. Solución #3: DNS (+vistas)
La idea de esto es montar nuestro propio servidor DNS para resolución de nombres.
Lo que queremos hacer es, en el caso más general,que según el ámbito de donde provenga la petición (LAN o internet), resuelva el nombre de nuestro dominio a una IP u otra:
– Si la petición viene de la LAN, dominio resuelto a IP local del servidor.
– Si viene de internet, dominio resuelto a IP pública.
Asimismo, el servidor debe resolver las demas peticiones de nuestra red, comunicándose con los servidores DNS que teníamos configurados como primario y secundario (los del ISP).
Está bastante claro ¿no? manos a la obra…
Como servidor DNS usaremos Bind. Están disponibles las fuentes y el binario para windows NT/2K ( BIND 9.2.3 ). Para windows 98/Me … no es válido.
5.1 Instalando Bind
– Descomprimimos el fichero anterior en una carpeta temporal y ejecutamos BINDInstall.exe. El programa se instalará por defecto en %windir%\system32\dns
– Allí tendremos una carpeta bin con los ejecutables necesarios y una etc, para ficheros de configuración.
5.2 Configurando Bind
%WINDIR%\SYSTEM32\dns\bin:
named.exe – servidor BIND. Para las pruebas usaremos desde la consola named -g. Luego ya podremos hacer uso del servicio de sistema:
Herramientas Administrativas -> Servicios -> ISC Bind , poniéndolo en tipo de inicio automático.
rndc.exe – este programa puede usarse para arrancar/detener el servidor
named-checkzone.exe – para comprobar la sintaxis de los ficheros de zona.
named-checkconf.exe – para comporbar la sintaxis de los ficheros .conf
%WINDIR%\SYSTEM32\dns\etc:
named.conf – fichero principal de configuración
rndc.conf – clave de autenticación para rndc.exe. Lo generamos automáticamente mediante:
rndc-confgen.exe > %windir%\system32\dns\etc\rndc.conf
named.ca – DNS root servers.
db.midominio.com.internal – fichero de zona.
db.midominio.com.external – fichero de zona.
127.0.0.rev – fichero de zona (reverse IP)
192.168.2.rev – fichero de zona (reverse IP)
Adjunto una plantilla para cada fichero de configuración necesario:
5.2.1 Named.conf
– Suponemos nuestra red local con direcciones tipo 192.168.2.x y máscara 255.255.255.0 (192.168.2.0/24),
– El servidor (del tipo que sea) funcionando en PC_A (192.168.2.2).
– Dominio registrado midominio.dyndns.org.
-> Cambiar los datos del fichero de manera acorde a nuestra situación.
OJO:
– Editar también IP_DNS_Primario e IP_DNS_Secundario por los de nuestro ISP (o los que sea).
– Poner la clave secret del fichero rndc.conf
code:
/* BIND9 main configuration file with master zone statements: named.conf */options { directory “c:\winnt\system32\dns\etc”; recursion yes; allow-recursion {192.168.2.0/24;}; forward only; forwarders {IP_DNS_Primario; IP_DNS_secundario;}; allow-transfer {IP_DNS_Primario; IP_DNS_secundario;}; version “”; auth-nxdomain no; # conform to RFC1035 };
logging { channel my_file {file “c:\winnt\system32\dns\etc\named.run”; severity debug; print-time yes; }; category default {my_file;}; category panic {my_file;}; category packet {my_file;}; category eventlib {my_file;}; category queries {my_file;}; category lame-servers { null;}; category cname { null;}; };
view “internal” { match-clients { 192.168.2.0/24; 127.0.0.0/24; }; # Specify the root name servers zone “.” IN { type hint; file “named.ca”; };
zone “midominio.dyndns.org” { type master; file “c:\winnt\system32\dns\etc\db.midominio.com.internal”; }; # Reverse IP mapping for 127.0.0.x zone “0.0.127.in-addr.arpa” { type master; file “c:\winnt\system32\dns\etc\127.0.0.rev”; }; # Reverse IP mapping for 192.168.2.x. # Poner aquí los 3 primeros números de nuestro IP en orden inverso. zone “2.168.192.in-addr.arpa” { type master; file “c:\winnt\system32\dns\etc\192.168.2.rev”; }; };
view “external” { match-clients {none;}; recursion no;
zone “midominio.dyndns.org” { type master; file “c:\winnt\system32\dns\etc\db.midominio.com.external”; allow-transfer {none;}; }; };
key “rndc-key” { algorithm hmac-md5; secret “VER_FICHERO_RNDC.CONF”; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { “rndc-key”; }; };
5.2.2 Vista interna: db.midominio.com.internal
– Serial es un identificador de versión, con formato año[4]-mes[2]-dia[2]-[#numero de cambio] (dato anecdótico).
Así el cambio número 2 efectuado el 13/5/2003 tendría como serial 2003051302.
– OJO: Cambia la IP privada por la IP local donde se aloje nuestro servidor, y el nombre de dominio.
code:
$TTL 86400 @ IN SOA midominio.dyndns.org. admin.midominio.dyndns.org. ( 2004071100 ; Serial 604800 ; Refresh /* refresh every 1 week */ 86400 ; Retry /* retry refresh every 1 day */ 2419200 ; Expire /* expire after 4 weeks */ 604800 ) ; Negative Cache TTL ; @ IN NS midominio.dyndns.org.midominio.dyndns.org. A 192.168.2.2
5.2.3 Vista externa: db.midominio.com.external
Esto con DDNS en realidad no es necesario, ya que hay programas para DDNS que actualizan nuestra IP pública automáticamente en los servidores DNS. Se incluye para el caso de que alquien quiera usar esto con dominios registrados (€€€) tipo midominio.com y demás.
Caso de que queramos utilizarlo (para DDNS no desde luego, útil para dominios tipo midominio.com), NAT en el router del puerto 53 TCP/UDP hacia la IP donde se ejecute BIND.
code:
$TTL 86400 @ IN SOA midominio.dyndns.org. admin.midominio.dyndns.org. ( 2004071100 ; Serial 604800 ; Refresh /* refresh every 1 week */ 86400 ; Retry /* retry refresh every 1 day */ 2419200 ; Expire /* expire after 4 weeks */ 604800 ) ; Negative Cache TTL ; Configuración ante peticiones externas ; ... ; ...
5.2.4 Root servers: named.ca
code:
; DNS primario ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A IP_DNS_Primario ; DNS secundario ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A IP_DNS_Secundario
5.2.5 Reverse IP: 127.0.0.rev
code:
$TTL 86400 $ORIGIN 0.0.127.IN-ADDR.ARPA. @ SOA DNS-authoritative1.domain.com. DNS-admin.domain.com. ( 2004071100 ; zone serial number in ccyymmddxx format 3600 ; slave polls master for SOA/serial number 1800 ; slave re-polls unreachable master 864000 ; slave expires zone after master unreachable 3600 ; TTL for negative answers ) ;nameservers @ NS DNS-authoritative1.domain.com. @ NS DNS-authoritative2.domain.com. ; 1 PTR localhost.
5.2.5 Reverse IP: 192.168.2.rev
Suponemos que BIND se ejecuta en 192.168.2.2: ponemos 2 PTR (nombre el que sea, irrelevante).
code:
$TTL 86400 $ORIGIN 2.168.192.IN-ADDR.ARPA. @ SOA DNS-authoritative1.domain.com. DNS-admin.domain.com. ( 2001060101 ; zone serial number in ccyymmddxx format 3600 ; slave polls master for SOA/serial number 1800 ; slave re-polls unreachable master 864000 ; slave expires zone after master unreachable 3600 ; TTL for negative answers ) ;nameservers @ NS DNS-authoritative1.domain.com. @ NS DNS-authoritative2.domain.com. ; 2 PTR
5.3 Usando BIND
Vamos a comprobar que todo funciona bien:
– Arrancamos BIND manualmente mediante:
named -g
– Configuramos en algún equipo de la red (puede ser donde se ejecuta BIND) la IP privada del Pc donde está BIND como servidor DNS primario y secundario.
– Ejecutamos:
nslookup midominio.dyndns.org
ping midominio.dyndns.org
¿Se resuelven a la IP privada? ¡ Enhorabuena ! Puedes arrancar BIND como servicio de sistema en Panel de control -> Herramientas Administrativas -> Servicios -> ISC Bind : tipo de inicio = automático.
En caso negativo… a revisar los ficheros de configuración, ojo con los ; y cosas así.
5.4 Ventajas e inconvenientes
Las ventajas están claras, tenemos un sistema mucho más sencillo de mantener y administrar que los anteriores ya que todo se realiza de forma centralizada. La escalabilidad de la red también ha mejorado sensiblemente, si un nuevo equipo se incorpora solo hay que configurarle nuestro servidor DNS.
Las desventajas son las asociadas a cualquier servidor proxy:
– Puede suponer un cuello de botella para el tráfico de nuestra red
– Como todo sistema centralizado, es poco robusto ante fallos: si el servidor donde está BIND falla, toda la red se queda sin acceso (sin poder resolver nombres al menos). Podemos mitigar esto configurando en los equipos de la red IP_BIND como DNS primario , y otro cualquiera como DNS secundario.
6. ¿Que solución utilizo?
Pues depende de lo que necesitemos:
– La solución #1 (proxy externo) sería recomendable para pruebas de accesibilidad externa, pero no para nada de carácter permanente.
– La #2 (fichero HOSTS), es adecuada para redes pequeñas (la típica que podemos tener en nuestra casa,hasta unos 5 equipos), en las que tampoco nos merece la pena instalar un servidor extra.
– La #3 (bind), sería la más ajustada a redes “grandes” (un cibercafe, aula de informática)
– Para redes mucho más grandes, soluciones mediante HW específico dedicado (un BUEN router CISCO catalyst).
7. Últimos comentarios:
Este hilo queda abierto para resolver problemas con BIND… y poco más. No para consultas de otros servidores, servicios, protocolos ni nada por el estilo.
Cargando ...
