Hoy en día ya está obsoleto el concepto de "Centro de Cálculo" como cuarto con un gran ordenador donde los usuarios traían sus trabajos para procesar escribiendo los comandos en terminales conectadas al ordenador por líneas serie. El viejo modelo de un solo ordenador que atendía todas las necesidades de computación de una organización ha sido reemplazado por uno en el cual tenemos un gran número de ordenadores separados pero interconectados entre sí a través de una red.

Desde el momento en que tenemos una red (RTB, LAN, MAN, WAN, etc…) sobre un soporte físico capaz de unir dos ordenadores podemos hablar de acceso remoto como el sistema de alcanzar un ordenador distante geográficamente para trabajar con él en las mismas condiciones que si estuvieramos sentados delante de una de sus terminales conectada por la línea serie (control remoto del ordenador).

El modo de acceso remoto ha variado considerablemente a lo largo de los años en función de la evolución de las tecnologías y expansión de las redes de datos. Inicialmente el acceso remoto sólo se entendía como la posibilidad de conexión a un gran ordenador central vía módem por RTB en modo terminal. Posteriormente, y con la difusión de las redes locales y metropolitanas, surgieron nuevos sistemas y protocolos de acceso remoto a ordenadores dentro de la misma red que permitían compartir los recursos disponibles por un ordenador a todos los de la red. Hoy en día el término "acceso remoto" se simplifica erróneamente muchas veces como la conexión de un ordenador que está en Internet hacia otro, o bien con el típico acceso a Internet suministrado por un PSI desde un PC con módem.

A continuación veremos una clasificación de tipos de acceso remoto en función de la clase de conexión disponible:

Las líneas dedicadas son apropiadas para sitios con un gran número de usuarios con gran volumen de datos para recibir u ofrecer. Debido a su alto coste suele ser una solución demasiado cara para pequeñas empresas o usuarios individuales. Una línea dedicada conecta habitualmente una red local a otra red local de la misma compañía o bien a Internet. Todos los usuarios de la red local tendrán conexión dedicada full-time con la otra red local o Internet. Hay varios tipos de conexiones sobre líneas dedicadas pero todas ellas tienen dos cosas en común: las redes locales están conectadas a un router y hay una línea suministrada por la compañía telefónica entre los dos routers. Podemos ver el caso típico de una gran empresa que consigue el acceso remoto a Internet desde su red local de la forma siguiente:

Las diferentes tecnologías empleadas en la industria de las telecomunicaciones permite diferente tipos de circuitos sobre estas líneas. Tradicionalmente se ha usado los circuitos punto a punto digitales o analógicos, pero también tenemos alternativas como SMDS (Switched Multimegabit Digital Service), Frame Relay, o ATM (Asynchronous Transfer Mode).

La principal diferencia de las conexiones dialup con respecto a las líneas dedicadas es que para estar conectados remotamente debemos iniciar una conexión marcando un número de teléfono y dicha conexión durará únicamente lo que dure nuestra sesión de trabajo, mientras que sobre líneas dedicadas tenemos una conexión permanente full-time y además el costo será fijo independientemente del tiempo que utilicemos el medio.

Las conexiones dialup son apropiadas para usuarios individuales y pequeñas empresas debido a su bajo menor costo. Podemos dividir los tipos de conexiones dialup en 3 grupos:

Una cuenta de trabajo online es una cuenta en un ordenador que se encuentra dentro de la red a la que queremos acceder, por ejemplo Internet. Nuestro ordenador local trabaja como una simple terminal de caracteres, y el software de comunicaciones suministra una emulación de terminal. Cuando llamamos al ordenador remoto debemos dar el nombre de usuario y el password asociado.

Muchos de los proveedores de acceso remoto público utilizan UNIX en sus sistemas, y cuando nos conectamos a ellos disponemos de una sesión shell o bien un menú de servicios con una lista de utilidades que podemos utilizar desde esa máquina tales como Gopher, WAIS, WWW (en modo carácter), telnet, ftp, y en general cualquier programa disponible en el ordenador remoto.

La mayor pega de esta modalidad de trabajo es que si queremos transferir ficheros por ejemplo de un host de Internet hacia nuestro puesto de trabajo debemos hacerlo en dos pasos. En primer lugar usaremos FTP para descargar los ficheros sobre el ordenador que nos da la cuenta de trabajo, y después transmitirlos a nuestro puesto local con un programa de transferencia de ficheros estándar tal como kermit, ymodem, zmodem, etc.

Otra forma más flexible de utilizar cuentas on-line que nos permite además elegir el servidor host dentro de una red local es realizar una conexión a un servidor de terminales y después, desde la línea de comandos del servidor de terminales, inicial una sesión telnet o LAT (o cualquier otro protocolo que entiendan ambos) con el host. En el gráfico siguiente se ven estas dos formas de conexión:

A diferencia del método anterior, cuando tenemos una conexión SLIP o PPP podemos decir que nuestro ordenador local tiene capacidad completa de conexión en Internet, y puede intercambiar paquetes con otros ordenadores de la red utilizando su protocolo nativo IP. Podremos por tanto correr aplicaciones de red como FTP, WAIS, WWW localmente. Otro gran beneficio de este tipo de conexión es que podemos abrir sesiones múltiples con diferentes ordenadores a la vez.

Si el objetivo es usar SLIP y PPP para salir a Internet es importante que nuestro proveedor nos suministre los siguientes datos para configurar nuestro ordenador local:

Por último hay que comentar otro tipo de conexión SLIP y PPP más avanzada: disponer de un router SLIP/PPP (Netblazer de Telebit por ejemplo). Esta solución se adapta mejor a redes locales, ya que de esta forma cada ordenador de la red local no necesita un módem ni una configuración SLIP/PPP, basta con indicarles quién es el router SLIP/PPP en la red. De esta forma, el router establece la conexión dialup cuando lo necesita y de cara al usuario aparenta que tenemos una línea dedicada. Esta forma de trabajo era utilizada hasta hace muy poco por el C.I.D.I.R. en el Campus de Gipuzkoa de la Universidad del Pais Vasco para integrar en su red FDDI y dar acceso hacia Internet a los centros lejanos donde no llegaba la fibra óptica.

Otra alternativa a las líneas de teléfono básicas es utilizar otro tipo de conexión dialup como RDSI o X.25. En ambos casos los proveedores de acceso necesitan instalar conexiones especiales (aunque en RDSI esto se reduce a cambiar el PTR de RJ-11 a RJ-45 si nuestra centralita local ya es digital) Comentaremos brevemente las características de RDSI.

Las velocidades conseguidas actualmente sobre líneas telefónicas analógicas ronda los 56 Kbps. Las líneas RDSI son digitales y se componen de dos tipos de canales: Canal B, que transporta voz o datos a una velocidad de 64Kbps y el canal D, que transporta la señalización de llamada (canal de control).

La línea RDSI debe instalarla la compañía telefónica tanto en el servidor como en la instalación remota. También es necesaria una tarjeta RDSI en lugar de un módem. El costo del equipo y las líneas RDSI será mayor que el de los módems y las líneas telefónicas estándar, aunque la mayor velocidad de comunicación reduce la duración de las conexiones y por tanto el gasto global.

Para hacernos una idea de velocidades y precios, Telefónica en España ofrece dos tipos de instalación RDSI. En la modalidad de "Acceso Básico" nos ofrece dos canales de tipo B y un canal D (32.480 pts de alta + 4.408 de cuota mensual) y en la modalidad de "Acceso Primario", treinta canales de tipo B y uno tipo D de 64Kps (696.000 pts de alta + 66.120 de cuota mensual).

SLIP es un viejo protocolo diseñado en 1984 inicialmente para conectar estaciones de trabajo Sun a Internet a través de una línea telefónica usando un módem. Se trata de un protocolo punto a punto muy sencillo, descrito en RFC 1055. La estación sólo envía paquetes IP en bruto a través de la línea, con un byte indicador especial (0xC0) al final para delimitar el paquete. Si existe otro byte 0xC0 dentro del paquete, se usa una forma de relleno, enviando la secuencia de dos bytes (0xDB, 0xDC) en su lugar. Si también tenemos un byte de datos 0xDB dentro del paquete, también se rellena.

Las versiones más recientes de SLIP efectúan cierta compresión de encabezados TCP e IP. Lo que hacen es aprovechar el hecho de que los paquetes enviados consecutivos tienen con frecuencia muchos campos de encabezado en común; la técnica de compresión consiste en omitir aquellos campos que son iguales a los campos correspondientes del paquete IP previo. Incluso los campos que sí difieren no son enviados en su totalidad, sino como incrementos del valor previo. Estas optimizaciones se describen en RFC 1144.

Aunque el uso de SLIP estuvo muy generalizado, tenía varios problemas serios que se citan a continuación y exigían la aparición de otro protocolo más robusto:

1. SLIP no efectúa detección o corrección de errores, por lo que es responsabilidad de los niveles superiores detectar y recuperar los paquetes perdidos o dañados.
2. SLIP solo reconoce IP. Con el crecimiento de Internet para abarcar redes que no usan IP (tales como redes locales Novell, o NetBEUI), esta restricción se vuelve cada vez más grave.
3. Cada extremo de la conexión debe conocer por adelantado la dirección IP del otro; ninguna de las dos direcciones puede asignarse dinámicamente durante el establecimiento del enlace. Dada la escasez actual de direcciones IP, esta limitación es importante, pues es imposible asignar a cada usuario que se conecta desde su domicilio una dirección IP única.
4. SLIP no proporciona ninguna forma de verificación de autenticidad, por lo que ninguna parte sabe realmente con quién está hablando. Con líneas dedicadas no es un gran problema, pero sí con líneas de RTB.
5. SLIP no es un estándar aprobado en Internet, por lo que existen muchas versiones diferentes e incompatibles que complican la interconexión.

La IETF (Internet Engineering Task Force) creó un grupo de trabajo dedicado a diseñar un protocolo de enlace de datos para líneas punto a punto (no necesariamente sobre líneas serie) que resolviera todos los problemas de SLIP y que pudiera convertirse en un estándar oficial para Internet. Este trabajo culminó con el PPP, que se define básicamente en RFC 1661, y se ha desarrollado más en RFC 1662 y 1663. A diferencia de SLIP, PPP realiza detección de errores, reconoce múltiples protocolos, permite la negociación de direcciones IP en el momento de la conexión y permite la verificación de autenticidad. El futuro está claramente en PPP, tanto para enlaces sobre líneas de RTB como incluso sobre líneas dedicadas de router a router. PPP proporciona tres grandes ventajas:

Para ver la manera en que encajan estos mecanismos, vamos a considerar la típica situación de un usuario particular que llama a un proveedor de servicios de Internet para convertir su PC en un host temporal de Internet. El PC llama inicialmente al router del proveedor a través de un módem. Cuando el módem del router contesta y se ha establecido la conexión física, el PC manda al router una serie de paquetes LCP en el campo de datos sobre uno o varios paquetes PPP. Tras varios intercambio de paquetes LCP, se seleccionan los parámetros PPP que se van a usar en la conexión.

Después debemos configurar el nivel de red enviando una serie de paquetes NCP. Si el PC va a utilizar TCP/IP, necesita una dirección de red IP. Como ya se ha comentado antes, no hay una dirección IP para cada PC particular, por lo que el proveedor de Internet tendrá un bloque de ellas y asignará una dinámicamente al PC que se acaba de conectar enviándole una serie de paquetes NCP.

A partir de ese momento, el PC ya es un host de Internet y pude enviar y recibir paquetes IP igual que los hosts que están permanentemente conectados. Cuando el usuario ha terminado la sesión de trabajo, se usan ciertos paquetes NCP para destruir la conexión de la capa de red y liberar la dirección IP. Después se cierra la conexión de enlace de datos mediante los adecuados paquetes LCP. Por último, el PC indica al módem que cuelgue la línea, liberando así la conexión de la capa física. Esto sería un cierre ordenado de la sesión consensuado por ambos pares, sin embargo por economía telefónica y de direcciones IP, la mayoría de los proveedores aplican un tiempo de time-out por encima del cual, si no se reciben o envían paquetes cierran automáticamente la conexión con el PC.

El diagrama de fases para activar y desactivar una línea es el siguiente:

En cuanto al formato de los paquetes PPP, hay señalar su gran parecido a HDLC, con la diferencia de que el primero está orientado a caracteres, y el segundo a bits. Además no sólo pueden mandarse paquetes PPP a través de líneas telefónicas, sino también, como ya se ha dicho anteriormente, sobre líneas dedicadas o HDLC auténticas orientadas a bits, como por ejemplo un enlace punto a punto entre dos routers. Gráficamente el formato de cada paquete PPP es el siguiente:

Todos los paquetes comienzan con el byte estándar de HDLC (01111110). Después viene el campo de dirección, al que siempre se le asigna 11111111 para indicar que todas las estaciones deben aceptar el paquete. Este valor sirve únicamente para evitar tener que asignar direcciones de enlace de datos.

El campo de dirección va seguido del campo de control, cuyo valor predeterminado es 00000011. Este valor indica un paquete sin numeración, es decir, que PPP no proporciona por defecto transmisión confiable usando números de secuencia y acuses de recibo. En redes ruidosas se puede aplicar el modo numerado para transmisión confiable definido en RFC 1663. Dado que los campos dirección y control son constantes, LCP proporciona los mecanismos necesarios para que las dos partes negocien una opción que los omita.

El campo de protocolo indica la clase de paquete que está en el campo de datos. Se definen códigos para LCP, NCP, IP, IPX, AppleTalk y otros protocolos. Los protocolos que comienzan con 0 son protocolos del nivel de red como IP, IPX, OSI. Los que comienzan por 1 se usan para negociar otros protocolos. Estos incluyen un LCP y NCP diferente para cada protocolo del nivel de red reconocido.

El campo de datos es de longitud variable, hasta algún máximo negociado. Si la longitud no se negocia con LCP, se usa una longitud predeterminada de 1500 bytes. De ser necesario, se puede incluir caracteres de relleno después de los datos. Por último viene el campo de comprobación, que suele ser de 2 ó 4 bytes.

Todos los sistemas UNIX soportan una serie de servicios llamados UUCP utilizados para la transferencia de datos sobre líneas telefónicas. Este tipo de acceso remoto está en desuso, pero fue muy común hasta la llegada del SLIP para recibir el correo electrónico de Internet desde servidores de correo o para recoger las news de USENET a intervalos regulares de tiempo. UUCP nos permite leer y enviar correo y news, pero a diferencia de SLIP o PPP no nos proporciona un acceso directo a Internet durante la conexión, sino que podemos verlo como un método de transferencia regular de ficheros sobre RTB, aunque también se puede emplear sobre redes TCP/IP. La gran ventaja de UUCP y motivo de su gran difusión es que se trata un software de libre distribución incluido con el sistema UNIX.

UUCP es un término que incluye, además de un protocolo de transferencia de ficheros, varias utilidades que describimos brevemente a continuación:

Cuando Internet no estaba tan extendida como hoy en día y apenas había Proveedores de Servicio, las empresas o centros en general que querían poner información pública a sus clientes se limitaban a crear una BBS sobre un ordenador al que se accedía por línea telefónica desde cualquier parte del mundo. Este sistema de acceso requería programas de acceso remoto que por una parte fueran capaces de recuperar errores en la transmisión sobre la poco fiable línea de RTB, y por otra que contaran con potentes algoritmos de compresión de datos para reducir al máximo el tiempo de conexión.

Algunos de estos programas son Kermit, ymodem, xmodem, ymodem, y zmodem, cada cual más evolucionado que el anterior, pero en definitiva todos dan las mismas utilidades:

Son los dos protocolos de acceso remoto y transferencia de ficheros respectivamente más conocidos actualmente pero hay que clasificarlos fuera de todos los vistos anteriormente por ser protocolos de niveles superiores que necesitan tener TCP/IP por debajo, que a su vez podría tener como otro protocolo remoto de enlace a PPP o SLIP.

Su gran difusión es debida una vez más a Internet, por ser protocolos (con sus aplicaciones respectivas) incluidos en UNIX para acceso a Internet, aunque también se han convertido en estándares de facto para acceso remoto dentro de redes locales o metropolitanas basadas en TCP/IP, habiendo sido adoptados por todos los sistemas operativos actuales. Ambos utilizan la arquitectura cliente servidor y sólo basan su seguridad en el viejo sistema de cuenta y password siempre y cuando no haya otro sistema adicional (como Kerberos) en ambos extremos (cliente y servidor).

El objetivo de este tipo de softwares es poder utilizar un PC con Windows para controlar otro PC remoto también con Windows. La información introducida desde el teclado o el ratón del ordenador Guest (el que inicia la comunicación) es enviada al PC Host (el que es controlado), así como la salida acústica y de vídeo. No hace falta que los PC conectados remotamente utilicen el mismo tipo de pantalla, teclado o ratón. La comunicación entre ambos PC se realiza a través del puerto serie con conexión directa o mediante módem, o bien, si los dos están en la misma red local, se puede implementar el control remoto utilizando protocolos de enlace sobre la red local tales como IPX o NetBIOS.

Existen varios softwares comerciales de control remoto, tales como Cubix o pcANYWHERE. A continuación se enumeran las características y los programas de utilidad incluidos dentro de uno tomado como ejemplo: Microcom Carbon Copy.

Este es el programa fundamental de Carbon Copy, y permite, como ya se ha dicho antes, usar un PC remoto como si estuviéramos sentados delante de él. El Control Remoto puede ser iniciado por el usuario Guest o por el usuario Host, aunque quien controla el PC Host es siempre el usuario Guest. El uso de este programa de control remoto suele ser: