Capítulo 12. Redes

O processo de processo de inicialização sem disco implica na possibilidade de uma máquina FreeBSD ser inicializada através da rede, lendo os arquivos necessários à partir de um servidor, ao invés de um disco rígido. Para maiores detalhes, por favor, consulte o ítem diskless booting no Manual do FreeBSD.

Pode. Por gentileza, refira-se à documentação do Manual do FreeBSD sobre configurações avançadas de rede, mais especificamente, a seção sobre roteamento e gateways.

Normalmente, as pessoas que propõem esse tipo de questão possuem dois computadores em casa, um com FreeBSD e outro com Win95. A idéia é utilizar a maquina com FreeBSD para se conectar à Internet, e então oferecer acesso Internet a máquina Win95 através do FreeBSD. Essa é apenas uma extensão especial da questão anterior.

... e a resposta é sim! No FreeBSD 3.x, o ppp(8) em modo usuário oferece a opção -nat. Se o ppp(8) for executado com essa opção, basta definir a variável gateway_enable para YES no arquivo /etc/rc.conf, e configurar corretamente a máquina Windows. Isso é o bastante.

Para obter mais informações, por gentileza, refira-se a página de manual do ppp(8)

Se o ppp(8) estiver sendo usado em modo kernel (kernel-mode) ou a conexão com a Internet for via Ethernet, a opção mais viável será utilizar o natd(8). Por favor, consulte a seção natd dessa documentação.

Claro. Veja as páginas de manual do slattach(8), sliplogin(8), ppp(8), e pppd(8). O ppp(8) e o pppd(8) oferecem suporte à conexões entrantes e de saída (conexões incoming/outgoing), enquanto o slattach(8) à conexões de saída (outgoing).

Para obter mais informações sobre a correta utilização desses recursos, por gentileza, refira-se ao Capítulo sobre PPP e SLIP do Manual do FreeBSD.

Se o seu acesso à Internet for apenas por meio de uma conta Shell, pode ser interessante dar uma olhada no port da aplicação net/slirp. Esse port oferece acesso (limitado) à serviços como FTP e HTTP direto da máquina local.

Se no seu caso, existe uma subrede (uma ou mais máquinas locais interconectadas em rede), mas o seu Provedor de Internet disponibiliza apenas um IP (ou se o endereço IP em questão é dinâmico), com certeza é interessante dar uma olhada no natd(8). O natd(8) possibilita que uma subrede inteira acesse a Internet através de um único endereço IP.

O ppp(8) oferece suporte interno à essa mesma funcionalidade, através da opção -nat do programa. A biblioteca libalias(3) é usada tanto pelo ppp(8) quanto pelo natd(8).

Por gentileza, refira-se à seção sobre PLIP do Manual do FreeBSD.

Porque não é preciso! Na estrutura de redes de Berkeley, as interfaces de rede são acessadas somente (e diretamente) pelo código do kernel. Por favor verifique o arquivo /etc/rc.network e as páginas do manual para os diversos programas de rede ali mencionados, para maiores informações. Se isto deixá-lo completamente confuso, consulte um livro que descreva a administração de rede em um outro sistema operacional baseado no modelo BSD. Com poucas exceções significativas, a administração de rede em sistemas FreeBSD é basicamente a mesma da utilizada em sistemas como o SunOS 4.0 ou o Ultrix.

Se a intenção é definir um apelido IP para uma subrede previamente configurada, basta adicionar a máscara 0xffffffff junto à sintaxe usual para definição de alias no ifconfig(8):

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Do contrário, basta definir o endereço de rede e a netmask em questão, da forma tradicional:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Se você deseja utilizar uma outra interface de conexão, deverá especificar alguns parâmetros adicionais na linha de comando do ifconfig(8). A porta padrão é a link0. Para usar a porta AUI ao invés da porta BNC utilize a flag link2. Tais flags devem ser definidas através das variáveis ifconfig_* no arquivo /etc/rc.conf. (consulte o rc.conf(5)).

Certas interfaces de rede para PC são melhores do que outras (para adotarmos um eufemismo) e as vezes podem causar problemas em aplicações que utilizam a rede de modo intensivo, como o NFS.

Consulte o item NFS do Manual do FreeBSD para obter mais informações sobre o assunto.

Algumas versões do código NFS do Linux aceitam requisições de montagem provenientes apenas de portas privilegiadas, experimente o comando:

# mount -o -P linuxbox:/blah /mnt

Estações de trabalho Sun rodando SunOS 4.X aceitam requisições de montagem provenientes apenas de portas privilegiadas, experimente o comando:

# mount -o -P sunbox:/blah /mnt

O problema mais freqüente é o não entendimento correto do formato do arquivo /etc/exports. Por gentileza, leia com atenção a página de manual do exports(5) e a documentação sobre NFS no Manual do FreeBSD, especialmente a seção sobre a configuração do NFS.

Experimente desabilitar a variável TCP extensions no arquivo /etc/rc.conf (consulte rc.conf(5)) alterando a variável abaixo para NO:

tcp_extensions=NO

Máquinas Annex da Xylogic também apresentam um problema similar neste aspecto, e você deve adotar a mesma solução para conectar-se a estes sistemas.

Desde o FreeBSD 2.0 que operações Multicast são completamente suportadas por padrão. Se a itenção é fazer o sistema FreeBSD atuar como um roteador multicast, será necessário que o kernel do sistema seja recompilado com a opção MROUTING e que o mrouted(8) seja executado. O FreeBSD, à partir da versão 2.2, pode iniciar o mrouted(8) durante o processo de inicialização se a variável mrouted_enable estiver configurada com o parâmetro "YES" no arquivo /etc/rc.conf.

As ferramentas MBONE estão disponíveis em sua própria categoria na coleção de ports, mbone. Se você está procurando as ferramentas de conferência vic e vat, procure neste diretório!

Esta é uma lista compilada por Glen Foster <gfoster@driver.nsta.org>, com algumas adições recentes:

Provavelmente você vai estar trabalhando com estações em domínios diferentes. Por exemplo, se você esta em foo.bar.edu e deseja alcançar uma estação chamada mumble no domínio foo.bar.edu, deverá referir-se à essa esse host através do seu nome de domínio qualificado, mumble.foo.bar.edu, ao invés de apenas mumble.

Normalmente era possível alcançar a estação apenas por seu nome. Essa função era realizada pelos resolvedores BIND do ISC. Contudo, as versões atuais do BIND (veja o named(8)) que acompanham o FreeBSD não oferecem mais abreviações padrão para domínios que não sejam FQDN, com a única exceção do domínio que sua própria estação faz parte. Dessa forma, o host mumble, se não for localizado como mumble.foo.bar.edu, será localizado através de uma busca direta à partir da raiz dos servidores de resolução.

Este comportamento é diferente do verificado anteriormente onde a pesquisa continuaria através de mumble.bar.edu e mumble.edu. Consulte a RFC 1535 para descobrir porque isso é considerado uma prática ruím, e até mesmo uma brecha de segurança.

Uma alternativa é adicionar a linha abaixo:

search foo.bar.edu bar.edu

ao invés da linha previamente existente

domain foo.bar.edu

em seu arquivo /etc/resolv.conf (consulte resolv.conf(5)). Contudo verifique se a ordem de pesquisa não vai além da fronteira entre a administração pública e a local, conforme definido na RFC 1535.

Se o kernel do seu FreeBSD foi compilado com a opção IPFIREWALL, você deve compreender que a política padrão, à partir da versão 2.1.7 (atualmente alterada durante o desenvolvimento da versão 2.1-STABLE) é negar todos os pacotes que não forem explicitamente permitidos.

A seu firewall foi erroneamente configurado, de forma não intencional, a operacionalidade do sistema pode ser restaurada, simplesmente digitando o seguinte (conectado como root):

# ipfw add 65534 allow all from any to any

A variável firewall_type="open" também pode ser definida, no arquivo /etc/rc.conf.

Para maiores informações sobre a configuração de firewall, por gentileza, consulte a seção correspondente no Manual do FreeBSD.

Por gentileza, refira-se ao capítulo sobre Firewalls do Manual do FreeBSD mais específicamente, a seção sobre Overhead & Otimização do IPFW.

Provavelmente porque a verdadeira intenção é traduzir os pacotes que chegam na sua estação, e rescrevê-los para renviar para a outra máquina, e não simplesmente redirecionar o pacote. Normalmente o ideal é fazer NAT (tradução de endereços de rede). Uma regra de reenvio de pacotes, faz exatamente o que ela deve fazer: reenviar pacotes. As regras não alteram (rescrevem) o conteúdo ou cabeçalhos dos dados presentes no pacote. Por exemplo, digamos que a questão seja a seguinte regra:

01000 fwd 10.0.0.1 from any to foo 21

Quando um pacote destinado à estação foo chegar no FreeBSD que filtra essa regra, ele será encaminhado para a máquina cujo endereço IP é 10.0.0.1, mas o endereço de destino original do pacote será mantido, ou seja, os pacotes chegando em 10.0.0.1 ainda terão a estação foo como destino final, marcado em seu cabeçalho TCP. O endereço de destino não é alterado (reescrito) para a máquina 10.0.0.1, o que propicia um comportamento de verificação de checksum do cabeçalho IP. O comportamento normal é que a máquina 10.0.0.1 descarte o pacote, já que o endereço de destino do mesmo não é o endereço da estação em questão. Esse comportamento costuma confundir alguns usuários menos experientes, não correspondendo a ação com suas expectativas. Essa é uma característica do IPFW, e não um problema.

Consulte o FAQ sobre Redirecionamento de Serviços, a página de manual do natd(8), ou uma das diversas ferramentas de redirecionamento disponíveis na Coleção de Ports, para verificar a forma correta de obter o comportamento desejado.

Serviços como FTP (e outros) podem ser redirecionados com o pacote socket, disponível na árvore de Coleção do Ports, sob a categoria “sysutils”. Simplesmente substitua a linha de comando do serviço a ser redirecionado para executar a ferramenta socket, como no exemplo abaixo:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

Onde ftp.foo.com e ftp são a máquina (host) e a porta de conexão que será utilizada para o redirecionamento, respectivamente.

Existem três ferramentas de gerenciamento de banda disponíveis para o FreeBSD. O dummynet(4), integrada ao FreeBSD (ou mais especificamente ao ipfw(4));, o ALTQ, disponível gratuitamente, e o Bandwidth Manager da Emerging Technologies, um produto comercial.

Você está tentando usar um programa que precisa do Berkeley Packet Filter (veja a página de manual do bpf(4) para obter maiores informações), mas ele não está compilado no kernel. Adicione a seguinte linha no arquivo de configuração do seu kernel e recompile-o:

pseudo-device bpf        # Berkeley Packet Filter

Depois que reiniciar o sistema com o novo kernel, basta criar a interface do dispositivo, o que pode ser feito ao executar o seguinte comando, no diretório /dev:

# sh MAKEDEV bpf0

Por gentileza, refira-se à seção sobre Criação de interface de Dispositivos do Manual do FreeBSD, para obter mais informações sobre o assunto.

Use o conjunto de ferramentas SMBFS. Se trata de um conjunto de modificações no kernel, e uma série de aplicações específicas. O programa e outras informações podem ser obtidos na Coleção de Ports do FreeBSD, em net/smbfs, ou no sistema base do FreeBSD a partir da versão 4.5-RELEASE.

É o resultado de seu kernel informando-o que alguma atividade esta provocando o envio de um número de respostas ICMP ou TCP reset (RST) superior ao número que o kernel julga adequado. Respostas ICMP são, geralmente, comportamento ocasionado pela tentativa de conexão em portas UDP não utilizadas. As respostas TCP reset são o resultado gerado pelas tentativas de conexão em portas TCP não poníveis. Entre outras causas, algumas das atividades que podem ocasionar esse tipo de mensage, são:

• Ataques de negação de serviço (DoS) por força bruta (em oposição a ataques baseados em um único pacote que visa explorar uma vulnerabilidade específica).

• Varreduras de porta (port scans) que visam rastrear um elevado número de portas (em oposição a ataques que tentam varrer apenas um pequeno número de portas conhecidas).

O primeiro número (valor) na mensagem indica quantos pacotes foram enviados pelo kernel antes do limite passar a vigorar e o segundo valor indica o limite estabelecido no kernel. Você pode controlar este limite através da variável net.inet.icmp.icmplim do sysctl com instruções como esta abaixo, onde estabelecemos um limite de 300 pacotes por segundo:

# sysctl -w net.inet.icmp.icmplim=300

Se a intenção é não registrar essas mensagens nos arquivos de registros, mas ainda assim manter a capacidade do kernel limitar as respostas, a variável net.inet.icmp.icmplim_output do sysctl pode ser usada para desabilitar o registro:

# sysctl -w net.inet.icmp.icmplim_output=0

Finalmente se a inteção é desabilitar esse comportamento por completo, basta definir a variável net.inet.icmp.icmplim do sysctl (conforme o exemplo acima) como 0. Desabilitar o recurso de limite de resposta é desencorajado pelas razões acima expostas.

Significa que alguma interface de rede no mesmo barramento Ethernet que você, está usando um endereço de MAC cujo formato não é reconhecido pelo FreeBSD. Provavelmente isso deve estar sendo causado por algum outro usuário, fazendo experiências com placas Ethernet em algum lugar na sua mesma rede. Em redes com Cable Modens esse comportamento é ainda mais comum; não é prejudicial e não atrapalha a performance do seu FreeBSD.

Primeiro, verifique se as mensagens de erro em questão são como essas:

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

Esse tipo de erro se deve à instalação do port net/cvsup em estações sem o XFree86. Se a inteção é usar a interface gráfica oferecida pelo CVSup, então instale o XFree86 imediatamente. Do contrário, se a intenção é usar o CVSup apenas por linha de comando, basta desinstalar a aplicação anterior e instalar o port net/cvsup-without-gui. A seção sobre CVSup do Manual do FreeBSD cobre essas questões de forma mais detalhada.