|
INTRODUCCIÓN
He querido preparar este pequeño resumen debido fundamentalmente a los
posibles desconocimientos por parte de los usuarios de su funcionamiento y
debido a que nunca se debe estar jugando con los parámetros del TCP sin
saber qué es lo que se está tocando. Igualmente, Microsoft ha intentado
ayudar al usuario final, poniendo una serie de "Asistentes" a su
disposición. Pero el problema que veo en estos Asistentes, es que el
utilizarlos "conjuntamente" con modificaciones manuales posteriores a los
parámetros del TCP, puede dejar inoperativa nuestra maquina.
Estos
asistentes están muy bien para el usuario final. Pero precisamente para
eso: el usuario totalmente final, es decir, aquel usuario que nunca va a
entrar en los parámetros del TCP a modificarlos.
Un porcentaje muy
alto de gente, tiene, o bien, mínimos conocimientos del TCP y se arriesga
a andar tocando parámetros, o tiene un amigo que a su vez ha leído
que..... (el típico 'experto' no se sabe en qué, o bien, se encuentra
publicados en el web cosas a las que nunca debería hacer
caso.....
Entiendo igualmente que Microsoft, y esto sirva como
crítica a ellos, nunca ha terminado de ajustar estos asistentes. Si se
utilizan debería impedirse el acceso manual a las configuraciones TCP, o
bien quedar lo suficientemente ocultas para que ya no pueda modificarse
manualmente excepto por un experto.
En particular, y aunque parezca
mentira, existen dos grandes caballos de batalla: la implementación del
NetBios sobre TCP-IP (responsable de "ver" los otros equipos en la red) y
la implementación de la conexión compartida a Internet (ICS - Internet
Connection Sharing).
Vamos a repasar un poco los conceptos...
PROTOCOLO IP
El IP es el 'Internet Protocol'. Existen varios protocolos dentro de lo
que en lenguaje vulgar denominamos TCP-IP. Existen ICMP, ARP, etc... que
son los denominados paquetes de control del TCP-IP. Y existen los que
yendo bajo IP puro, encapsulan los mensajes TCP y udp. Estos últimos son
los que nos van a interesar, ya que son los normalitos que utilizan las
aplicaciones a las que estamos acostumbrados: navegadores, y en general
comunicaciones bajo TCP.
PUERTOS
En TCP-IP, pueden definirse 65536 puertos. Es decir, un puerto, no es
nada mas que un numero de 16 bits (2 elevado a 16 es el numero anterior),
y que se utiliza para que un determinado programa se comunique con la pila
TCP. Es decir, un programa se hace "dueño" de un puerto, y es capaz de
enviar y recibir datos por él.
Los puertos de números bajos:
inferiores al 1024, están reservados para el TCP-IP y normalmente tienen
nombre propio: el 21 es el FTP, el 23 el telnet, el 80 es el servidor
web... etc).
Los puertos superiores quedan libres pudiendo
utilizarles cualquier aplicación y para cualquier uso.
DIRECCIÓN IP
Cada máquina conectada a una red Internet, constituye un host que debe
ser único. Para ello, cada máquina debe tener una dirección IP (de 4
bytes) única en toda la red.
Esta dirección es de 4 bytes. Cada
byte, puede tener un numero desde 0 a 255. Y normalmente la representación
normal de esta dirección es por los 4 números en decimal anteriores,
separados por puntos. Por ejemplo: 192.168.0.1
El numero 255 queda
reservado normalmente para direcciones de broadcasting (direcciones
genéricas a toda una subred, y por ahora debemos obviarla).
Debe
existir una dirección IP en cada interfase de red. Una interfase de red,
es una tarjeta de red, o un módem en comunicación telefónica, o un simple
cable de conexión entre PCs, por ejemplo en el puerto paralelo, que vaya a
realizar una comunicación IP.
MÁSCARA IP
Para que las máquinas bajo TCP-IP, sepan cómo y por dónde enviar un
mensaje, es importante el tema de la máscara. La máscara es aquella serie
de 4 números (como si fuese una dirección IP), que ejecutado bit a bit con
una dirección IP, le indica al sistema si esta dirección IP pertenece a la
subred local -y por tanto es alcanzable mediante broadcast- o no pertenece
a la subred local, y por tanto el mensaje TCP, hay que enviarlo al gateway
o puerta de enlace de nuestra red.
Si la máscara está mal en
algunos de los equipos, pueden suceder problemas de todo tipo.
Por
ejemplo, la dirección 192.168.0.1 con mascara 255.255.255.0 indica que son
alcanzables en la subred local todas las maquinas de dirección 192.168.0.x
(siendo x cualquiera) y que cualquier otra maquina es alcanzable
únicamente enviando el paquete al gateway por defecto.
Quien quiera
pormenorizar en este tema, puede verse el manual "Fundamentos del TCP-IP",
del cual soy autor, y que he puesto a vuestra disposición en repetidas
ocasiones.
SOCKET
Un socket no es nada más que un canal de comunicaciones entre dos host
TCP. Por tanto, un socket queda totalmente definido por 4 números: la
dirección IP y el puerto de la máquina origen y la dirección IP y el
puerto de la máquina destino.
Cuando estamos viendo una página web
por ejemplo, los datos que vemos han viajado en un socket. Este socket se
ha establecido entre la máquina origen (la dirección IP de
www.microsoft.com, por ejemplo), y el puerto 80 (que es el puerto de los
servidores web), y la dirección IP de la máquina destino (nuestra IP) y un
puerto cualquiera que el navegador ha seleccionado en ese momento del
rango de los puertos libres en nuestra máquina.
DNS
Servidor de Nombres. Normalmente cuando nos referimos a una dirección,
no estamos casi nunca escribiendo la dirección IP de 4 números. Lo normal
es escribir un nombre, por ejemplo www.microsoft.com.
Pero tal y
como visto anteriormente, nuestra máquina solo entiende de direcciones IP.
Por tanto, es necesario que alguien traduzca el nombre en la dirección IP.
Ese "alguien" es un servidor DNS (Domain Name Solver).
Normalmente,
nuestro TCP, debe tener asignado la dirección IP del DNS, es decir qué
máquina de internet (o intranet) nos va a resolver los nombres. Cada vez
que a nuestra máquina le digamos un nombre, lo primero que hará será
consultar al DNS para tener su dirección y poder referirse a ella por
dirección.
Todos los nombre de Internet, deben localizarse en un
DNS. Por ello, cuando nos conectamos a Internet, o bien hemos configurado
los DNS de nuestra conexión telefónica, o bien nuestro proveedor de acceso
a internet (ISP) nos lo puede asignar, al igual que nos asigna dirección
IP, en el momento de establecer la comunicación.
El DNS de nuestro
ISP, evidentemente no tendrá todas las direcciones de Internet, pero para
aquellas que no tenga, tiene a su vez las direcciones de otros DNS a los
cuales les reenvía (forwarding) la pregunta.
Al final, sea
quien sea el que tiene la dirección real, el caso es que a nuestra máquina
le llegará y por tanto, nuestra máquina (mejor dicho el programa que lo
necesita en ese momento), a partir de entonces podrá referirse por
dirección al otro PC o al otro servidor.
DHCP
Es el mecanismo estándar por el cual una máquina en internet, es capaz
de dar automáticamente direcciones IP a las máquinas que se conectan sin
dirección IP.
Hemos comentado que la dirección IP debe ser única en
Internet. Pero por desgracia, no existen suficientes direcciones IP para
que cada uno de nosotros tengamos una asignada. Y menos, si queremos
distribuir y racionalizar esto un poco, es decir, distribuir las
direcciones IP por rangos.
Por ello, los proveedores de Internet,
suelen tener asignado un rango de direcciones, y lo normal es que los PC's
no tengan dirección IP en la conexión telefónica. El proveedor de
Internet, tiene entonces un servidor DHCP que nos dará una dirección en
ese momento, de su rango de direcciones libre. Ese servidor DHCP,
igualmente almacena y guarda en un fichero, a quien le ha dado la
dirección IP al objeto de poder ser consultado en cualquier
auditoría).
OTROS PROTOCOLOS
Existen otra serie de protocolos de mensajería y control: ICMP, IGMP,
ARP, etc,... que aunque viajan por internet, son siempre transparentes al
usuario final. Normalmente y por desgracia, estos son los más susceptibles
a los temas de hacking.
¿CÓMO VIAJA FÍSICAMENTE UN
MENSAJE?
A la hora de salir el mensaje "físico" por el cable, este ya no
entiende de dirección IP. Entiende únicamente de la dirección física de la
tarjeta de red destino. (Cada tarjeta de red, lleva internamente un número
único en el mundo y que los fabricantes de hardware garantizan que es
único).
Por ello, se debe convertir de nuevo, la dirección IP
destino en la dirección MAC (la dirección física de la tarjeta destino
comentada anteriormente).
Precisamente el protocolo APR mencionado
anteriormente, lo utiliza, entre otras cosas, el propio TCP-IP para tener
las direcciones MAC o bien de las maquinas destino a las cuales queremos
alcanzar, o bien la dirección MAC del gateway o puerta de enlace de
nuestra subred con la red externa o internet.
* Lo anterior es básicamente la implementación del TCP-IP bajo
internet, o bien los conceptos con los que nos vamos a manejar a partir de
ahora.
Existe una segunda implementación (que no es posible
utilizar por internet), de la implementación LM (Lan Manager, definida por
IBM a principios de la década de los 80), que nos permite utilizar el
TCP-IP en las intranet, o bien en las redes domesticas. La implementación
de Lan Manager se hace con la resolución de nombre NetBios sobre TCP-IP.
Es decir, es un protocolo llamado NetBios y que se encapsula en mensajes
TCP.
(para entender el tema del encapsulado, baste un pequeño
ejemplo -y muy basto-, ¿es posible viajar el coche desde Madrid a New
York?.... Pues sí: comienzo mi viaja en coche hasta la costa, allí meto el
coche en un barco ('encapsulo'), atravieso el Atlántico, llego al puerto,
saco el coche ('desencapsulo') y continúo hasta mi destino).
|
|
HAGAMOS UN BREVE
RESUMEN
Aunque lo que hemos visto hasta aquí, es muy básico, prácticamente
todos hemos tenido que configurar la conexión a Internet y siempre lo
hemos hecho rutinario. Nuestro ISP nos daba las instrucciones.
Generalmente no había que configurar nada y en algunos casos, los DNS's
del ISP.
Con lo que hemos visto, supongo que hemos comprendido un
poquito como funciona: tenemos un interfase de red (el modem) sin
dirección IP. Al conectarnos, solicita de un servidor DHCP una dirección
IP, así como los DNS's si estos no estuviesen configurados.
Según
recibe la dirección IP en la nueva interfase de red, Windows cambia
automáticamente las rutas de envío. Esto puede verificarse ejecutando el
comando:
route print
antes y después de la
conexión.
Acabo de conectarme e Internet y la salida de ese comando
me informa de:
Active Routes:
| Network Destination |
Netmask |
Gateway |
Interface |
Metric |
| 0.0.0.0 |
0.0.0.0 |
62.37.149.2 |
62.37.149.2 |
1 |
| 62.36.208.19 |
255.255.255.255 |
62.37.149.2 |
62.37.149.2 |
1 |
| 62.37.149.2 |
255.255.255.255 |
127.0.0.1 |
127.0.0.1 |
1 |
| 62.255.255.255 |
255.255.255.255 |
62.37.149.2 |
62.37.149.2 |
1 |
| 127.0.0.0 |
255.0.0.0 |
127.0.0.1 |
127.0.0.1 |
1 |
| 192.168.0.0 |
255.255.255.0 |
192.168.0.1 |
192.168.0.1 |
1 |
| 192.168.0.1 |
255.255.255.255 |
127.0.0.1 |
127.0.0.1 |
1 |
| 192.168.0.255 |
255.255.255.255 |
192.168.0.1 |
192.168.0.1 |
1 |
| 224.0.0.0 |
224.0.0.0 |
62.37.149.2 |
62.37.149.2 |
1 |
| 224.0.0.0 |
224.0.0.0 |
192.168.0.1 |
192.168.0.1 |
1 |
| 255.255.255.255 |
255.255.255.255 |
192.168.0.1 |
192.168.0.1 |
1 |
Default Gateway: 62.37.149.2
Esta tabla de rutas indica por
dónde saldrán nuestro mensajes IP. La manera de leerla es desde abajo
hacia arriba.
Localizamos desde abajo a arriba, las líneas que
tienen como gateway el 127.0.0.1 (que es el 'localhost', es decir la
dirección de 'loppback' de nuestra propia maquina.
La primera
entrada que encontramos es la que tiene como IP 192.168.0.1 (curiosamente,
la dirección IP de mi tarjeta de red).
En la línea anterior, nos
indica que todos los paquetes a la dirección 192.168.0.x (pongo una x ya
que la mascara es 255.255.255.0) saldrán por el gateway 192.168.0.1 que es
mi tarjeta de red. Es decir, para mi red local, la salida de los paquetes
IP es por mi tarjeta de red.
Continuando, vemos que el siguiente
127.0.0.1, pertenece a la dirección 127.0.0.0. Esta entrada se ignora ya
que es el propio 'loopback' local. Es decir el que se utiliza normalmente
entre aplicaciones, que a pesar de ejecutarse en la misma máquina, se
comunican entre ellas vía TCP-IP, como si estuviesen en máquinas
diferentes.
Ascendiendo en la lista, nos encontramos que el
siguiente 127.0.0.1, pertenece a la dirección 62.37.149.2. Curiosamente es
justo la dirección IP que nos acaba de dar nuestro proveedor de Internet
(ISP).
Se puede verificar esto, ejecutando el
comando:
ipconfig /all
Bien, ascendiendo hacia arriba,
ignoramos todas las que tienes máscara 255.255.255.255, y la primera que
queda es: 0.0.0.0 (con máscara a ceros) sale precisamente (gateway) por la
dirección IP de mi interfase de conexión a Internet (modem). Esto indica
que cualquier dirección que no haya sido enviada antes (es decir,
cualquier otra que no sea mi red local), saldrá por el
modem.
*****************************
Bien, lo visto en estas
líneas, puede parecer un poco pesado y un poco raro. Pero es
importantísimo cuando tenemos mas de una interfase de red, el saber leer
correctamente la tabla de rutas.
Esta tabla que acabamos de ver,
puede modificarse mediante el comando "route". Pueden añadirse y quitarse
rutas de red. Si ejecutamos:
route /?
nos dará la sintaxis
completa.
*****************************
Lo importante de lo
que hemos visto hasta ahora, es que estos conceptos que hasta el momento
los he centrado en Internet, no solo son para Internet. Son para cualquier
red TCP-IP (incluida nuestra posible red local).
MEJORAS IMPLEMENTADAS DESDE W98
HASTA W2000
Hasta el momento hemos visto que es necesario siempre una dirección IP
para que funcione una comunicación TCP-IP.
La pregunta que surge
es: yo he instalado W98 (o W2000), no he dado ninguna dirección IP, no sé
ni lo que es un servidor de direcciones DHCP y que yo sepa no existe en mi
red, y curiosamente me funciona todo ¿como es eso?....
Bien, la
respuesta es sencilla: Microsoft, a partir de W98 (y superiores)
implementó el concepto de 'Autonet Configuration'. Este mecanismo lo que
hace, es que cuando no hay dirección IP, investiga en la red para
localizar un servidor DHCP. Si no lo encuentra en los primeros tres
intentos, se "inventa" un dirección IP cualquiera en el rango de
direcciones 169.254.x.y de clase B (es decir, con mascara 255.255.0.0) y
para evitar que esa IP inventada ya exista, investiga en la red mediante
el protocolo ARP si ya está duplicada. Si estuviese, se "inventa" otra y
repite el proceso.
De esta manera, nuestra red siempre tendrá
direcciones IP dentro del mismo rango de direcciones (por tanto lo PC's se
verán entre ellos,... pero eso lo veremos más adelante...) y no hemos
tenido que configurar nada.
Por supuesto, las direcciones que hemos
visto hasta ahora:
192.168.0.x (clase C: es decir mascara
255.255.255.0) 169.254.x.y (clase B: es decir mascara
255.255.0.0)
Y esta otra:
10.x.y.z (clase A: es decir
mascara 255.0.0.0)
Son direcciones "reservadas" en Internet. Es
decir, no puede existir ninguna máquina en Internet con estas direcciones.
Por tanto, son las candidatas primeras a utilizar en nuestra red
local.
CONCLUSIÓN Y TIP
TIP: El mecanismo que acabamos de describir para "autoasignarse"
dirección IP en una red que no tenga servidores DHCP, es evidentemente un
mecanismo lento. Las normas del TCP-IP (RFC), indican los tiempos de
espera (time out) entre cada uno de los intentos para localizar un
servidor DHCP, los tiempos de búsqueda y espera del protocolo ARP, etc.
Por tanto este mecanismo hará que nuestro PC se demore unos 20-30 segundos
más de lo debido en arrancar.
Si queremos eliminar esta demora,
simplemente asignando a los PCs de nuestra red alguna de las direcciones
(evidentemente dentro del rango de direcciones) que hemos comentado antes,
nos ahorraremos ese tiempo en arrancar el PC.
NOTA: Si
tenemos instalado el ICS (conexión compartida a Internet en W98SE o WME o
W2000), no deben asignarse direcciones IP ya que automáticamente la
maquina que comparta el modem se convierte en servidor DHCP, colisionando
por tanto con las configuraciones manuales que podamos asignar. Más
adelante veremos en profundidad el ICS.
José Manuel Tella LLop
|