 | |
REDESII | | |
 Cómo trabaja RLOGIN ?
Una vez que yahoo recibe nuestra solicitud y encuentra que nuestra petición es razonable, iniciará un
pequeño diálogo con
nuestra computadora, mandándose algunas señales mutuas para realizar la conexión y veremos entonces
aparecer la página
de yahoo
¿Y cómo se establece esta comunicación?: porque en nuestro paquete, aparte de tener la dirección de
yahoo y de su puerto
(y de otros datos) tenía nuestra dirección, es decir, la dirección que nos asignó nuestro proveedor
dinámicamente cuando
hicimos la comunicación vía modem o adsl, si es por allí que hicimos la conexión. ¿Y por qué dinámica?:
porque no siempre
es la misma, dependerá del modem en suerte que nos hemos conectado en el servidor del proveedor, según
la línea de
teléfono real que estemos usando (porque aunque llamamos siempre al mismo número, en general son líneas
rotativas y ese
número no tiene ningún modem para respondernos, sino que pasa el número a la siguiente línea libre y
esa linea/modem nos
asignará un ip.
Por supuesto que puede ser que querramos pagar más y que el número que nos asignen sea siempre el mismo,
pero para el
caso que estamos viendo es lo mismo: sea una IP fija o una IP asignada dinámicamente, es con esa IP
que el resto del
mundo nos conocerá en ese momento para devolvernos las respuestas de nuestras solicitudes: mandar una
carta, hacer un
ftp para subir o bajar un archivo o navegar por la web
Pero supongamos que tenemos otra computadora, conectadas ambas mediante sendas placas ethernet. O imaginemos
un
escenario algo más complejo: estamos en el aula-laboratorio de una escuela, estando todas las computadoras
conectadas en
red, algunas viejas 386 y 486 con Windows 3.11, otras 586 con Windows 95 y otras más nuevas con Windows
98
(ninguna con Windows 2000, más de uno ha decidido desinstalarlo, por problemas con dispositivos y con
ciertos programas
conducta más anormal que con el 98) y naturalmente nuestra máquina con GNU/Linux. Cada una de ellas
tiene su propia
dirección IP. Como no eran muchas decidimos hacer una red de clase C a la cual la llamamos 192.168.1.0,
y cada
computadora tiene un IP fijo: la con Linux 192.168.1.1, la siguiente con 192.168.1.2 y así sucesivamente.
Y la máscara de
red es 255.255.255.0 justamente porque el cero indica la parte del anterior número que corresponde al
host y los unos
(255=8 unos,11111111)
Bien. En nuestra máquina GNU/Linux tenemos el modem, llamamos al proveedor mediante una comunicación
ppp y luego
de establecida la comunicación miramos con ifconfig qué dirección nos asignó el proveedor y vemos que
ha sido algo así
como 200.32.16.108. Dicho de otra manera, nuestra computadora entonces tiene dos direcciones IP, la
reconocida
externamente, 200.32.16.108 y la que le hemos puesto en nuestra red interna: 192.168.1.1
¿Pero y si queremos navegar por otra computadora de la red?. Una alternativa sería logearse en nuestro
servidor
GNU/Linux y desde allí navegar, pero no es lo más conveniente. Lo bueno es navegar desde los recursos
de la propia
computadora (salvo que sea muy vieja), por ejemplo desde la computadora 5. Pero nos encontramos con
un inconveniente:
aún suponiendo que nuestra solicitud de pedido saliese y llegase hasta yahoo, este servidor no sabría
cómo enviarnos la
respuesta, porque la dirección 192.168.1.5 no existe para Internet, porque es una dirección privada
(todas las que empiezan
con 192.168 lo son).
Una alternativa sería ponerle un modem a esa computadora, llamar a un proveedor para que este nos asigne
una dirección IP
(pública) pero para ello necesitaríamos otra línea de teléfono y un gasto mayor en pulsos telefónicos.
Para resolver este problema se pensó en lo siguiente: ese paquete que llega de la 192.168.1.5 a la 192.168.1.1
(pues le
hemos dicho a la 5 que el gateway o compuerta es la 1), se lo modifica para que pareciera que lo está
enviando la IP
asignada por el proveedor (en este caso la 200.32.16.108)
De esta manera yahoo, cuando recibe la solicitud envía la respuesta a la 200.32.16.108, pero, claro,
aquí hay otro
problema, no es la 200.32.16.108 la que hizo la solicitud (la 200.32.16.108 = 192.168.1.1) sino la 5.
Entonces ese paquete
tendría que salir de la 1 con una marca, para que cuando la 1 lo recibiera supiera redirigirla a la
5. Esto se resolvió
asignándole a ese paquete un dato más, un puerto que identifica la computadora 5, de esa manera sabe
la 1 que es paquete
no es para ella sino para la cinco.
Todo este proceso se llamó enmascaramiento o masquerading y se empezó a usarlo asiduamente a partir
del núcleo 2.0.x,
aunque ya a partir del núcleo 1.3.15 existían posibilidades de hacerlo.
2. Cómo enmascarar con ipfwadm
Para ello el núcleo debía estar compilado con algunas características experimentales, entre otras justamente
el
IP_Masquerade, así como otros (NET, FIREWALLE, FORWARD, MODULES, etc)
y un programa facilitaba enormemente el proceso de configuración, el ifwadm
Teniendo ya preparado ese núcleo (algunas distribuciones a partir del 2.0.x comenzaron a tener estos
módulos preinstalados,
facilitando el uso de esto al usuario que recién se iniciaba), simplemente había que dar las órdenes
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
Y prácticamente con esto la navegación para todas estaba habilitada (había que tener en cuenta otras
cosas pequeñas, pero
como son iguales para las otras versiones del núcleo, las veremos después)
¿Que se está diciendo allí?. La primer línea quita los permisos de acceso a todo el mundo, la segunda
habilita, aceptar el
enmascaramiento para los paquetes que tenga su origen (source) en la red 192.168.10/255.255.255.0 y
que tenga como
destino todo el mundo (0.0.0.0/0.0.0.0)
Ese 24, se habrán dado cuenta, es una manera de abreviar la máscara de red:
======================================
Máscara de red |abrev.| Subred
======================================
255.0.0.0 | 8 | Clase A
255.255.0.0 | 16 | Clase B
255.255.255.0 | 24 | Clase C
255.255.255.255 | 32 | Una sola máq
======================================
A título de ejemplo, si se quiere permitir que sólo naveguen tres máquinas, la 3, la 5 y la 8:
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.1.3/32 -D 0.0.0.0/0
ipfwadm -F -a m -S 192.168.1.5/32 -D 0.0.0.0/0
ipfwadm -F -a m -S 192.168.1.8/32 -D 0.0.0.0/0
Cambios de sistema de filtrado y de herramientas para hacerlo
3. Cómo enmascarar con ipchains
A partir del núcleo 2.2.0, el IP Forward Administrador (ipfwadm) cayó en desuso siendo reemplazado por
el ipchains y este
ha sido el sistema que se ha utilizado mayormente para hacer enmascaramiento y cortafuegos. La mayoría
de los libros sobre
el tema que circulan hoy están referidos justamente a esta herramienta y para ubicarnos, las distribuciones
realizadas hasta
fines del 2000 y principios del 2001 usarán este sistema (Red Hat del 6 al 7, Mandrake hasta el 7.2,
Debian 2.2 Potato,
Suse 7.2, Conectiva 6). El gran cambio, el que sorprenderá a más de un usuario de GNU/Linux cuando haga
este año o los
siguientes la actualización, está dado con la aparición del núcleo 2.4.x, donde en vez del ipfwadm y
el ipchain se utiliza el
iptables y se incorpora el sistema NAT (Network Address Translation)(en realidad se incorporó antes,
en el núcleo 2..3.5)
¿Y por qué sorprenderá a más de un usuario no informado?: porque cuando instale las nuevas distribuciones
y escriba
aquellas órdenes o las similares con ipchains, le aparecerá un mensaje que el kernel no soporta ipchains
(o ipfwadm, si pone
esta última orden)
En realidad no es tan dramático el asunto, porque si quieren seguir usando sus viejas configuraciones
sólo deberán
recompilar el núcleo con acceso a ipchains, pero cuidado, no se pueden mezclar órdenes de ipchains con
las de iptables, así
como también existen pequeñas diferencias en los nuevos formatos de órdenes que deberán tener en cuenta
quienes quieran
seguir usando ipchains con el núcleo 2.4 (ver al respecto los howto de iptables y de NAT)
Supongamos que estamos con el núcleo 2.2.x y que queremos usar el ipchains: las órdenes son similares
a las que ya vimos.
Supongamos que nuestra conexión a internet la estamos haciendo vía ppp, por lo que nuestro dispositivo
de conexión se
llamará ppp0. La orden a dar será::
ipchains -P forward DENY
ipchains -A forward -i ppp0 -j MASQ
y finalmente (o al principio, deberemos poner un 1 en un archivo que puede tener un 0)
echo 1 > /proc/sys/net/ipv4/ip_forward
(con cero está deshabilitado el forward, con 1 habilitado)
Por las dudas, antes de hacerlo mirar qué hay adentro:
cat /proc/sys/net/ipv4/ip_forward
Si está el 1 es que en algún lado ya dimos la orden de habilitación. Y si está cero no.
Generalmente esta orden se da en el archivo network, que en algunas distribuciones que siguen la línea
de Red Hat está en
etc/sysconf/network
y que más o menos puede decir algo así:
NETWORKING=yes
FORWARD_IPV4=false
HOSTNAME=fer17.intercol.org.ar
DOMAINNAME=intercol.org.ar
GATEWAY=192.168.3.1
GATEWAYDEV=eth0
En este caso vemos la configuración de una máquina de la red, no del servidor. En él deberá estar un
true en
FORWARD_IPV4 (y el gateway será la dirección del proveedor y el dispositivo será un eth0 o un eth1 si
estamos con adsl
o un ppp0 si es vía modem
4. IPTABLES Y NAT. La arquitectura netfilter
4.1 Cómo enmascarar con ipchains
Según relata Rusty Russell (mailing list [email protected]) en el HowTO de IPTABLES
"El kernel de Linux ha tenido filtrado de paquetes desde la versión 1.1. La primera versión
estaba basada en
ipfw de BSD, que fue portada por Alan Cox en 1994. Para Linux 2.2 fue realizado por Jos Vos y otros;
la
utilidad 'ipfwadm' controlaba las reglas de filtrado del kernel. A mediados de 1998, para Linux 2.2,
rehice el
kernel con la ayuda de Michael Neuling, e introduje la herramienta "iptables". Finalmente,
la cuarta
generación de herramientas, "iptables", fue reescrita a mediados de 1999 para Linux 2.4"
En realidad el cambio grande es el sistema de arquitectura del núcleo, basado en netfilter
Pero antes de pasar a ver esto con algo más de detalle, para quienes lo que simplemente están buscando
es enmascarar su
red para navegar, las nuevas órdenes a dar serán:
echo 1 > /proc/sys/net/ipv4/ip_forward
(igual que en caso anterior, habilita el reenvío de paquetes)
Limpiando todas las anterior que podamos tener definido:
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
Y luego las órdenes propiamente dichas:
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT
Como vemos aquí no pusimos la dirección de IP de la red porque se asume que esa placa de red tiene definida
la dirección
ip de la máquina (la que vemos con ipconfig) y por ende se saca la de configuración de la placa de red
Con ADSL
Si tenemos un adsl, o la conexión es por cable al router, es decir, si la conexión que haremos no la
hacemos vía modem
(ppp0) sino vía placa ethernet, debemos tener definida con ifconfig cuál es la placa de red que tiene
la dirección con el
proveedor y cual es la placa de red que tenemos en la red interna.
Supongamos que tenemos la red interna en la placa de red que viene en el motherboard o la que se reconoce
primero (eth0),
y que nuestro adsl lo tenemos conectado a la segunda placa de red, la eth1, las órdenes a dar son muy
parecidas a las
anteriores, sólo sacando el ppp0 y poniendo la placa correspondiente. Es decir, igual órdenes para borrar
las reglas y chain
definidas anteriormente y para poner el 1 en el archivo que habilita el forwarding
y luego, para donde está la conexión hacia afuera eth1
iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
y par la red interna por eth0
iptables --append FORWARD --in-interface eth0 -j ACCEPT
Y con esto anda.
Importante: Podría ocurrir que le de un mensaje de error cuando ejecuta el iptables, que falta el módulo.
Si es así primero
cárguelo escribiendo
modprobe iptables_nat
Y si quieren saber el estado actual de su sistema, escriban:;
iptables -L
¿Por qué aparece el netfilter y el iptables?
Fueron varios los motivos que llevaron a los diseñadores a modificar el sistema. IPCHAINS no tenía una
infreestructura para
pasar paqueter al espacio de usuario, hacer un proxy transparente era muy difícil, y tenía otras limitaciones.
El cambio a la
arquitectura de netfilter posibilita enfrentar el manejo de los paquetes de una manera mas poderosa
y menos complicada,
favoreciendo la seguridad y otras cuestiones
Cuando pensaba el título del trabajo y puse Filtrado y enmascarado me pareció una contradicción pero
lo dejé así. ¿Por
qué?: Porque en realidad el enmascaramiento es un caso particular del filtrado, claro que implica a
su vez un cambio del
cabezal del paquete.
Por eso la herramienta que se utiliza para hacer el filtro de red (netfilter) es el iptables, aunque
con las órdenes simples de
iptables no se puede producir el enmascaramiento: hay que cargar el NAT. Pero vayamos por parte.
4.2 Netfiler
A partir de la versión 2.3.15 del núcleo fue posible cargar el módulo iptables (compilando el núcleo
con un Yes a la opción
CONFIG_NETFILTER)
¿Y qué hace el netfilter?: El núcleo se fija en la tabla (tabla que se arma con la herramienta ipfilter)
que le dirá, según el
cabezal del paquete, qué hacer con él: DENY (denegar), ACCEPT (aceptarlo o REJECT (descartarlo). ¿Y
para qué
querríamos hacer esto?. Para controlar el tráfico de la red, para evitar paquetes indeseables, para
permitir el paso de cierto
tipo de paquetes y denegar el paso de otros. Por ejemplo para hacer un cortafuegos (firewall) que sirva
de nexo, filtro y
protección entre la red interna e Internet, permitiendo cierto tipo de tráfico y negando otro, dejando
pasar pedidos para
ciertos servicios y negando otros.
Rusty Russell, quien se encarga de mantenerel Firewall IP de Linux, nos dice que el kernel empieza con
tres listas de reglas,
llamadas firewall chains, o sólo chains: INPUT, OUTPUT y FORWARD (Entrada, Salida y Reenvío)
Y lo diagrama más o menos así:
______
/
\
-->[Decisión]--->|REENVÍO |----->
[de ruteo] | |
\_______/
^
|
|
v
_____
_____
/ \
/ \
|SALIDA|
|ENTRADA|
\______/
\_______/
^
|
|
----> Proceso Local ----
Los tres "círculos" representan las tres chains mencionadas anteriormente. Cuando el paquete
llega al dispositivo de red el
kernel mira el destino de dicho paquete y lo rutea: si es para esa máquina, lo deja pasar, ingresa (INPUT).
Si no lo es, y
tiene activado el reenvío (FORDWARD), va a la chain de reenvío para tomar una decisión (si se acepta
el paquete se lo
envía afuera). Y si no cumple ninguna de las opciones, es directamente ignorado (DROP)
Y si hay algún paquete producido por un programa irá a la chain de salida OUTPUT y allí se tomará la
decisión de qué
hacer con ese paquete. Si todo está ok, el paquete saldrá dirigiéndose a donde fuera que estaba destinado
Rusty Russell define a "Una chain es una lista de reglas. Cada una de ellas dice "si la cabecera
de un paquete se parece a
esto, entonces esto es lo que lo que se debe hacer con ese paquete". Si una regla no corresponde
con el paquete, entonces
la siguiente regla de la chain se examina. Finalmente, si no hay más reglas que consultar, el kernel
mirará la política para
decidir qué se debe hacer. En un sistema con una buena política de seguridad, la política normalmente
será de hacer DROP
del paquete".
No veremos aquí las reglas (están en el HowTo y en el man), pero si hablemos del caso especial donde
aplicaremos al
paquete NAT, el Network Address Translation
4.3 NAT
Como vimos al principio, el NAT de alguna manera modifica el paquete, por ejemplo para enmascarar una
dirección, y
luego debe recordar eso que hizo para cuando venga la respuesta (otro paquete) y sepa qué hacer
con él y todo funcione
como se espera
NAT es muy útil no sólo para enmascarar el paquete, como vimos. También tiene otros usos.
Supongamos que tenemos una sola dirección IP reconocida por internet. Y nos gustaría que el servidor
de web en otra
computadora, la de la dirección 192.168.1.3, de la red que mencionábamos anteriormente. Cuando llega
el pedido desde
afuera a nuestro servidor, el paquete buscará la dirección 200.32.16.108 de nuestro ejemplo inventado,
que es la
computadora que tiene en ese ejemplo la dirección 1, es decir, 192.168.1.1 Y dicho paquete solicitando
el servicio buscará
entonces el puerto 80 y no habría forma de hacer que lo sirviese un apache en la computadora 192.168.1.3
ni cualquier otra
de la red, porque para Internet son inexistentes. Pero aquí viene NAT a salvarnos. Podemos hacer que
dicho paquete sea
modificado, "engañado"
iptables -A PREROUTING -t nat -p tcp -d 200.32.16.108 --dport 80 \
-j DNAT --to 192.168.1.3:80
(el \ del anterior renglón es para decir que el renglón no se cortó, el comando sigue en el renglón
de abajo)
Así pueden hacerse otras cosas, como balanceo de carga entre varios servidores a pesar de tener una
sola dirección IP, o
hacer un proxy transparente.
Esto último es más o menos lo siguiente: Con un Sevidor Proxy, cuando desde al red interna se
quiere navegar, y se pide
una web, seguimos con el ejemplo de yahoo, en realidad aunque la persona cree que le está pidiendo la
página a yahoo, se
la está pidiendo a un servidor proxy. Y yahoo recibe la solicitud nuestra y cree que somos nosotros
quienes estamos
pidiendo algo y nos lo envía, pero en realidad quien lo envía es el servidor proxy y él quien lo recibe.
De esta manera
establecemos un filtrado entre la red interna y el resto del mundo.
Existen dos tipos de NAT: SNAT (por Source -fuente- NAT) y Destino NAT (Destination NAT)
Source NAT es cuando se altera el origen del primer paquete y esto se hace luego del encadenamiento,
justo antes de salir
afuera. De allí que el enmascaramiento que vimos al principio es una forma particular de SNAT
En cambio en el último ejemplo que vimos, el de engañar el paquete que ha llegado para que vaya a otra
computadora o a
otro puerto, usamos en DNAT, es decir, cambiamos la dirección de destino del primer paquete, por lo
que DNAT se hace
siempre antes del enrutamiento, cuando el paquete está entrando. El cambio de puerto (hacer que un paquete
que va a un
puerto vaya a otro), port forwarding, el balanceo de carga y el proxy transparente son formas de DNAT.
Para crear las reglas NAT que le digan al núcleo qué conexiones cambiar y cómo hacerlo, se usa también
el iptables, pero
con el parámetro -t nat
Rusty Russell dice:
"La tabla de reglas NAT contiene tres listas llamadas "cadenas": cada regla se examina
por orden hasta que
una coincide. Las tres cadenas se llaman PREROUTING (para Destination NAT, según los paquetes entran),
POSTROUTING (para SOURCE NAT, según los paquetes salen), y OUTPUT (para Destination NAT con los
paquetes generados en la propia máquina).
En cada uno de los puntos anteriores, cuando un paquete pasa miramos la conexión a la que está asociado.
Si es una
conexión nueva, comprobamos la cadena correspondiente en la tabla de NAT para ver qué hacer con ella.
La respuesta que
obtenemos se aplicará a cualquier paquete posterior de esa conexión.
La página HowTO de NAT es bastante clara al respecto por lo que no tiene caso redundar en ello. Los
interesados pueden
consultarla
4.4 Muchas posibilidades
Para analizar cada paquete y decidir que hacer, hemos visto dos elementos del cabezal: dirección de
origen y dirección de
destino, pero en realidad hay muchos otros elementos, por ejemplo la definción de protocolo (-p) que
admite varios, como
"TCP", "UDP" o "ICMP". También se pueden examinar las banderas,
por ejemplo el primer mensaje de un envio tiene un
tipo de bandera y los siguientes otros, etc. Entre otras banderas (flags( están SYN,ACK,FIN,RST,URG,PSH,
ALL que
incluye todas las anteriores, y las principales serán SYN y ACK
5. Adevertencias y precauciones
La lectura de documentos o libros sobre filtrados, firewalls, y seguridad puede asustar a más de uno
por la cantidad de
parámetros y posibilidades, no siempre fáciles de entender. De allí que han ido apareciendo distintas
herramientas para
configurar el firewall o la seguridad que tienen una ventaja: están al alcance del neófito. Pero deben
usarse con precaución,
porque pueden obtener resultados no esperados
Por ejemplo hay una muy interesante y bastante completa, bastille, pero su uso puede llevarle
alguna sorpresa, no
necesariamente porque funcione mal, sino hará cosas que no sabemos y que pueden bloquearnos el uso normal
de la
computadora, no poder conectarnos más a internet o no poder usar ciertos programas, por lo que antes
de hacer nada es
recomendable hacer una copia de respaldo completo al menos del directorio /etc y todo lo que contiene,
y tal vez del /var
Puede ocurrir que usted se loguee normalmente desde la consola como root y de golpe, luego de ejecutado
dicho programa,
no puede hacerlo más y le dice que su contraseña es incorrecta
Eso se debe a que ha modificado el archivo /etc/securetty
Normalmente ese archivo tiene una de terminales desde donde puede ingresar el root
ttyS1
ttyS2
.....
ttyS6
y si suprimimos toda esa lista o alguna de esas terminales, ya no se puede entrar como root. Primero
hay que logearse como
un usuario común y luego para llegar a ser root cambiar con la orden su
Este simple ejemplo nos muestra que a veces podemos definir cosas sin saber qué está pasando y qué hacer,
con algún tipo
de problemas, por lo que es recomendable antes de hacer nada de todo esto, estudiar un poco los materiales
y tener a mano
alguien a quién consultar en caso de problemas
Por lo que mejor no use esas herramientas que son muy poderosas, sin saber lo que está haciendo
Otro ejemplo es el linuxconf, un programa muy útil para configurar nuestro sistema. Y aquí puede presentarse
otro problema:
puede que usted esté acostumbrado a hacer desde él el enmascaramiento y la configuración del cortafuegos.
Pero por ahora,
al menos las versiones que vienen con las distribuciones hasta mitad de este año, el linuxconf
trabaja con el ipchains, por lo
que con el nuevo núcleo no podría configurar el iptables ni hacer un enmascaramiento usando el linuxconf
a menos que
recompile el núcleo para que tome lo viejo.
Con esto hemos dado un pantallazo al tema de filtros y enmascaramiento
Sólo nos queda un punto para terminar de armar aquella red con clientes windows. ¿Cómo se configuran?
5. Configurando clientes MSWindows 9x
Naturalmente deberán tener reconocida e instalada la tarjeta de red ethernet
Luego Menú de Inicio, Configuración, Panel de Control, Red
Allí deberá estar e protocolo TCP/IP asignado a la placa que instalaron. Si no está en la lista, agregenla,
generalmente estará
el TCP/IP Adaptador de Acceso telefónico a Redes, pero no es ese, es un segundo protocolo
Una vez que lo tiene, clic y van a Propiedades.
Allí aparecerá un nuevo menú con varios "ojales" o "solapitas" arriba: Enlaces,
Avanzado, Configuración DNS, etc
Allí se va a Dirección IP y se habilita "Especificar una dirección IP" y allí se pone la dirección
que han asignado a esa
máquina (que estará en el archivo /etc/hosts del servidor GNU/Linux)
Por ejemplo la 192.168.1.6 y ponen también la máscara de red: 255.255.255.0
En configuración DNS deberán poner Activar DNS y poner el nombre del host (o sea el nombre que le han
puesto a esa
computadora) y en otro rectángulo en nombre de la máquina. También deberán poner cuál es el servidor
DNS, en este caso
será el mismo del gateway 192.168.1.1 o el DNS del proveedor. Pueden agregar hasta tres
Si están con dudas, mientras está la conexión realizándose en el servidor, miren el archivo /etc/resolv.conf
y allí seguramente
aparecerán los números que corresponden, si no es probable que el sistema no esté andando
Luego van a "Puerto de Enlace" o Gateway o Pasarela, y ponen el número del servidor GNU/Linux,
el que hace la conexión
hacia afuera, y ponen su número, en el ejemplo que puse arriba sería
192.168.1.1
Hacen clic en Agregar para agregarlo
Las otras pantallas son innecesarias de tocar
Darle al Aceptar y naturalmente, booteen la computadora :-)
(con Linux no es necesario bootearlo cada vez que hacemos algún cambio, simplemente reinicializamos
el servicio tocado)
En el caso de las computadoras Linux, es muy simple: cada una debe tener un nombre distinto, igual dominio
y un número de
red igual y de host distinto
La lista de todas las computadoras se guardan en el archivo /etc/hosts de cada una, todos igual
(si una computadora no está en esa lista, no podrá hacerse la conexión). También hay otra manera, configurar
en una sola (el
servidor por ej.) el DNS pero es más complejo y para el caso no tiene sentido
En el archivo /etc/hosts de la computadora que estoy escribiendo esto tiene:
192.168.3.17 fer17.intercol.org.ar fer
192.168.3.15 ale17.intercol.org.ar ale
192.168.3.3 server3.intercol.org.ar server3
192.168.3.1 dns1.intercol.org.ar intercol
192.168.2.1 server1.cignux.org.ar server1
192.168.3.19 grae19.intercol.org.ar grae19
| 
