NO PUEDO ACCEDER A SERVIDOR EN LAN MEDIANTE IP PUBLICA
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- Public Proxy Servers
2- Proxy4Free
3- 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.
Y eso es todo. Un saludo.
Documento elaborado por MetalHead para www.adslayuda.com
