| Howto - Servidor proxy 7. Instalando o Servidor de Proxy TIS 7.1. Buscando o software O TIS FWTK se encontra em ftp://ftp.tis.com/. Não cometa o mesmo engano que eu fiz. Quando você esta nos arquivos de ftp do TIS, LEIA OS README's. O fwtk do TIS é colocado em diretório escondido no servidor deles. TIS requer que você envie um email para [email protected] com a palavra SEND no corpo da mensagem para saber o nome do diretório escondido. Não é necessário nenhum assunto na mensagem. O sistema deles verá a correspondência e então você receberá o nome do diretório (bom durante 12 horas) para baixar o arquivo. Enquanto eu estou escrevendo o TIS está lançando a versão 2.0 (beta) do FWTK. Esta versão parece compilar bem (com alguns exceções) e tudo está funcionando para o meu uso. Esta é a versão que eu estarei cobrindo aqui. Quando eles lançar o código final eu atualizarei o HOWTO. Instale o FWTK, crie um diretório fwtk-2.0 no seu diretório /usr/src. Mova a sua cópia do FWTK (fwtk-2.0.tar.gz) para este diretório e descompacta ele (tar zxf fwtk-2.0.tar.gz). O FWTK não faz proxy SSL de documentos Web mas há um complemento para isto escrito por Jean-Christophe Touvet. É encontra-se no ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z. Touvet não faz apóio sobre o código. Eu estou usando uma versão modificada que inclui acesso para o Secure Netscape e o servidores de notícias escritos por Eric Wedel. Está disponível em ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z. Em nosso exemplo eu usarei a versão do Eric Wedel. Instale ele, simplesmente crie um diretório de ssl-gw em seu diretório /usr/src/fwtk-2.0 e o ponha lá. Quando eu instalei este gateway ele requereu algumas mudanças antes de compilar com o resto do toolkit. A primeira mudança era ao arquivo de ssl-gw.c. Eu achei que não precisava incluir este arquivo. Defined(__linux de #if) Segundo é que não veio com um Makefile. Eu copiei um outro do diretório do gateway e substitui o nome do gateway por ssl-gw. 7.2. Compilando o TIS FWTK Versão 2.0 do FWTK compilou fácil em relação as mais velhas versões. Eu ainda achei várias coisas que precisaram ser mudadas antes de que a versão BETA compilace completamente. Espero ansiomente estas mudanças sejam feitas na versão final. Arrume ele, comece mudando o diretório de /usr/src/fwtk/fwtk contido no arquivo Makefile.config.linux em cima do arquivo Makefile.config NÃO RODE o FIXMAKE. As instruções lhe dizem que o execute. Se você o faz o arquivo makefile quebra em relação a cada diretório. Eu tive uma dificuldade com o fixmake. O problema é o script do sed adicione um '.' e '' para a linha que contem o Makefile. Estes é o trabalho no script do sed. sed 's/^include[ ]*\([^ ].*\)/include \1/' $name .proto > $name Logo nós precisamos editar o arquivo de Makefile.config. Há duas mudanças que você pode precisar fazer. O autor fixou o diretório de fonte para o diretório home dele. Nós iremos compilar o nosso código em /usr/src assim você deve mudar a variável FWTKSRCDIR para refletir isto. FWTKSRCDIR=/usr/src/fwtk/fwtk Segundo, pelo menos alguns sistema do Linux o banco de dados de gdbm. O Makefile.config está usando dbm. Você pode precisar mudar isto. Eu tive que fazer para RedHat 3.0.3. DBMLIB=-lgdbm A última dificuldade está no x-gw. O bug na versão BETA é no código do socket.c. Configure isto removendo estas linhas de código. #ifdef SCM_RIGHTS /* 4.3BSD Reno and later */ Se você somar o ssl-gw ao seu fonte FWTK no diretório que você precisa some na lista de diretório no Makefile. DIRS= smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw
x-gw ssl-gw 7.3. Instalando o TIS FWTK Rode o make install. O diretório de instalação default é /usr/local/etc. Você pode mudar isto (eu não o fiz) para um diretório mais seguro. Eu escolhi mudar o acesso a este diretório para 'chmod 700'. Depois agora resta é configurar o firewall. 7.4. Configurando o TIS FWTK Agora é que realmente começa a diversão. Nós temos que ensinar o sistema a chamar os novos serviços e criar uma tabela de controles. Eu não vou tentar ré-escrever o manual do TIS FWTK aqui. Eu mostrarei a você a colocação de como estou trabalhado e explico os problemas que ocorreram quando eu fui rodar eles. Há três arquivos que compõem estes controles. · /etc/services · Chama um serviço para a porta do sistema aberta. · /etc/inetd.conf · Chama o programa inetd que define quando alguém bate em uma porta de serviço. · /usr/local/etc/netperm-table · Chama os serviços de FWTK que permitir e negam os serviços. Para chamar as funções do FWTK, você precisa edita os arquivos acima. Editando os arquivos de serviços sem o arquivo inetd.conf ou netperm-table configurados corretamente o seu sistema pode ficar inacessível. 7.4.1. O arquivo de netperm-table Estes controles do arquivo podem ter acesso aos serviços do TIS FWTK. Você deva pensar no tráfico que é usar o firewall de ambos os lados. Pessoas de fora da sua network deveriam se identificar antes de ganhar acesso, mas as pessoas de dentro de sua network poucos poderiam ser permitidos. Assim as pessoas podem se identificar, o firewall usa um programa chamado authsrv para manter um banco de dados de IDs do usuário IDs e a password. A seção de autenticação do netperm-table controla onde o banco de dados é mantem quem pode ter acesso. Eu tive alguma dificuldade de fechar o acesso para este serviço. Note a linha premit-host Eu usei um '*' para dar ha todo mundo acesso. A colocação correta para esta linha é '' authsrv: localhost de premit-host localhost se você quer trabalhar com isto. # Inicializar o banco de dados, su para o root, e executar ./authsrv no Diretório do /var/local/etc para criar o registro de usuário administrativo. Aqui é uma sessão de amostra. Leia a documentação de FWTK para aprender a somar os usuários e grupos. # A porta de controle do telnet (tn-gw) são dianteiros e o primeiro você deve montar. Eu permito que o host de dentro da network privada possa passar em meu exemplo, sem se autenticar. (permit-hosts 19961.2.* -passok) Mas, qualquer outro usuário tem que entrar no ID do usuário e com a password para usar o proxy. (permit-hosts * -auth) Eu também permito que um outro sistema (196.1.2.202) tenha acesso ao meu firewall diretamente sem passar pelo firewall. As duas linhas inetacl- in.telnetd do in.telnetd faz isto. Eu explicarei como estas linhas são chamadas posteriormente. O intervalo de Telnet deveria ser mantido pequeno. # telnet gateway rules: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd Os r-comandos trabalham do mesmo modo como o telnet. # rlogin gateway rules: Você não deve deixar que ninguém tenha acesso ao seu firewall diretamente e isso inclui o FTP assim não põe um servidor de FTP, no seu firewall. Novamente, a linha de permit-hosts permite que qualquer um na network protegida acesse livremente a Internet e tudos os outros têm que autenticar eles. Eu incluí um arquivo de logs de envio e recebimento no meu controle. (-log { retr stor }) O intervalo do ftp controla quanto tempo leva para derrubar um conexão péssima como também quanto tempo uma conexão ficará aberto com nenhuma atividade. # ftp gateway rules: Web, gopher e browser baseado em ftp são controlados pelo http-gw. As primeiras duas linhas criam um diretório para armazenar documentos do ftp e do web de como eles estão atravessando o firewall. Eu faço estes arquivos na raiz e pôs o em um diretório acessível só através da raiz. A conexão de Rede deve ser mantida pequena. Controlar quanto tempo o usuário espere em uma conexão ruim. # www and gopher gateway rules: O ssl-gw é uma passagem real como qualquer outra porta. Seja cuidadoso com isto. Neste exemplo eu permito que qualquer um de dentro da network protegida possa se conectar a qualquer servidor de fora da network menos nos endereços 127.0.0.* e 192.1.1.* e então só em portas 443 até 563. Portas 443 até 563 são portas conhecidas do SSL. # ssl gateway rules: Aqui é um exemplo de como usar um plug-gw permitir que as conexões para um servidor de news. Neste exemplo eu permito que qualquer um dentro da network protegida possa conectar a só um sistema e só para isto é a porta de news. A segunda linha permite ao servidor de notícias passar os seus dados através da network protegida. Porque a maioria dos clientes espera ficar conectados enquanto o usuário leia as notícias, o intervalo para um servidor de news deve ser longo. # NetNews Pluged gateway A porta do finger é simples. Qualquer um de dentro da network protegida deve logar-se primeiro e então nós lhes permitimos usar o programa finger no firewall. Se não é enviado uma mensagem. # Enable finger service Eu não tenho configuração de Correio e serviços de X-window assim eu não estou incluindo estes exemplos. Se qualquer um tem um exemplo em funcionamento, por favor envia-me um email. 7.4.2. O arquivo de inetd.conf Aqui esta um arquivo de /etc/inetd.conf completo. Tudos serviços têm um comentário por fora. Eu incluí o arquivo completo para mostrar como desligar tudo, e como também as configurações para os novos serviços do firewall. #echo stream tcp nowait root internal 7.4.3. O arquivo de /etc/services Isto é aonde tudo começa. Quando um cliente conecta o firewall isto conecta em uma porta conhecido (menos em 1024). Por exemplo o telnet conecta na porta 23. O deamon do inetd ouve esta conexão e olha para o nome deste no arquivo de /etc/services. E então chamada o programa definido no nome do arquivo /etc/inetd.conf. Alguns dos serviços que nós estamos criando normalmente não são no arquivo /etc/services. Você pode nomear alguns deles a qualquer porta que você quer. Por exemplo, eu nomeei o telnet do administrador para porta(telnet-a) 24. Você poderia nomear isto para aportar 2323 se você desejar. Para o administrador (VOCÊ) conectar diretamente ao firewall você vai precisar que o telnet não acesse 24 nem 23 e se você configurar o seu arquivo netperm-table, como eu fiz, você só será capaz de dentro da sua network protegida. telnet-a 24/tcp 8. O Servidor de Proxy do SOCKS 8.1. Configurando um Servidor de Proxy O servidor de proxy do SOCKS está disponível em ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux- src.tgz. Também há um exemplo de config dentro deste diretório chamado de "socks-conf". Descompacte e utilizar o tar no arquivo em um diretório do seu sistema, e siga as instruções em como instalar. Eu tive alguns problemas quando eu fiz isto. Tenha certeza que seu Makefiles estão corretos. Uma coisa importante para notar é que o servidor de proxy precisa ser anexado no /etc/inetd.conf. Você tem que anexar a seguinte linha: socks stream tcp nowait nobody /usr/local/etc/sockd sockd avisa ao servidor para roda-lo quando pedido. 8.2. Configurando o Servidor de Proxy Os programas SOCKS precisam de dois arquivos de configuração separados. Um conta o acesso permitido, e um dirigi os pedidos apropriados para o servidor de proxy. O arquivo de acesso deve ser colocado no servidor. O arquivo de roteamento deve ser colocado em toda máquina Un*x. O DOS e, presumivelmente, computadores Macintosh farão o seu próprio roteamento. 8.2.1. O Arquivo de Acesso Com o socks4.2 Beta, o arquivo de acesso é chamado de "sockd.conf". Deve conter 2 linhas, uma de permição(permit) e um de linha de negação(deny). Cada linha terá três entradas: · O Identifier (permit/deny) · O endereço do IP · O modificador de endereço O identifier é o que permite ou nega. Você deve ter ambos um linha de permição e um de negação. O endereço IP é formado de quatro byte de enreçamento de IP típico de anotação. I.E. 192.168.2.0. O modificador de endereço também é um IP típico que envia quatro número de byte. Funciona como um netmask. Verefique este número para ser 32 bits (1s ou 0s). Se o bit é um 1, o bit correspondente do endereço que isto está conferindo tem que emparelhar o bit correspondente no campo do endereço IP. Por exemplo, se a linha é: permit 192.168.2.23 255.255.255.255 permitirá que somente o endereço IP se emparelhar com todo o bit em 192.168.2.23, isto é, somente 192.168.2.3. A linha: permit 192.168.2.0 255.255.255.0 permita que todo número dentro de grupo 192.168.2.0 até 192.168.2.255, a Classe C inteira do domínio. Você não deve ter a seguinte linha: permit 192.168.2.0 0.0.0.0 como isto permitirá todos os endereço, indiferentemente. Assim, primeiro permite todo endereço que você quer permitir, e então negue o resto. Permiti que todo mundo no domínio 192.168.2.xxx, com a seguintes linhas: permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 configure corretamente. Note que o primeiro "0.0.0.0" na linha de negação. Com um modificador de 0.0.0.0, o IP se dirigem ao campo não se importando. Todos os 0's é a norma porque é fácil de digitar. Mais de uma entrada de cada é permitido. Também podem ser concedidos a usuários específicos ou podem ser negados acesso. Isto é via a autenticação do ident. Nem todos os sistemas apóiam o ident e incluindo o Trumpet Winsock, assim eu não irei mostra isto. A documentação do socks é bastante adequado neste assunto. 8.2.2. O Arquivo de roteamento O arquivo de rotemaneto no SOCKS é chamado probremente de "socks.conf". Eu digo "chamado pobremente" porque é parecido com o nome do arquivo de acesso isto é fácil para obter duas confusões. O arquivo de roteamento é chamado para os clientes do SOCKS quando usa o socks e quando não. Por exemplo, em nossa network, 192.168.2.3 não vai precisar usar o socks para falar com 192.168.2.1, firewall. Tem uma conexão direta por Ethernet. Define 127.0.0.1, o loopback, automaticamente. Claro que você não precisa de SOCKS para acessar a você mesmo. Há três entradas: · negação (deny) · direct · Sockd Negue os acessos para o SOCKS quando rejeitar um pedido. Esta entrada tem o mesmo três campos como em sockd.conf, identificador, endereço e modificador. Geralmente, desde que isto também seja para o sockd.conf, o arquivo de acesso, o campo de modificador é fixado em 0.0.0.0. Se você quer impedir você pode chamar de qualquer lugar, você pode fazer isto aqui. A entrada direct conta quais são os endereços que não usaram o socks. Estes são todos os endereços que podem ser alcançados sem o servidor de proxy. Novamente nós temos os três campos, identificador, endereço e modificador. Nosso exemplo seria direct 192.168.2.0 255.255.255.0 Indo direto assim a qualquer parte de nossa network protegida. A entrada do sockd conta ao computador que o host tem o servidor de daemon de socks. A sintaxe é: sockd @= Note a entrada @=. Isto permite lhe definir os endereços de IP de um lista de servidores de proxy. Em nosso exemplo, nós usamos somente um servidor de proxy. Mas, você pode ter muitos para permitir uma maior carga e para a redundância em caso de fracasso. O endereço de IP e campos do modificador trabalham igual como nos outros exemplos. Você tem que especificar quais os endereços que vão poder acessar. 6.2.3. DNS por detrás de um Firewall. Configurar um Serviço de Nomes de Domínio por detrás um firewall é um tarefa relativamente simples. Você precisa montar o DNS somente na máquina com o firewall. Então, definir cada máquina atrás do firewall para usar este DNS. 8.3. Trabalhando Com um Servidor de Proxy 8.3.1. Unix Para ter suas aplicações trabalhando com o servidor de proxy, eles precisam ter o "sockified". Você precisará de dois telnets diferente, um para acessar a comunicação, e um para comunicação pelo servidor de proxy. O SOCKS vem com instruções de como definir um programa SOCKify, como também vários programas de pre-SOCKified. Se você usa a versão de SOCKified para acessar algum direct, o SOCKS trocarão automaticamente um pelo outra versão para você. Por causa disto, nós queremos mencionar novamente que todos os programas em nossa network protegida é substituida com os programas do SOCKified. "finger" se torna "finger.orig , "telnet" se torna "telnet.orig", etc. Você tem que dizer ao SOCKS sobre cada um destes no arquivo de include/socks.h. Certos programas acessarão o roteamento e o sockifying nisto. O Netscape é um deles. Você pode usar um servidor de proxy dentro do Netscape com entradas no endereço do servidor (192.168.2.1 em nosso caso) nos campos de Socks dentro do Proxy. Cada aplicação precisará de pelo menos um pouco de arrumação embora de como acessar um servidor de proxy. 8.3.2. MS Windows com o Trumpet Winsock O Trumpet Winsock vem embutido com capacidades para oe servidor de proxy. No menu de "setup", entre o endereço IP do servidor, e os endereços de todo os computadores que acessam diretamente. O Trumpet define todos os pacotes de inicialização. 8.3.3. Acessando um Servidor para usar pacotes com UDP O SOCKS trabalha somente com pacotes do TCP, e não UDP. Isto faz com que prejudique em muitas utilizações. Muitos programas úteis, como o talk, o Archie, use o UDP. Há um pacote projetadou para ser usado com um servidor proxy para pacotes de UDP chamado UDPrelay, por Tom Fitzgerald, [email protected]. Infelizmente, na hora deste trabalho, ele ainda não é compatível com o Linux. 8.4. Desvantagens com o Servidores de Proxy O servidor de proxy é, acima de tudo, um dispositivo de segurança. Usando para acessar a internet e aumentar os endereços de IP limitados terá muitas desvantagens. Um servidor de proxy permitirá maior acesso de dentro da sua network protegida para o exterior, mas manterá o interior completamente inacessesivel do exterior. Isto significa que nenhum servidor, usará conexões de talk ou o archie, ou acessar aos computadores interiores. Estas desvantagens poderiam parecer leves, mas pensa do seguinte modo: · Que você deixou um relatório que você está fazendo em seu computador dentro de um network protegida com firewall. Você está em casa, e decide que você gostaria de revisar. Você não pode. Você não pode alcançar o seu computador porque está atrás de um firewall. Você tenta acessar no firewall primeiro, mas então todo mundo tem o acesso do servidor de proxy, e ninguém, montou uma conta para você. · Que sua filha vai para faculdade. Você quer enviar um email para ela. Você tem algumas coisas privadas para falar, e teria seu mail enviado diretamente da sua máquina. Você confia em no seu administrador de sistema completamente, mas ainda, este é um mail privado. · A inabilidade para usar pacotes de UDP representa uma desvantagem grande com o servidores de proxy. Eu imagino outras capacidades de UDP que estarão vindo brevemente. O FTP causa outro problema com um servidor de proxy. Se você usar um ls, o servidor de FTP abre uma cova na máquina de cliente e envia a informação. Um servidor de proxy não permiti isto, assim o FTP não trabalha particularmente. E, servidores de proxy rodam lentamente. Por causa do overhead, quase todos os pedidos necessitam de acesso rapidamente. Basicamente, se você tem um endereço IP, e você não está preocupado com a segurança, não use firewall e/ou servidores de proxy. Se você não tem um endereço de IP, mas você também não esta preocupado com a segurança, você também pode querer olhar sobre emluador de IP, como o Term, Slirp ou TIA. O Term está disponível no ftp://sunsite.unc.edu, Slirp esta disponível em ftp://blitzen.canberra.edu.au/pub/slirp, e TIA esta disponível em marketplace.com. Estes pacotes rodam mais rapidos, permiti conexões melhores, e provê um nível maior de acessos para dentro da network da internet. Servidores de proxy são bons para cadeias que têm muitos hosts que querem conectar a internet voando, com uma configuração e pouco trabalho depois. 9. Configurações avançadas Há uma configuração que eu gostaria de revisar antes de acabar este documento. Eu há pouco esbocei suficientemente provavelmente bastará para a maioria das pessoas. Porém, eu penso que o próximo esboço mostrará uma configuração mais avançada que pode clarear algumas perguntas. Se você tiver perguntas além do que eu há pouco cobri, ou há está interessado na versatilidade de servidores de proxy e firewalls, prosseguida lendo. 9.1. Uma grande network com ênfase na segurança Por exemplo, digamos que você seja o líder de millisha e você quer uma network local. Você tem 50 computadores e um subnet de 32 (5 bits) numeros de IP. E você precisa de vários níveis de acesso dentro de sua network porque você diz para os seus seguidores coisas diferentes. Então, você vai precisar proteger certas partes da sua network do resto. Os níveis são: 1. O nível externo. Este é o nível para o que é mostrado para todo mundo. todo o mundo. Aqui é aonde você divulga e delira para adquirir os novos voluntários. 2. Tropa. Este é o nível das pessoas além do que adquiriram do nível externo. Aqui é onde você os ensina sobre o governo demôniaco e como fazer bombas. 3. Mercenário. Aqui é onde são mantidos realmente os planos. Neste nível é armazenado toda a informação em como o 3º governo mundial vai assumir o mundo, seus planos envolvendo o Newt Gingrich, a Cidade de Oklahoma, lown se preocupam produtos e que realmente é armazenado e cabe nesta área 51. 9.1.1. A Configuração da Network Os números de IP são organizados como: · O número 1 é o 192.168.2.255 que é o broadcast e não é utilizável. · São alocados 23 dos 32 endereços de IP para 23 máquinas que serão acessível a internet. · 1 IP extra vai para uma linux naquela cadeia · 1 extra vai para um linux diferente naquela cadeia. · 2 IP #'s vão para o roteador · 4 permanecem, menos os que são determinados domínio nomeiados como paul, ringo, john, e george, só para confundir as coisas um pouco. · As networks protegidas têm os endereços 192.168.2.xxx Então, são construídas duas networks separadas, cada uma quartos diferentes. Elas são roteadas por Ethernet de infra-vermelho de forma que são completamente invisíveis para o quarto externo. Por sorte, o funcionamento de ethernet de infra-vermelho há pouco funcionam como uma ethernet normal. Estas networks são cada conectados a um dos linux com um endereço extra de IP. Há um servidor de arquivo que conecta as duas networks protegidas. Isto porque os planos por assumir o mundo envolvem algumas das Tropas mais altas. O servidor de arquivo assegura o endereço 192.168.2.17 para a Network da tropa e 192.168.2.23 para a network Mercenária. Elas tem IP diferente que acessam porque tem que ter placas deEthernet diferentes. O IP Forwarding está desligado. IP Forwarding em ambas os Linux também estão desligados. O roteador não vai por pacotes que destinaram para 192.168.2.xxx a menos que explicitamente contasse para fazer isto, assim a internet não podera entrar. A razão para IP Forwarding estar desligado aqui é de forma que os pacotes da Network da Tropa não podeça alcançar a network Mercenária, e vica-versa. O servidor de NFS também pode ser definido aqui para oferecer arquivos diferentes para as networks diferentes. Isto pode ser feito à mão, e um pouco de artifícios com vínculos simbólicos pode fazer isto de forma que os arquivos comuns pode ser compartilhados com todos. Usando esta ligação e outra placa de ethernet podemos oferecer um servidor de arquivos para todas as três networks. 9.1.2. A Configuração do Proxy Agora, desde que todos os três níveis querem poder monitorar a network para os próprios propósitos desviados, toda as três necessitam ter acesso certo. A network externa é conectada diretamente na internet, assim nós não temo que fazer configuração dos servidores de proxy aqui. A netowrks dos Mercenário e da Tropa estão atrás de firewalls, assim é necessário montar o servidor de proxy. Ambas as cadeias serão muito semelhantemente na configuração. Ambas têm o mesmo Endereços de IP nomeadas nelas. Eu defini vários parâmetros, só fazer isto mais interessante. 1. Ninguém pode usar o servidor de arquivo para acesso a internet. Isto expõe o servidor de arquivo para vírus e outras coisas sórdidas, e é bastante importante, assim se for fora dos limites. 2. Nós não permitir-mos o acesso de tropa ao World Wide Web. Eles estão em treinando, e este tipo de poder de recuperação de informação poderia danificar o aprendizado. Assim, o arquivo do sockd.conf arquivam no linux da Tropa terá esta linha: deny 192.168.2.17 255.255.255.255 e na máquina Mercenária: deny 192.168.2.23 255.255.255.255 E, no linux da Tropa terá esta linha deny 0.0.0.0 0.0.0.0 eq 80 Isto diz para negar o acesso para todas as máquinas que tentam acessar a porta igual (eq) a 80, a porta de http. Isto ainda permitirá todos os outros serviços, só neguando o acesso ao Web. Então, ambos os arquivos terão: permit 192.168.2.0 255.255.255.0 permiti que todos os computadores na network 192.168.2.xxx pode usar o servidor de proxy com exceção desses que já foram negados (ie. o servidor de arquivo e o acesso a Web da network da Tropa). O arquivo de sockd.conf da Tropa será assim: deny 192.168.2.17 255.255.255.255 e o arquivo do Mercenário será como: deny 192.168.2.23 255.255.255.255 Agora, assuma o mundo! Autor: Mark Grennan - ([email protected]); Traduzido por: Bruno H. Collovini - ([email protected] |