Introdução

Embora seja uma forma prática de acessar máquinas remotamente, o VNC possui duas graves
limitações, que são o baixo desempenho quando usado através de conexões lentas (como uma rede
wireless congestionada) ou via Internet e a falta de suporte a conexões simultâneas no Windows, o
que limita bastante seu uso.

No Linux, a ferramenta de acesso remoto mais utilizada é o SSH (que veremos a seguir), enquanto o
Windows oferece um protocolo próprio de acesso remoto, o RDP, que permite o acesso tanto a partir
de outras máquinas Windows quanto a partir de clientes Linux, como você pode ver no screenshot
abaixo, onde temos uma máquina com o Ubuntu acessando uma estação com o Windows XP:

O RDP é um protocolo bem mais eficiente que o VNC, que se baseia no envio de instruções em vez de
bitmaps com screenshots da tela. O cliente recebe as instruções e as combina com ícones e outros
elementos para montar novamente as janelas. Isso faz com que usar o servidor remotamente seja
uma experiência muito parecida com usá-lo localmente, além de melhorar bastante a qualidade do
acesso via Internet. Outro fator essencial é que ele permite que vários usuários se conectem
simultaneamente ao servidor, abrindo sessões independentes, o que é impossível ao usar o VNC para
Windows.

O RDP é usado desde a época do Windows NT. Ele surgiu como um protocolo para administração
remota dos servidores Windows, mas foi logo expandido e transformado em um protocolo de acesso
remoto, dando origem ao Windows Terminal Services (WTS), que permite que vários usuários se
conectem simultaneamente à mesma máquina Windows de forma a usar o sistema e rodar aplicativos.
Todo o processamento é feito no servidor, permitindo que ele seja usado mesmo em máquinas antigas
ou em terminais burros, com pouco poder de processamento.

Além da baixa utilização da rede, o algoritmo de compressão do RDP também consome menos
recursos do servidor, o que permite o uso de mais terminais simultaneamente. De uma forma geral,
um servidor equipado com um processador Core 2 Duo, Athlon X2 ou superior e 2 GB de memória
RAM, pode atender 50 clientes simultâneos rodando aplicativos leves, ou de 15 a 25 clientes
simultâneos rodando aplicativos mais pesados.

O maior obstáculo é a questão do licenciamento, pois além da licença do servidor, você precisa de
licenças para os clientes. Além disso, apenas as versões server do Windows, incluindo o Windows
2000 Server, 2003 Server e 2008 Server (com exceção do Windows Server 2003 Web Edition)
oferecem o pacote completo, onde o número de sessões simultâneas é limitado apenas ao hardware
do servidor e ao número de licenças. As máquinas com as versões domésticas do Windows XP e do
Vista também podem ser acessadas remotamente, mas sem suporte a várias conexões simultâneas
(quando você se loga remotamente, ele coloca a sessão local em espera e ao se logar localmente ele
fecha a conexão remota).

Uma solução para permitir mais conexões simultâneas em máquinas com o Windows XP é usar o XP
Unlimited, que remove a barreira técnica, permitindo abrir um número indefinido de conexões, assim
como no Windows 2003 Server.

A versão demo disponível no http://www.xpunlimited.com/demo.html (apenas para uso não-

comercial) permite três conexões simultâneas. Para liberar o uso de mais conexões, é necessário
comprar a versão completa. Note que embora o XP Unlimited remova a limitação técnica, a questão
do licenciamento fica nebulosa, já que em tese o Windows XP não poderia ser usado simultaneamente
por mais de um usuário, sem que cada um tivesse uma licença. Verifique essa questão antes de
considerar o uso em ambientes de produção.

Outra opção para destravar o acesso de vários clientes simultaneamente é uma modificação do
arquivo termsrv.dll, combinado com uma chave de registro. Na verdade, o limite no número de
conexões é apenas uma trava artificialmente adicionada no sistema. Sem ela, mesmo o Windows XP
suporta vários clientes simultâneos. Você pode baixar uma versão modificada do arquivo, juntamente
com os scripts de instalação no: http://dot651.blog.com/1883945/.

Para instalar, basta descompactar o arquivo e executar os scripts "Install RDP.bat" e "TS Reg
Patch.reg", que se encarregam de copiar a dll e inserir a chave no registro. Se o link estiver fora do
ar, pesquise por "Unlimited Remote Desktop Connections" ou pelo arquivo "URDPC.zip". Vale lembrar,
entretanto, que usar a dll modificada viola potencialmente o contrato de licença do Windows, por isso
você deve usá-lo apenas para testes ou em ambiente doméstico.
Em um ambiente de produção, o correto é utilizar um servidor com o Windows 2003 Server,
acompanhado por um licensing server (servidor de licenciamento), que nada mais é do que um
servidor Windows 2003 Server separado, rodando o serviço "Terminal Server Licensing", que pode ser
instalado através do Windows Components Wizard. É possível também instalar o serviço no próprio
servidor principal, evitando assim a necessidade de usar uma máquina separada.

Sem o licensing server, o servidor Windows vai fornecer licenças temporárias para os clientes, o que
pode ser usado para fins de teste e avaliação. Entretanto, isso só funciona por um período de 120
dias; depois disso o Terminal Services deixa de funcionar até que o licensing server seja instalado.
Como você pode ver, a única função do licensing server é verificar o licenciamento; uma norma
burocrática que aumenta os custos e faz com que você tenha mais trabalho. Infelizmente é assim que
as coisas funcionam dentro do mundo Windows.

As licenças para os terminais são chamadas de CALs (Client Access License). Existem dois tipos de
licença, por máquina (per device) e por usuário (per user) e você pode escolher qual dois dois
sistemas usar através do "Administrative Tools > Terminal Services Configuration > Server Settings >
Licensing > Licensing Mode" (no servidor Windows).

Ao usar o sistema por máquina, você compra uma licença para cada micro da rede e eles podem ser
utilizados por um número indefinido de usuários (desde que um usuário por micro de cada vez). Ao
optar pelo licenciamento por usuário, você adquire uma licença para cada usuário da rede, que passa
a poder se logar em qualquer máquina.

Salvo exceções, se você possui mais usuários do que máquinas (como em um Cybercafé, onde cada
cliente tem um login separado, por exemplo), as licenças por máquina são mais vantajosas, enquanto
em situações onde os usuários tem liberdade para se logar remotamente a partir de qualquer PC, as
licenças por usuário são mais recomendáveis. Como de praxe, é recomendável se informar sobre a
questão do licenciamento e calcular os custos antes de implantar o servidor. Veja mais detalhes no:
http://support.microsoft.com/default.aspx?scid=kb;en-us;823313.

Ativando o serviço
Voltando à parte técnica, para ativar o acesso remoto em uma máquina Windows, clique com o botão
direito no "Meu Computador" e, no menu "Propriedades do Sistema", acesse a aba "Remoto" e
marque a opção "Área de trabalho remota".

Clique no botão "Selecionar usuários remotos" e indique quais logins de acesso poderão ser usados
remotamente. Por padrão, apenas o Administrador e o usuário atualmente logado (que você está
utilizando para fazer a configuração) podem acessar:
No Windows 2003 Server, abra o wizard "Configure Your Server" e ative a opção "Terminal Server" na
página "Server Role", o que vai instalar os arquivos necessários para ativar o serviço.

Para que os usuários possam usar o terminal server, é necessário cadastrá-los no grupo "Remote
Desktop Users". Você pode fazer isso através do "Administrative Tools > Computer Management >
Local Users and Groups > Groups". Clicando com o botão direito sobre o grupo, você tem a opção de
adicionar usuários a ele:
Ao usar o Active Directory, você pode também ajustar algumas opções relativas às sessões remotas
dentro da aba "Sessions" das propriedades de cada usuário no Administrative Tools > Active Directory
Users and Computers. A principal observação nesse caso é que você deve usar servidores separados
como controlador de domínio e como terminal server. Por segurança, ao ativar o uso do terminal
server em um servidor configurado como controlador de domínio, o sistema bloqueia o acesso de
todos os usuários, com exceção dos administradores.

Nem todos os programas podem ser usados facilmente no servidor de terminais, já que é necessário
que o programa possa ser executado por usuários sem privilégios administrativos, suporte o uso de
múltiplas instâncias, entre outros detalhes, mas o número de aplicativos incompatíveis vem caindo
bastante.

Uma dica para minimizar os problemas é instalar os aplicativos usando o "Adicionar ou remover
programas" do Painel de controle em vez de simplesmente clicar sobre o instalador do programa.
Isso faz com que o sistema execute algumas verificações adicionais, instalando o programa dentro das
pastas correspondentes do sistema (e não mais dentro da pasta de documentos do usuário ou outra
localização fora do padrão), além de ativar um conjunto de checagens relacionadas ao uso de
múltiplas sessões do programa e ao compartilhamento do espaço de memória usado por ele; dois
fatores fundamentais para que ele possa ser usado por diversos usuários simultaneamente.

No Vista, a opção para ativar o WTS está escondida dentro do "Painel de Controle > Sistema >
Configurações avançadas do sistema > Remoto". Assim como no XP e no 2003 Server, você precisa
definir senhas para as contas de usuário e indicar manualmente os usuários que devem ter acesso,
usando o botão "Selecionar usuários":

É importante enfatizar que apenas os usuários com senhas definidas podem acessar as máquinas
remotamente. Todos os logins sem senha são automaticamente recusados. Você pode definir as
senhas na seção "Contas de usuário" do Painel de Controle. No caso do 2003 Server, é necessário que
os usuários que irão acessar o servidor sejam incluídos no grupo "Remote Desktop".

Como todos os usuários utilizarão a mesma máquina, é importante ajustar os privilégios das contas,
de forma que os usuários remotos não possam fazer modificações que afetem os outros usuários. Dar
privilégios de administrador para todos os usuários, como muitas vezes é feito em micros desktop,
pode ser desastroso ao usar o Terminal Services.
Em caso de problemas na ativação, acesse a opção "Ferramentas administrativas > Serviços" do
Painel de Controle e verifique se os serviços "Alocador Remote Procedure Call (RPC)" e "Serviços de
terminal" estão ativados. Verifique também se a porta TCP 3389, usada pelo Terminal Services está
aberta no firewall (em caso de dúvida, experimente desativar o firewall e refazer o teste).

Clientes Windows
Nos clientes Windows XP, você encontra o cliente RDP no "Iniciar > Todos os programas > Acessórios
> Comunicações > Conexão de área de trabalho remota". Por padrão, o programa pede apenas o
nome, domínio ou endereço IP do servidor onde se conectar, mas clicando no botão "Opções" você
tem acesso a um conjunto mais generoso de opções:
O default é abrir a conexão em tela cheia e utilizar 16 bits de cor, mas você pode ajustar a resolução,
fazendo com que o desktop remoto seja aberto em uma janela na aba "Exibição". O Terminal Services
permite redirecionar o fluxo de áudio da sessão diretamente para o cliente, além de permitir o acesso
a impressoras, unidades de disco e dispositivos diversos instalados nas portas seriais do cliente.
Continuando, a aba "Programas" permite especificar um programa que será aberto automaticamente
ao abrir a conexão (um aplicativo de gerenciamento ou agenda de grupo que deve ser usado por
todos os usuários, por exemplo) e a aba "Experiência" permite ajustar opções relacionadas à conexão,
desativando animações e a exibição do papel de parede entre outras opções.

O "Conexão de área de trabalho remota" não está disponível no XP Home e no Vista Home Basic.
Neles, você pode instalar o Terminal Services Client, disponível no:
http://support.microsoft.com/kb/925876

No caso dos servidores 2003 ou 2008 Server, existe também um serviço de acesso via web, que fica
disponível para os clientes através do endereço "http://servidor/tsweb". Ele é baseado no uso de
controles ActiveX, por isso só funciona corretamente no Internet Explorer, o que limita seu uso aos
clientes Windows.

Clientes Linux
Naturalmente, além de ser acessado pelos clientes Windows, o servidor pode também ser acessado
pelos clientes Linux da rede. Esta é uma forma prática de disponibilizar alguns aplicativos Windows
específicos para os usuários em máquinas Linux, sem precisar manter instalada uma cópia do
Windows em dual-boot ou usar o VMware para rodá-lo em uma VM em cada máquina.

Esta solução é muito usada por empresas que migram as estações de trabalho para Linux, mas
precisam manter algumas cópias do Windows para rodar alguns aplicativos específicos. Ao invés de
manter máquinas com o Windows, ou rodá-lo via VMware, pode fazer mais sentido manter um
servidor Windows na rede, com o acesso remoto ativado e permitir que os usuários abram sessões
remotas quando necessário.

Nos clientes Linux, usamos o rdesktop, que pode ser tanto utilizado via linha de comando, quanto
através do TSclient, Krdc ou outra das interfaces de acesso remoto que oferecem suporte a ele. O
uso mais simples para o rdesktop é simplesmente passar o endereço IP ou domínio da máquina
remota como argumento, como em:

$ rdesktop 192.168.0.1

O problema é que ele vai utilizar todas as opções default, abrindo uma tela de 800x600 com 256
cores. O protocolo RDP v5 (usado no Windows XP e no 2003 server) suporta o uso de 16 bits de cor.
Para ativar o recurso, inclua as opções "-5 -a 16" (o -5 é a versão do protocolo e o -a 16 especifica os
bits de cor), como em:

$ rdesktop -5 -a 16 192.168.0.1

Para especificar a resolução, use a opção "-g", seguida pela resolução desejada, como em:

$ rdesktop -5 -a 16 -g 1000x700 192.168.0.1

Ao especificar a resolução, você pode usar qualquer número que adapte a janela ao seu desktop. Não
é necessário se limitar às resoluções padrão. Para abrir a sessão em tela cheia, use a opção "-f", como
em:

$ rdesktop -5 -a 16 -f 192.168.0.1

(pressione "Ctrl+Alt+Enter" para chavear entre o modo fullscreen e janela)

Outra opção útil, sobretudo ao criar scripts de conexão é a opção "-u", que permite especificar o
usuário com o qual será aberta a conexão, de forma que ele já fique pré-selecionado na tela de login.
Um exemplo de uso seria:

$ rdesktop -5 -a 16 -u gdh -f 192.168.0.1

Ao acessar uma máquina XP ou 2003 server, você pode também redirecionar o som para o cliente, de
forma que os sons dos aplicativos sejam tocados usando a placa de som e caixas do seu micro, ao
invés de no servidor. Funciona mesmo que o servidor não possua placa de som.
Esse é um recurso que deve ser usado com cautela em redes com muitos clientes, ou via Internet,
pois gera um fluxo de aproximadamente 800 kbits para cada cliente usando o som. Para ativar,
adicione a opção "-r sound:local=/dev/dsp", como em:

$ rdesktop -5 -a 16 -r sound:local=/dev/dsp 192.168.0.1

Note que o "/dev/dsp" indica o dispositivo da placa de som no cliente. Se não funcionar da primeira
vez, verifique as permissões de acesso (no cliente). Caso necessário, abra as permissões usando o
comando "chmod 666 /dev/dsp" (como root, no cliente).

É possível também "compartilhar" pastas no cliente, de forma que os arquivos sejam acessados
dentro da sessão remota. Você pode, por exemplo, editar documentos em uma pasta dentro do seu
home, usando os programas instalados no servidor. Para isso, adicione a opção "-r disk:nome=pasta",
onde o "nome" indica como ele será visto dentro da sessão e a "pasta" é a pasta no cliente que está
sendo "compartilhada". Esta opção pode ser usada em combinação com as anteriores, como em:

$ rdesktop -5 -a 16 -r sound:local=/dev/dsp -r disk:arquivo=/home/joao

192.168.0.1

As pastas compartilhadas aparecem dentro do "Meu Computador > Outros", como se fossem
compartilhamentos de rede montados:
Para compartilhar o CD-ROM, pendrive ou disquete, basta indicar a pasta onde eles ficam acessíveis,
como em "-r disk:cdrom=/mnt/cdrom" ou "-r disk:pendrive=/mnt/pendrive". A observação, nesse
caso, é que você vai sempre precisar montar o CD-ROM ou pendrive no cliente para acessá-lo dentro
da sessão remota. O comando simplesmente compartilha os arquivos acessíveis dentro da pasta.

É possível, ainda, mapear a impressora, de forma que você consiga imprimir na impressora instalada
no seu cliente Linux de dentro dos aplicativos na sessão remota. Se os clientes e o servidor estão na
mesma rede local, é mais simples compartilhar a impressora via Cups ou Samba e instalá-la no
servidor. O mapeamento de impressoras do RPD, por sua vez, permite usar as impressoras quando
isso não é uma opção, como ao acessar um servidor via Internet.
Em primeiro lugar, a impressora deve estar instalada no cliente e você deve conseguir imprimir nela
usando o lpr. Nas distribuições derivadas do Debian, instale o pacote "cupsys-bsd" (que substitui o
lpr); caso contrário, nada vai funcionar.

Ao conectar no servidor, é preciso especificar o nome da impressora, da forma como é vista pelos
aplicativos no cliente e também o driver Windows (esta é a parte mais complicada...) que o servidor
vai usar na hora de enviar trabalhos para ela, como em:

$ rdesktop -5 -a 16 -r printer:e230="Lexmark Optra E+ (MS)" 192.168.0.1

Para descobrir o driver da Impressora no Windows, abra o assistente de instalação de impressora,

indique o fabricante e copie o nome que aparece no menu da esquerda:

No caso de impressoras paralelas, você pode também redirecionar a porta "/dev/lp0". Nesse caso,
você poderia instalar a impressora dentro da sessão remota, como se ela estivesse instalada no
próprio servidor, adicionando o parâmetro "-r lptport:LPT1=/dev/lp0" ao comando de conexão. É
possível, ainda, redirecionar portas seriais, usando a opção "-r comport:COM1=/dev/ttyS0".

Como viu, o rdesktop suporta um grande número de opções, o que torna os comandos de acesso
bastante longos. É aí que entra o TSclient, que permite especificar as opções através de uma interface
muito mais amigável. Ele está disponível em várias distribuições; nas derivadas do Debian, você pode
instalá-lo via apt-get. A página oficial é a http://gnomepro.com/tsclient/.

Outra opção é criar ícones nos desktops dos usuários. O ícone pode disparar um comando com o
rdesktop cuidadosamente personalizado, de forma a já abrir a janela de conexão com a resolução
desejada e já especificando o login usado e os parâmetros necessários para compartilhar a impressora
e as pastas desejadas, de forma que o usuário tenha apenas o trabalho de clicar.

No KDE, clique com o botão direito sobre o desktop e use a opção "Criar Novo > Link para Aplicativo".
O comando a executar vai no campo Aplicativo > Comando". Um exemplo de comando a usar seria:
"rdesktop -g 1024x768 -u gdh 192.168.0.1":

TSclient (à esquerda) e propriedades do ícone de atalho com o comando para se conectar ao servidor
diretamente

Mais dicas
Como comentei, o uso do Terminal Services, combinado com o rdesktop é uma boa opção para casos
em que você precisa oferecer o uso de aplicativos Windows para os usuários da rede, ao usar Linux
nos desktops, sem com isso precisar manter o sistema instalado em dual-boot em todas as máquinas,
ou precisar usar máquinas virtuais com o VMware.
Manter um único servidor com o Windows 2003, ou com o Windows XP (mais o XP Unlimited) acaba
sendo uma solução muito mais simples e barata, sobretudo em casos em que os usuários precisam
apenas de alguns serviços específicos.

Quando falo em "servidor" você pode ter a idéia de se tratar de uma máquina parruda, com vários
gigabytes de memória e discos em RAID, mas isso não vem ao caso. Se a idéia for que o servidor
atenda apenas a um pequeno volume de acessos, ou que atenda apenas um usuário por vez (que
seria o caso de uma máquina com o Windows XP, sem o XP Unlimited), você pode usar basicamente
qualquer máquina com uma placa de rede onde você consiga instalar o sistema.

Você pode inclusive usar alguma máquina antiga. No meu caso, por exemplo, uso esse resto de
notebook, o "hp":
Ele é um HP nx6110, com um Celeron 1.4, que foi aposentado depois que o LCD quebrou. Depois de
doar a placa wireless e o drive de CD-ROM, ele acabou ficando com pouca utilidade. Apesar disso, ele
funciona muito bem como mini-servidor, já que tem potência suficiente para rodar aplicativos básicos,
consome pouca energia (por ser um notebook) e tem um nobreak embutido (a bateria).

Outra possibilidade com relação ao uso de micros antigos é transformá-los em clientes de um servidor
WTS. O cliente passa então a simplesmente carregar um cliente RDP para obter a tela de login do
servidor e rodar os aplicativos através dele, funcionando como um terminal burro.

Uma boa opção é o AnywhereTS, um aplicativo Windows que gera uma imagem bootável, que permite
inicializar os clientes via CD ou via rede, através de um servidor TFTP. Como todo o software é obtido
via rede, os clientes não precisam sequer de um HD instalado.

A imagem gerada é na verdade uma mini-distribuição Linux, que inicializa o cliente e usa o rdesktop
para obter a tela de login do servidor. O executável do AnywhereTS é na verdade apenas um
configurador, que reúne as informações necessárias e gera a imagem:

O wizard precisa basicamente do endereço IP do servidor e do driver que será usado pela placa de
vídeo, rede e som, além do layout de teclado que será usado nos clientes. No caso dos drivers, você
pode usar a opção "Autodetect", que faz com que o sistema de boot tente detectar os dispositivos
durante a inicialização do sistema. Você pode gerar alguns CDs "genéricos" usando a detecção
automática e deixar para criar imagens com os drivers indicados manualmente para inicializar os
clientes problemáticos.