Capítulo 31. Rede Avançada

31.1. Sinopse

Este capítulo aborda vários tópicos avançados de rede.

Depois de ler este capítulo, você saberá:

O básico de gateways e rotas.
Como configurar o USB tethering.
Como configurar os dispositivos IEEE™ 802.11 e Bluetooth™.
Como fazer o FreeBSD atuar como uma Bridge.
Como configurar a inicialização via PXE na rede.
Como configurar o IPv6 em uma máquina FreeBSD.
Como habilitar e utilizar os recursos do Protocolo CARP (Common Address Redundancy Protocol) no FreeBSD.
Como configurar múltiplas VLANs no FreeBSD.
Como configurar um fone de ouvido bluetooth.

Antes de ler este capítulo, você deve:

Entender os fundamentos dos scripts /etc/rc .
Estar familiarizado com a terminologia básica de rede.
Saber como configurar e instalar um novo kernel do FreeBSD ( Configurando o kernel do FreeBSD ).
Saber como instalar software adicional de terceiros ( Instalando Aplicativos. Pacotes e Ports ).

31.2. Gateways e Rotas

O roteamento é o mecanismo que permite que um sistema encontre o caminho da rede para outro sistema. Uma rota é um par definido de endereços que representam o "destino" e um "gateway". A rota indica que, ao tentar chegar ao destino especificado, você deverá enviar os pacotes pelo gateway especificado. Existem três tipos de destinos: hosts individuais, sub-redes e "padrão". A "rota padrão" é usada se nenhuma outra rota for aplicada. Existem também três tipos de gateways: hosts individuais, interfaces, também chamados de links, e endereços de hardware Ethernet (MAC). Rotas conhecidas são armazenadas em uma tabela de roteamento.

Esta seção fornece uma visão geral dos fundamentos de roteamento. Em seguida, ele demonstra como configurar um sistema FreeBSD como um roteador e oferece algumas dicas de solução de problemas.

31.2.1. Fundamentos de roteamento

Para ver a tabela de roteamento de um sistema FreeBSD, use netstat(1) :

% netstat -r
Routing tables

Internet:
Destination      Gateway            Flags     Refs     Use     Netif Expire
default          outside-gw         UGS        37      418       em0
localhost        localhost          UH          0      181       lo0
test0            0:e0:b5:36:cf:4f   UHLW        5    63288       re0     77
10.20.30.255     link#1             UHLW        1     2421
example.com      link#1             UC          0        0
host1            0:e0:a8:37:8:1e    UHLW        3     4601       lo0
host2            0:e0:a8:37:8:1e    UHLW        0        5       lo0 =>
host2.example.com link#1            UC          0        0
224              link#1             UC          0        0

As entradas neste exemplo são as seguintes:

padrão: A primeira rota nesta tabela especifica a rota padrão . Quando o sistema local precisa estabelecer uma conexão com um host remoto, ele verifica a tabela de roteamento para determinar se existe um caminho conhecido. Se o host remoto corresponder a uma entrada na tabela, o sistema verificará se pode se conectar usando a interface especificada nessa entrada.

Se o destino não corresponder a uma entrada ou se todos os caminhos conhecidos falharem, o sistema usará a entrada para a rota padrão. Para hosts em uma rede local, o campo Gateway na rota padrão é definido para o sistema que possui uma conexão direta com a internet. Ao ler esta entrada, verifique se a coluna Flags indica que o gateway é utilizável ( UG ).

A rota padrão para uma máquina que está funcionando como gateway para o mundo externo será a máquina de gateway no provedor de serviços de Internet (ISP).
localhost: A segunda rota é a localhost . A interface especificada na coluna Netif para localhost é lo0 , também conhecido como o dispositivo de loopback. Isso indica que todo o tráfego para esse destino deve ser interno, em vez de enviá-lo pela rede.
Endereço MAC: Os endereços que começam com 0:e0: são endereços de MAC. O FreeBSD irá identificar automaticamente quaisquer hosts, test0 no exemplo, na Ethernet local e adicionará uma rota para aquele host através da interface Ethernet, re0 . Esse tipo de rota tem um tempo limite, visto na coluna Expire , que é usada se o host não responder em um período de tempo específico. Quando isso acontecer, a rota para esse host será automaticamente excluída. Esses hosts são identificados usando o protocolo de informações de roteamento (RIP), que calcula rotas para hosts locais com base em uma determinação de caminho mais curto.
sub-rede: O FreeBSD irá adicionar automaticamente rotas de sub-rede para a sub-rede local. Neste exemplo, 10.20.30.255 é o endereço de broadcast da sub-rede 10.20.30 e example.com é o nome de domínio associado a essa sub-rede. A designação link#1 refere-se à primeira placa Ethernet na máquina.

Hosts de rede local e sub-redes locais têm suas rotas configuradas automaticamente por um daemon chamado routed(8) . Se ele não estiver em execução, somente as rotas definidas estaticamente pelo administrador existirão.
host: A linha host1 refere-se ao host pelo seu endereço Ethernet. Como é o host de envio, o FreeBSD sabe usar a interface de loopback ( lo0 ) em vez da interface Ethernet.

As duas linhas host2 representam os aliases que foram criados usando ifconfig(8) . O símbolo ⇒ após a interface lo0 diz que um alias foi definido além do endereço de loopback. Tais rotas só aparecem no host que suporta o alias e todos os outros hosts na rede local terão uma linha link#1 para tais rotas.
224: A linha final (destino subnet 224 ) lida com multicasting.

Vários atributos de cada rota podem ser vistos na coluna Flags . A Flags da Tabela de Roteamento Frequentemente Observados resume algumas destas flags e seus significados:

Tabela 1. Flags da Tabela de Roteamento Frequentemente Observados
Comando	Propósito
U	A rota está ativa (up).
H	O destino da rota é um único host.
G	Envie qualquer coisa para este destino por este gateway, que ele irá descobrir a partir daí para onde enviá-lo.
S	Esta rota foi configurada estaticamente.
C	Clona uma nova rota baseada nessa rota para as máquinas se conectarem. Esse tipo de rota é normalmente usado para redes locais.
W	A rota foi configurada automaticamente com base em uma rota de rede local (clone).
L	A rota envolve referências a um hardware Ethernet (link).

Em um sistema FreeBSD, a rota padrão pode ser definida no /etc/rc.conf especificando o endereço IP do gateway padrão:

defaultrouter="10.20.30.1"

Também é possível adicionar manualmente a rota usando o comando route :

# route add default 10.20.30.1

Observe que as rotas adicionadas manualmente não sobreviverão a uma reinicialização. Para obter mais informações sobre a manipulação manual das tabelas de roteamento de rede, consulte route(8) .

31.2.2. Configurando um roteador com rotas estáticas

Um sistema FreeBSD pode ser configurado como o gateway padrão, ou roteador, para uma rede se for um sistema dual-homed. Um sistema dual-homed é um host que reside em pelo menos duas redes diferentes. Normalmente, cada rede é conectada a uma interface de rede separada, embora o aliasing IP possa ser usado para vincular vários endereços, cada um em uma sub-rede diferente, a uma interface física.

Para que o sistema encaminhe os pacotes entre as interfaces, o FreeBSD deve ser configurado como um roteador. Padrões da Internet e boas práticas de engenharia impedem o Projeto FreeBSD de habilitar esse recurso por padrão, mas ele pode ser configurado para iniciar na inicialização adicionando esta linha ao /etc/rc.conf :

gateway_enable="YES"          # Set to YES if this host will be a gateway

Para habilitar o roteamento agora, defina a variável sysctl(8) net.inet.ip.forwarding para 1 . Para parar o roteamento, redefina essa variável para 0 .

A tabela de roteamento de um roteador precisa de rotas adicionais para saber como acessar outras redes. Rotas podem ser adicionadas manualmente usando rotas estáticas ou rotas podem ser aprendidas automaticamente usando um protocolo de roteamento. As rotas estáticas são apropriadas para redes pequenas e esta seção descreve como adicionar uma entrada de roteamento estático para uma rede pequena.

Para grandes redes, as rotas estáticas se tornam não escaláveis rapidamente. O FreeBSD vem com o daemon de roteamento BSD padrão routed(8) , que fornece os protocolos de roteamento RIP, versões 1 e 2 e IRDP. O suporte para os protocolos de roteamento BGP e OSPF pode ser instalado usando o pacote ou port net/zebra .

Considere a seguinte rede:

Neste cenário, o RouterA é uma máquina FreeBSD que está agindo como um roteador para o resto da Internet. Ele tem uma rota padrão definida como 10.0.0.1 , que permite a conexão com o mundo externo. O RouterB já está configurado para usar 192.168.1.1 como seu gateway padrão.

Antes de adicionar rotas estáticas, a tabela de roteamento no RouterA se parece com:

% netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif  Expire
default            10.0.0.1           UGS         0    49378    xl0
127.0.0.1          127.0.0.1          UH          0        6    lo0
10.0.0.0/24        link#1             UC          0        0    xl0
192.168.1.0/24     link#2             UC          0        0    xl1

Com a tabela de roteamento atual, o RouterA não tem uma rota para a rede 192.168.2.0/24 . O comando a seguir adiciona a rede Internal Net 2 à tabela de roteamento do RouterA usando 192.168.1.2 como o próximo salto:

# route add -net 192.168.2.0/24 192.168.1.2

Agora, o RouterA pode alcançar qualquer host na rede 192.168.2.0/24 . No entanto, as informações de roteamento não persistirão se o sistema FreeBSD for reinicializado. Se uma rota estática precisar ser persistente, adicione-a ao /etc/rc.conf :

# Add Internal Net 2 as a persistent static route
static_routes="internalnet2"
route_internalnet2="-net 192.168.2.0/24 192.168.1.2"

A variável de configuração static_routes é uma lista de strings separadas por um espaço, onde cada string faz referência a um nome de rota. A variável route_internalnet2 contém a rota estática para esse nome de rota.

Usar mais de uma string em static_routes cria várias rotas estáticas. A seguir, é mostrado um exemplo de adição de rotas estáticas para as redes 192.168.0.0/24 e 192.168.1.0/24 :

static_routes="net1 net2"
route_net1="-net 192.168.0.0/24 192.168.0.1"
route_net2="-net 192.168.1.0/24 192.168.1.1"

31.2.3. Solução de problemas

Quando um espaço de endereçamento é atribuído a uma rede, o provedor de serviços configura suas tabelas de roteamento para que todo o tráfego da rede seja enviado para o link do site. Mas como os sites externos sabem enviar seus pacotes para a rede do ISP?

Existe um sistema que rastreia todos os espaços de endereçamento e define seu ponto de conexão com o backbone da Internet, ou as principais linhas que transportam o tráfego da Internet pelo país e pelo mundo. Cada máquina de backbone possui uma cópia de um conjunto mestre de tabelas, que direciona o tráfego de uma rede específica para uma portadora de backbone específica e, a partir daí, desce a cadeia de provedores de serviços até alcançar uma determinada rede.

É tarefa do provedor de serviços anunciar aos sites de backbone que eles são o ponto de conexão e, assim, o caminho para dentro de um site. Isso é conhecido como propagação de rota.

Às vezes, há um problema com a propagação de rotas e alguns sites não conseguem se conectar. Talvez o comando mais útil para tentar descobrir onde o roteamento está quebrando seja o traceroute . Ele é útil quando o ping falha.

Ao usar o traceroute , inclua o endereço do host remoto para se conectar. A saída mostrará os gateway ao longo do caminho da tentativa, eventualmente atingindo o host de destino ou encerrando devido à falta de conexão. Para mais informações, consulte traceroute(8) .

31.2.4. Considerações sobre Multicast

O FreeBSD suporta nativamente tanto aplicativos multicast e quanto roteamento multicast. Os aplicativos multicast não exigem nenhuma configuração especial para serem executados no FreeBSD. O suporte ao roteamento multicast requer que a seguinte opção seja compilada em um kernel personalizado:

options MROUTING

O daemon de roteamento multicast, mrouted, pode ser instalado usando o pacote ou port net/mrouted . Este daemon implementa o protocolo de roteamento multicast DVMRP e é configurado editando o /usr/local/etc/mrouted.conf para configurar os túneis e o DVMRP. A instalação do mrouted também instala o map-mbone e o mrinfo, bem como suas páginas de manual associadas. Consulte estes documentos para exemplos de configuração.

O DVMRP foi amplamente substituído pelo protocolo PIM em muitas instalações multicast. Consulte pim(4) para obter maiores informações.

31.3. Rede sem fio

31.3.1. Noções básicas sobre redes sem fio

A maioria das redes sem fio é baseada nos padrões IEEE™802.11. Uma rede sem fio básica consiste em várias estações que se comunicam com rádios que transmitem na banda de 2,4 GHz ou 5 GHz, embora isso varie de acordo com a localidade e também esteja mudando para permitir a comunicação nas faixas de 2,3 GHz e 4,9 GHz.

As redes 802.11 são organizadas de duas maneiras. No modo de infra-estrutura , uma estação atua como mestre para todas as outras estações que se associam a ela, a rede é conhecida como BSS e a estação mestre é denominada ponto de acesso. (AP). Em um BSS, toda a comunicação passa pelo AP; mesmo quando uma estação deseja se comunicar com outra estação sem fio, as mensagens devem passar pelo AP. Na segunda forma de rede, não há mestre e as estações se comunicam diretamente. Esta forma de rede é denominada IBSS e é comumente conhecida como uma rede ad-hoc .

As redes 802.11 foram implantadas pela primeira vez na banda de 2,4 GHz usando protocolos definidos pelo padrão 802.11 e 802.11b da IEEE™. Essas especificações incluem as frequências operacionais e as características da camada MAC, incluindo as taxas de enquadramento e transmissão, pois a comunicação pode ocorrer em várias taxas. Posteriormente, o padrão 802.11a definiu a operação na faixa de 5GHz, incluindo diferentes mecanismos de sinalização e taxas de transmissão mais altas. Mais tarde, o padrão 802.11g definiu o uso de mecanismos de sinalização e transmissão 802.11a na banda de 2,4 GHz de modo a ser compatível com redes 802.11b.

Separadas das técnicas de transmissão básicas, as redes 802.11 possuem uma variedade de mecanismos de segurança. As especificações originais do 802.11 definiam um protocolo de segurança simples chamado WEP. Este protocolo usa uma chave pré-compartilhada fixa e a criptografia criptográfica RC4 para codificar dados transmitidos em uma rede. Todas as estações devem concordar com a chave fixa para se comunicar. Esse esquema mostrou-se de fácil quebra e agora raramente é usado, exceto para desencorajar usuários transitórios a se juntarem a uma rede. A prática atual de segurança é dada pela especificação 802.11i do IEEE™ que define novas cifras criptográficas e um protocolo adicional para autenticar estações para um ponto de acesso e para trocar chaves para comunicação de dados. As chaves criptográficas são atualizadas periodicamente e existem mecanismos para detectar e combater tentativas de invasão. Outra especificação de protocolo de segurança comumente usada em redes sem fio é denominada WPA, que foi um precursor do 802.11i. O WPA especifica um subconjunto dos requisitos encontrados no 802.11i e foi projetado para implementação em hardware legado. Especificamente, o WPA requer apenas a codificação TKIP derivada da codificação original WEP. O 802.11i permite o uso do TKIP, mas também requer suporte para uma criptografia mais forte, o AES-CCM, para criptografar os dados. A codificação AES não era exigida no WPA porque foi considerada demasiadamente cara computacionalmente para ser executada em hardware legado.

Um outro padrão a se ter em conta é o 802.11e. Ele define protocolos para a implantação de aplicativos multimídia, como streaming de vídeo e voz sobre IP (VoIP), em uma rede 802.11. Como o 802.11i, o 802.11e também tem uma especificação de precursor denominada WME (posteriormente renomeada como WMM) que foi definida por um grupo industrial como um subconjunto do 802.11e que pode ser implantado agora para habilitar aplicativos multimídia enquanto aguarda a ratificação final do 802.11e. O mais importante a saber sobre o 802.11e e o WME/WMM é que ele permite o tráfego prioritário através de uma rede sem fio através de protocolos de Qualidade de Serviço (QoS) e protocolos de acesso de mídia aprimorados. A implementação adequada desses protocolos permite o aumento rápido de dados e o fluxo de tráfego priorizado.

O FreeBSD suporta redes que operam usando 802.11a, 802.11b e 802.11g. Os protocolos de segurança WPA e 802.11i também são suportados (em conjunto com qualquer um dos 11a, 11b e 11g) e o QoS e priorização de tráfego exigidos pelo protocolo WME/WMM são suportados por um conjunto limitado de dispositivos sem fio.

31.3.2. Inicio Rápido

Conectar um computador a uma rede sem fio existente é uma situação muito comum. Este procedimento mostra as etapas necessárias.

Obtenha o SSID (identificador de conjunto de serviços) e PSK (chave pré-compartilhada) para a rede sem fio do administrador da rede.
Identifique o adaptador sem fio. O kernel GENERIC do FreeBSD inclui drivers para muitos adaptadores sem fio comuns. Se o adaptador sem fio for um desses modelos, ele será mostrado na saída do ifconfig(8) :
```
% ifconfig | grep -B3 -i wireless
```
No FreeBSD 11 ou superior, use este comando:
```
% sysctl net.wlan.devices
```
Se um adaptador sem fio não estiver listado, um módulo adicional do kernel pode ser necessário, ou pode ser um modelo não suportado pelo FreeBSD.

Este exemplo mostra o adaptador wireless Atheros ath0 .
Adicione uma entrada para esta rede ao /etc/wpa_supplicant.conf . Se o arquivo não existir, crie-o. Substitua myssid e mypsk pelo SSID e PSK fornecidos pelo administrador da rede.
```
network={
	ssid="myssid"
	psk="mypsk"
}
```
Adicione entradas ao /etc/rc.conf para configurar a rede na inicialização:
```
wlans_ath0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
```
Reinicie o computador ou reinicie o serviço de rede para conectar-se à rede:
```
# service netif restart
```

31.3.3. Configuração básica

31.3.3.1. Configuração do Kernel

Para usar a rede sem fio, uma placa de rede sem fio é necessária e o kernel precisa ser configurado com o suporte de rede sem fio apropriado. O kernel é separado em vários módulos para que apenas o suporte necessário precise ser configurado.

Os dispositivos sem fio mais comumente usados são aqueles que usam peças fabricadas pela Atheros. Estes dispositivos são suportados pelo ath(4) e requerem que a seguinte linha seja adicionada ao /boot/loader.conf :

if_ath_load="YES"

O driver Atheros é dividido em três partes separadas: o driver ( ath(4) ), a camada de suporte de hardware que lida com funções específicas do chip ( ath_hal(4) ) e um algoritmo para selecionar a taxa de transmissão de quadros. Quando este suporte é carregado como módulo do kernel, quaisquer dependências são tratadas automaticamente. Para carregar o suporte para um tipo diferente de dispositivo sem fio, especifique o módulo para esse dispositivo. Este exemplo é para dispositivos baseados no driver Intersil Prism parts ( wi(4) ):

if_wi_load="YES"

Os exemplos nesta seção usam um dispositivo ath(4) e o nome do dispositivo nos exemplos deve ser alterado de acordo com a configuração. Uma lista de drivers sem fio disponíveis e adaptadores suportados pode ser encontrada nas Notas de Hardware do FreeBSD, disponíveis nas Informações de Release da página do site do FreeBSD. Se um driver nativo do FreeBSD para o dispositivo sem fio não existir, pode ser possível usar o driver Windows™ com a ajuda do wrapper de driver NDIS .

Além disso, os módulos que implementam o suporte criptográfico para os protocolos de segurança devem ser carregados. Estes destinam-se a ser dinamicamente carregados sob demanda pelo módulo wlan(4) , mas por enquanto eles devem ser configurados manualmente. Os seguintes módulos estão disponíveis: wlan_wep(4) , wlan_ccmp(4) , e wlan_tkip(4) . Os drivers wlan_ccmp(4) e wlan_tkip(4) são necessário apenas ao usar os protocolos de segurança WPA ou 802.11i. Se a rede não usar criptografia, o suporte a wlan_wep(4) não será necessário. Para carregar estes módulos no momento da inicialização, adicione as seguintes linhas ao /boot/loader.conf :

wlan_wep_load="YES"
wlan_ccmp_load="YES"
wlan_tkip_load="YES"

Uma vez que esta informação tenha sido adicionada ao /boot/loader.conf , reinicie a caixa FreeBSD. Como alternativa, carregue os módulos manualmente usando kldload(8) .

Para usuários que não querem usar módulos, é possível compilar esses drivers no kernel adicionando as seguintes linhas a um arquivo de configuração de kernel personalizado:

device wlan              # 802.11 support
device wlan_wep          # 802.11 WEP support
device wlan_ccmp         # 802.11 CCMP support
device wlan_tkip         # 802.11 TKIP support
device wlan_amrr         # AMRR transmit rate control algorithm
device ath               # Atheros pci/cardbus NIC's
device ath_hal           # pci/cardbus chip support
options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors
device ath_rate_sample   # SampleRate tx rate control for ath

Com esta informação no arquivo de configuração do kernel, recompile o kernel e reinicie a máquina do FreeBSD.

Informações sobre o dispositivo sem fio devem aparecer nas mensagens de inicialização, assim:

ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 11 at device 0.0 on cardbus1
ath0: [ITHREAD]
ath0: AR2413 mac 7.9 RF2413 phy 4.5

31.3.3.2. Definindo a Região Correta

Como a situação regulatória é diferente em várias partes do mundo, é necessário definir corretamente os domínios que se aplicam à sua localização para obter as informações corretas sobre quais canais podem ser usados.

As definições de região disponíveis podem ser encontradas em /etc/regdomain.xml . Para definir os dados em tempo de execução, use o ifconfig :

# ifconfig wlan0 regdomain ETSI country AT

Para persistir as configurações, adicione-o ao /etc/rc.conf :

# sysrc create_args_wlan0="country AT regdomain ETSI"

31.3.4. Modo de Infraestrutura

O modo de infra-estrutura (BSS) é o modo normalmente usado. Neste modo, vários pontos de acesso sem fio são conectados a uma rede com fio. Cada rede sem fio tem seu próprio nome, chamado de SSID. Os clientes sem fio se conectam aos pontos de acesso sem fio.

31.3.4.1. Clientes do FreeBSD

31.3.4.1.1. Como encontrar pontos de acesso

Para procurar redes disponíveis, use ifconfig(8) . Essa solicitação pode demorar alguns instantes para ser concluída, pois exige que o sistema alterne para cada frequência sem fio disponível e sonde os pontos de acesso disponíveis. Apenas o superusuário pode iniciar uma varredura:

# ifconfig wlan0 create wlandev ath0
# ifconfig wlan0 up scan
SSID/MESH ID    BSSID              CHAN RATE   S:N     INT CAPS
dlinkap         00:13:46:49:41:76   11   54M -90:96   100 EPS  WPA WME
freebsdap       00:11:95:c3:0d:ac    1   54M -83:96   100 EPS  WPA

A interface deve estar up antes de poder efetuar a busca. Pedidos de varredura subsequentes não exigem que a interface seja marcada como up novamente.

A saída de uma solicitação de varredura lista cada rede BSS/IBSS encontrada. Além de listar o nome da rede, o SSID , a saída também mostra o BSSID , que é o endereço MAC do ponto de acesso. O campo CAPS identifica o tipo de cada rede e os recursos das estações que operam lá:

Tabela 2. Códigos de capacidade da estação
Código de capacidade	Significado
`E`	Conjunto de serviços estendidos (ESS). Indica que a estação faz parte de uma rede de infraestrutura em vez de uma rede IBSS/ad-hoc.
`I`	Rede IBSS/ad-hoc. Indica que a estação faz parte de uma rede ad-hoc em vez de uma rede ESS.
`P`	Privacidade. A criptografia é necessária para todos os quadros de dados trocados dentro do BSS usando meios criptográficos como o WEP, o TKIP ou o AES-CCMP.
`S`	Preâmbulo Curto. Indica que a rede está usando preâmbulos curtos, definidos em 802.11b de Alta Taxa/DSSS PHYS, e utiliza um campo de sincronização de 56 bits em vez do campo de 128 bits usado no modo de preâmbulo longo.
`s`	Tempo de slot curto. Indica que a rede 802.11g está usando um tempo de slot curto porque não há estações legadas (802.11b) presentes.

Pode-se também exibir a lista atual de redes conhecidas com:

# ifconfig wlan0 list scan

Essas informações podem ser atualizadas automaticamente pelo adaptador ou manualmente com uma solicitação de scan . Dados antigos são automaticamente removidos do cache, então com o tempo essa lista pode diminuir a menos que mais varreduras sejam feitas.

31.3.4.1.2. Configurações básicas

Esta seção fornece um exemplo simples de como fazer com que o adaptador de rede sem fio funcione no FreeBSD sem criptografia. Uma vez familiarizado com esses conceitos, é altamente recomendável usar o WPA para configurar a rede sem fio.

Existem três etapas básicas para configurar uma rede sem fio: selecionar um ponto de acesso, autenticar a estação e configurar um endereço IP. As seções a seguir discutem cada etapa.

31.3.4.1.2.1. Selecionando um ponto de acesso

Na maioria das vezes, é suficiente deixar o sistema escolher um ponto de acesso usando a heurística integrada. Este é o comportamento padrão quando uma interface é marcada como up ou está listada em /etc/rc.conf :

wlans_ath0="wlan0"
ifconfig_wlan0="DHCP"

Se houver vários pontos de acesso, um específico pode ser selecionado pelo seu SSID:

wlans_ath0="wlan0"
ifconfig_wlan0="ssid your_ssid_here DHCP"

Em um ambiente em que há vários pontos de acesso com o mesmo SSID, o que geralmente é feito para simplificar o roaming, talvez seja necessário associá-lo a um dispositivo específico. Neste caso, o BSSID do ponto de acesso pode ser especificado, com ou sem o SSID:

wlans_ath0="wlan0"
ifconfig_wlan0="ssid your_ssid_here bssid xx:xx:xx:xx:xx:xx DHCP"

Existem outras maneiras de restringir a escolha de um ponto de acesso, como limitar o conjunto de freqüências que o sistema fará a varredura. Isso pode ser útil para uma placa sem fio de banda múltipla, pois a varredura de todos os canais possíveis pode consumir muito tempo. Para limitar a operação a uma banda específica, use o parâmetro mode :

wlans_ath0="wlan0"
ifconfig_wlan0="mode 11g ssid your_ssid_here DHCP"

Este exemplo forçará a placa a operar em 802.11g, que é definido apenas para freqüências de 2.4GHz, portanto, qualquer canal de 5GHz não será considerado. Isso também pode ser obtido com o parâmetro channel , que bloqueia a operação para uma frequência específica, e o parâmetro chanlist , para especificar uma lista de canais para varredura. Maiores informações sobre esses parâmetros podem ser encontradas em ifconfig(8) .

31.3.4.1.2.2. Autenticação

Quando um ponto de acesso é selecionado, a estação precisa se autenticar antes de poder transmitir dados. A autenticação pode acontecer de várias maneiras. O esquema mais comum, autenticação aberta, permite que qualquer estação entre na rede e se comunique. Essa é a autenticação a ser usada para fins de teste na primeira vez em que uma rede sem fio é configurada. Outros esquemas exigem que os handshakes criptográficos sejam concluídos antes que o tráfego de dados possa fluir, usando chaves ou segredos pré-compartilhados ou esquemas mais complexos que envolvam serviços de back-end, como o RADIUS. Autenticação aberta é a configuração padrão. A próxima configuração mais comum é o WPA-PSK, também conhecido como WPA Pessoal, que é descrito em WPA-PSK .

Se estiver usando uma estação base Extreme AirPort™ da Apple™ para um ponto de acesso, a autenticação de chave compartilhada juntamente com um WEP chave precisa ser configurada. Isto pode ser configurado em /etc/rc.conf ou usando wpa_supplicant(8) . Para uma única estação base AirPort™, o acesso pode ser configurado com:

wlans_ath0="wlan0"
ifconfig_wlan0="authmode shared wepmode on weptxkey 1 wepkey 01234567 DHCP"

Em geral, a autenticação de chave compartilhada deve ser evitada porque ela usa o material de chave WEP de uma maneira altamente restrita, facilitando ainda mais a quebra da chave. Se o WEP deve ser usado para compatibilidade com dispositivos legados, é melhor usar o WEP com a autenticação open . Mais informações sobre o WEP podem ser encontradas em WEP .

31.3.4.1.2.3. Obtendo um endereço IP com DHCP

Quando um ponto de acesso é selecionado e os parâmetros de autenticação são definidos, um endereço IP deve ser obtido para se comunicar. Na maioria das vezes, o endereço IP é obtido através do DHCP. Para isso, edite o /etc/rc.conf e adicione o DHCP à configuração do dispositivo:

wlans_ath0="wlan0"
ifconfig_wlan0="DHCP"

A interface sem fio está agora pronta para subir:

# service netif start

Quando a interface estiver rodando, use o ifconfig(8) para ver o status da interface ath0 :

# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 00:11:95:d5:43:62
        inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
        media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g
        status: associated
        ssid dlinkap channel 11 (2462 Mhz 11g) bssid 00:13:46:49:41:76
        country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7
        scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7
        roam:rate 5 protmode CTS wme burst

A linha status: associated significa que está conectada à rede sem fio. O bssid 00:13:46:49:41:76 é o endereço MAC do ponto de acesso e o authmode OPEN indica que a comunicação é não criptografada.

31.3.4.1.2.4. Endereço IP estático

Se um endereço IP não puder ser obtido de um servidor DHCP, defina um endereço de IP fixo. Substitua a palavra-chave DHCP mostrada acima pelas informações do endereço. Certifique-se de reter quaisquer outros parâmetros para selecionar o ponto de acesso:

wlans_ath0="wlan0"
ifconfig_wlan0="inet 192.168.1.100 netmask 255.255.255.0 ssid your_ssid_here"

31.3.4.1.3. WPA

O Wi-Fi Protected Access (WPA) é um protocolo de segurança usado em conjunto com redes 802.11 para resolver a falta de autenticação adequada e a fraqueza do WEP. O WPA utiliza o protocolo de autenticação 802.1X e usa uma das várias codificações disponíveis em vez do WEP para integridade de dados. A única codificação exigida pelo WPA é o protocolo de integridade de chave temporária (TKIP). O TKIP é uma codificação que estende a codificação básica RC4 usada pelo WEP, adicionando verificação de integridade, detecção de adulteração e medidas para responder a intrusões detectadas. O TKIP foi projetado para funcionar em hardware legado apenas com uma modificação de software. Ele representa um compromisso que melhora a segurança, mas ainda não é totalmente imune a ataques. O WPA também especifica a codificação AES-CCMP como uma alternativa para o TKIP, e é preferível quando possível. Para esta especificação, o termo WPA2 ou RSN é comumente usado.

O WPA define protocolos de autenticação e criptografia. A autenticação é mais comumente feita usando uma de duas técnicas: por 802.1X e um serviço de autenticação backend, como o RADIUS, ou por um handshake mínimo entre a estação e o ponto de acesso usando um segredo pré-compartilhado. O primeiro é comumente chamado de WPA Enterprise e o último é conhecido como WPA Pessoal. Como a maioria das pessoas não configurará um servidor backend RADIUS para sua rede sem fio, o WPA-PSK é de longe a configuração mais comumente encontrada para o WPA .

O controle da conexão sem fio e a negociação ou autenticação de chave com um servidor é feito usando o wpa_supplicant(8) . Este programa requer um arquivo de configuração, o /etc/wpa_supplicant.conf , para ser executado. Maiores informações sobre este arquivo podem ser encontradas em wpa_supplicant.conf(5) .

31.3.4.1.3.1. WPA-PSK

O WPA-PSK, também conhecido como WPA Pessoal, é baseado em uma chave pré-compartilhada (PSK) que é gerada a partir de uma determinada senha e usado como chave mestra na rede sem fio. Isso significa que todos os usuários sem fio compartilharão a mesma chave. O WPA-PSK destina-se a redes pequenas em que o uso de um servidor de autenticação não é possível ou desejado.

Sempre use senhas fortes que sejam suficientemente longas e feitas de um alfabeto rico para que elas não sejam facilmente adivinhadas ou atacadas.

O primeiro passo é a configuração do /etc/wpa_supplicant.conf com o SSID e a chave pré-compartilhada da rede:

network={
  ssid="freebsdap"
  psk="freebsdmall"
}

Então, em /etc/rc.conf , indique que a configuração do dispositivo sem fio será feita com o WPA e o endereço IP será obtido com o DHCP:

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

Então, suba a interface:

# service netif start
Starting wpa_supplicant.
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 192.168.0.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.254 -- renewal in 300 seconds.
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

Ou, tente configurar a interface manualmente usando as informações em /etc/wpa_supplicant.conf :

# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
Trying to associate with 00:11:95:c3:0d:ac (SSID='freebsdap' freq=2412 MHz)
Associated with 00:11:95:c3:0d:ac
WPA: Key negotiation completed with 00:11:95:c3:0d:ac [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:11:95:c3:0d:ac completed (auth) [id=0 id_str=]

A próxima operação é iniciar o dhclient(8) para obter o endereço IP do servidor DHCP:

# dhclient wlan0
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.254 -- renewal in 300 seconds.
# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

Se o /etc/rc.conf tiver uma entrada ifconfig_wlan0="DHCP" , dhclient(8) será iniciado automaticamente após o wpa_supplicant(8) associar-se ao ponto de acesso.

Se o DHCP não for possível ou desejado, defina um endereço IP estático após o wpa_supplicant(8) autenticar a estação:

# ifconfig wlan0 inet 192.168.0.100 netmask 255.255.255.0
# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

Quando o DHCP não é usado, o gateway padrão e o servidor de nomes também precisam ser definidos manualmente:

# route add default your_default_router
# echo "nameserver your_DNS_server" >> /etc/resolv.conf

31.3.4.1.3.2. WPA com EAP-TLS

A segunda maneira de usar o WPA é com um servidor de autenticação de backend 802.1X. Neste caso, o WPA é chamado de WPA Enterprise para diferenciá-lo do WPA Pessoal menos seguro. A autenticação no WPA Enterprise é baseada no protocolo de autenticação extensível (EAP).

O EAP não vem com um método de criptografia. Em vez disso, o EAP é incorporado dentro de um túnel criptografado. Existem muitos métodos de autenticação EAP, mas o EAP-TLS, o EAP-TTLS e o EAP-PEAP são os mais comum.

O EAP com Segurança da Camada de Transporte (EAP-TLS) é um protocolo de autenticação sem fio bem suportado, já que foi o primeiro método EAP a ser certificado pela WiFi Alliance . O EAP-TLS requer três certificados para executar: o certificado da Autoridade de Certificação (CA) instalado em todas as máquinas, o certificado do servidor para o servidor de autenticação e um certificado de cliente para cada cliente sem fio. Nesse método EAP, o servidor de autenticação e o cliente sem fio autenticam um ao outro apresentando seus respectivos certificados e, em seguida, verificam se esses certificados foram assinados pela CA da organização.

Como anteriormente, a configuração é feita através do /etc/wpa_supplicant.conf :

network={
  ssid="freebsdap" (1)
  proto=RSN  (2)
  key_mgmt=WPA-EAP (3)
  eap=TLS (4)
  identity="loader" (5)
  ca_cert="/etc/certs/cacert.pem" (6)
  client_cert="/etc/certs/clientcert.pem" (7)
  private_key="/etc/certs/clientkey.pem" (8)
  private_key_passwd="freebsdmallclient" (9)
}

1	Este campo indica o nome da rede (SSID).
2	Este exemplo usa o protocolo 802.11i RSN IEEE™, também conhecido como WPA2.
3	A linha `key_mgmt` refere-se ao protocolo de gerenciamento de chaves a ser usado. Neste exemplo, é o WPA usando a autenticação EAP.
4	Este campo indica o método EAP para a conexão.
5	O campo `identity` contém a sequência de identidade para EAP.
6	O campo `ca_cert` indica o nome do caminho do arquivo de certificado CA. Este arquivo é necessário para verificar o certificado do servidor.
7	A linha `client_cert` fornece o nome do caminho para o arquivo de certificado do cliente. Este certificado é exclusivo para cada cliente sem fio da rede.
8	O campo `private_key` é o nome do caminho para o arquivo de chave privada do certificado do cliente.
9	O campo `private_key_passwd` contém a frase secreta para a chave privada.

Em seguida, adicione as seguintes linhas ao /etc/rc.conf :

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

O próximo passo é subir a interface:

# service netif start
Starting wpa_supplicant.
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15
DHCPACK from 192.168.0.20
bound to 192.168.0.254 -- renewal in 300 seconds.
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

Também é possível subir a interface manualmente usando wpa_supplicant(8) e ifconfig(8) .

31.3.4.1.3.3. WPA com EAP-TTLS

Com o EAP-TLS, o servidor de autenticação e o cliente precisam de um certificado. Com o EAP-TTLS, um certificado de cliente é opcional. Esse método é semelhante a um servidor da Web que cria um túnel seguro SSL, mesmo se os visitantes não tiverem certificados do lado do cliente. O EAP-TTLS usa um túnel TLS criptografado para o transporte seguro dos dados de autenticação.

A configuração necessária pode ser adicionada ao /etc/wpa_supplicant.conf :

network={
  ssid="freebsdap"
  proto=RSN
  key_mgmt=WPA-EAP
  eap=TTLS (1)
  identity="test" (2)
  password="test" (3)
  ca_cert="/etc/certs/cacert.pem" (4)
  phase2="auth=MD5" (5)
}

1	Este campo especifica o método EAP para a conexão.
2	O campo `identity` contém a sequência de identidade para a autenticação EAP dentro do túnel TLS criptografado.
3	O campo `password` contém a senha para a autenticação EAP.
4	O campo `ca_cert` indica o nome do caminho do arquivo de certificado CA. Este arquivo é necessário para verificar o certificado do servidor.
5	Este campo especifica o método de autenticação usado no túnel TLS criptografado. Neste exemplo, o EAP com desafio MD5 é usado. A fase de "inner authentication" é freqüentemente chamada de "phase2".

Em seguida, adicione as seguintes linhas ao /etc/rc.conf :

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

O próximo passo é subir a interface:

# service netif start
Starting wpa_supplicant.
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 21
DHCPACK from 192.168.0.20
bound to 192.168.0.254 -- renewal in 300 seconds.
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

31.3.4.1.3.4. WPA com EAP-PEAP

O PEAPv0/EAP-MSCHAPv2 é o método PEAP mais comum. Neste capítulo, o termo PEAP é usado para se referir a esse método.

O EAP protegido (PEAP) foi criado como uma alternativa ao EAP-TTLS e é o padrão mais usado do EAP após o EAP-TLS. Em uma rede com sistemas operacionais mistos, o PEAP deve ser o padrão mais suportado após o EAP-TLS.

O PEAP é semelhante ao EAP-TTLS, pois usa um certificado do lado do servidor para autenticar clientes criando um túnel TLS criptografado entre o cliente e o servidor de autenticação, que protege a troca subsequente das informações de autenticação. A autenticação PEAP difere do EAP-TTLS, pois transmite o nome de usuário em texto aberto e somente a senha é enviada no túnel TLS criptografado. O EAP-TTLS usará o túnel TLS para o nome de usuário e para a senha.

Adicione as seguintes linhas ao /etc/wpa_supplicant.conf para ajustar as configurações relacionadas ao EAP-PEAP:

network={
  ssid="freebsdap"
  proto=RSN
  key_mgmt=WPA-EAP
  eap=PEAP (1)
  identity="test" (2)
  password="test" (3)
  ca_cert="/etc/certs/cacert.pem" (4)
  phase1="peaplabel=0" (5)
  phase2="auth=MSCHAPV2" (6)
}

1	Este campo especifica o método EAP para a conexão.
2	O campo `identity` contém a sequência de identidade para a autenticação EAP dentro do túnel TLS criptografado.
3	O campo `password` contém a senha para a autenticação EAP.
4	O campo `ca_cert` indica o nome do caminho do arquivo de certificado CA. Este arquivo é necessário para verificar o certificado do servidor.
5	Este campo contém os parâmetros para a primeira fase de autenticação, o túnel TLS. De acordo com o servidor de autenticação usado, especifique um label específico para autenticação. Na maioria das vezes, o label será "client EAP encryption" que é definido usando `peaplabel=0` . Maiores informações podem ser encontradas em wpa_supplicant.conf(5) .
6	Este campo especifica o protocolo de autenticação usado no túnel TLS criptografado. No caso do PEAP, é `auth=MSCHAPV2` .

Adicione o seguinte ao /etc/rc.conf :

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

Então, suba a interface:

# service netif start
Starting wpa_supplicant.
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15
DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 21
DHCPACK from 192.168.0.20
bound to 192.168.0.254 -- renewal in 300 seconds.
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      ether 00:11:95:d5:43:62
      inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
      media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g
      status: associated
      ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
      country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
      AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
      bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
      wme burst roaming MANUAL

31.3.4.1.4. WEP

A privacidade equivalente com fio (WEP) faz parte do padrão 802.11 original. Não há mecanismo de autenticação, apenas uma forma fraca de controle de acesso que é facilmente quebrada.

O WEP pode ser configurado usando o ifconfig(8) :

# ifconfig wlan0 create wlandev ath0
# ifconfig wlan0 inet 192.168.1.100 netmask 255.255.255.0 \
	    ssid my_net wepmode on weptxkey 3 wepkey 3:0x3456789012

O weptxkey especifica qual chave WEP será usada na transmissão. Este exemplo usa a terceira chave. Isso deve corresponder à configuração no ponto de acesso. Quando não tiver certeza de qual chave é usada pelo ponto de acesso, tente 1 (a primeira chave) para esse valor.

O wepkey seleciona uma das chaves WEP. Deve estar no formato index:key . A chave 1 é usada por padrão; o índice só precisa ser definido ao usar uma chave diferente da primeira.

Substitua o 0x3456789012 com a chave configurada para uso no ponto de acesso.

Consulte o ifconfig(8) para obter maiores informações.

O recurso wpa_supplicant(8) pode ser usado para configurar uma interface sem fio com o WEP. O exemplo acima pode ser configurado adicionando as seguintes linhas ao /etc/wpa_supplicant.conf :

network={
  ssid="my_net"
  key_mgmt=NONE
  wep_key3=3456789012
  wep_tx_keyidx=3
}

Então:

# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
Trying to associate with 00:13:46:49:41:76 (SSID='dlinkap' freq=2437 MHz)
Associated with 00:13:46:49:41:76

31.3.5. Modo Ad-hoc

O modo IBSS, também chamado de modo ad-hoc, é projetado para conexões ponto a ponto. Por exemplo, para estabelecer uma rede ad-hoc entre as máquinas A e B , escolha dois endereços IP e um SSID.

Em A :

# ifconfig wlan0 create wlandev ath0 wlanmode adhoc
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap
# ifconfig wlan0
  wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  ether 00:11:95:c3:0d:ac
	  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
	  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc>
	  status: running
	  ssid freebsdap channel 2 (2417 Mhz 11g) bssid 02:11:95:c3:0d:ac
	  country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60
	  protmode CTS wme burst

O parâmetro adhoc indica que a interface está sendo executada no modo IBSS.

B deve ser capaz de detectar A :

# ifconfig wlan0 create wlandev ath0 wlanmode adhoc
# ifconfig wlan0 up scan
  SSID/MESH ID    BSSID              CHAN RATE   S:N     INT CAPS
  freebsdap       02:11:95:c3:0d:ac    2   54M -64:-96  100 IS   WME

O I na saída confirma que A está no modo ad-hoc. Agora, configure B com um endereço IP diferente:

# ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap
# ifconfig wlan0
  wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  ether 00:11:95:d5:43:62
	  inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
	  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc>
	  status: running
	  ssid freebsdap channel 2 (2417 Mhz 11g) bssid 02:11:95:c3:0d:ac
	  country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60
	  protmode CTS wme burst

Ambos A e B agora estão prontos para trocar informações.

31.3.6. Pontos de Acesso com um host FreeBSD

O FreeBSD pode atuar como um Access Point (AP), o que elimina a necessidade de comprar um hardware AP ou executar uma rede ad-hoc. Isso pode ser particularmente útil quando uma máquina FreeBSD está atuando como um gateway para outra rede, como a Internet.

31.3.6.1. Configurações básicas

Antes de configurar uma máquina FreeBSD como um AP, o kernel deve ser configurado com o suporte de rede apropriado para a placa wireless assim como os protocolos de segurança que estão sendo usados. Para maiores detalhes, veja Configuração básica .

O wrapper do driver NDIS para os drivers Windows™ não suporta atualmente a operação AP. Somente os drivers nativos de rede sem fio do FreeBSD suportam o modo AP.

Quando o suporte à rede sem fio estiver carregado, verifique se o dispositivo sem fio oferece suporte ao modo de ponto de acesso baseado em host, também conhecido como modo hostap:

# ifconfig wlan0 create wlandev ath0
# ifconfig wlan0 list caps
drivercaps=6f85edc1<STA,FF,TURBOP,IBSS,HOSTAP,AHDEMO,TXPMGT,SHSLOT,SHPREAMBLE,MONITOR,MBSS,WPA1,WPA2,BURST,WME,WDS,BGSCAN,TXFRAG>
cryptocaps=1f<WEP,TKIP,AES,AES_CCM,TKIPMIC>

Esta saída exibe os recursos da placa. A palavra HOSTAP confirma que esta placa sem fio pode atuar como um AP. Diversas cifras suportadas também são listadas: WEP, TKIP e AES. Esta informação indica quais protocolos de segurança podem ser usados no AP.

O dispositivo sem fio só pode ser colocado no modo hostap durante a criação do pseudo-dispositivo de rede, portanto, um dispositivo criado anteriormente deve ser destruído primeiro:

# ifconfig wlan0 destroy

e então regenerado com a opção correta antes de configurar os outros parâmetros:

# ifconfig wlan0 create wlandev ath0 wlanmode hostap
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1

Use o ifconfig(8) novamente para ver o status da interface wlan0 :

# ifconfig wlan0
  wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  ether 00:11:95:c3:0d:ac
	  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
	  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
	  status: running
	  ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
	  country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60
	  protmode CTS wme burst dtimperiod 1 -dfs

O parâmetro hostap indica que a interface está sendo executada no modo de ponto de acesso baseado em host.

A configuração da interface pode ser feita automaticamente no momento da inicialização, adicionando as seguintes linhas ao /etc/rc.conf :

wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap"
ifconfig_wlan0="inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1"

31.3.6.2. Ponto de acesso baseado em host sem autenticação ou criptografia

Embora não seja recomendado executar um AP sem nenhuma autenticação ou criptografia, esta é uma maneira simples de verificar se o AP está funcionando. Essa configuração também é importante para depurar problemas do cliente.

Quando o AP estiver configurado, inicie uma verificação de outra máquina sem fio para encontrar o AP:

# ifconfig wlan0 create wlandev ath0
# ifconfig wlan0 up scan
SSID/MESH ID    BSSID              CHAN RATE   S:N     INT CAPS
freebsdap       00:11:95:c3:0d:ac    1   54M -66:-96  100 ES   WME

A máquina cliente encontrou o AP e pode ser associado a ele:

# ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap
# ifconfig wlan0
  wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  ether 00:11:95:d5:43:62
	  inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
	  media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g
	  status: associated
	  ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
	  country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7
	  scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7
	  roam:rate 5 protmode CTS wme burst

31.3.6.3. Ponto de acesso baseado em host com WPA2

Esta seção se concentra na configuração de um ponto de acesso do FreeBSD usando o protocolo de segurança WPA2. Maiores detalhes sobre WPA e a configuração de clientes sem fio baseados em WPA podem ser encontrados em WPA .

O daemon hostapd(8) é usado para lidar com a autenticação de clientes e o gerenciamento de chaves no AP com WPA2 habilitado.

As seguintes operações de configuração são executadas na máquina FreeBSD atuando como o AP. Uma vez que o AP esteja funcionando corretamente, o hostapd(8) pode ser iniciado automaticamente na inicialização com essa linha em /etc/rc.conf :

hostapd_enable="YES"

Antes de tentar configurar o hostapd(8) , primeiro defina as configurações básicas introduzidas em Configurações básicas .

31.3.6.3.1. WPA2-PSK

O WPA2-PSK destina-se a redes pequenas em que o uso de um servidor de autenticação backend não é possível ou desejado.

A configuração é feita em /etc/hostapd.conf :

interface=wlan0                  (1)
debug=1                          (2)
ctrl_interface=/var/run/hostapd  (3)
ctrl_interface_group=wheel       (4)
ssid=freebsdap                   (5)
wpa=2                            (6)
wpa_passphrase=freebsdmall       (7)
wpa_key_mgmt=WPA-PSK             (8)
wpa_pairwise=CCMP                (9)

1	Interface sem fio usada para o ponto de acesso.
2	Nível de detalhamento usado durante a execução de hostapd(8) . Um valor de `1` representa o nível mínimo.
3	Nome do caminho de diretório usado pelo hostapd(8) para armazenar arquivos de soquete de domínio para comunicação com programas externos, como hostapd_cli(8) . O valor padrão é usado neste exemplo.
4	O grupo permitiu acessar os arquivos da interface de controle.
5	O nome da rede sem fio, ou SSID, que aparecerá nas varreduras sem fio.
6	Ative o WPA e especifique qual protocolo de autenticação WPA será necessário. Um valor de `2` configura o AP para WPA2 e é recomendado. Defina como `1` apenas se o WPA obsoleto for necessário.
7	Senha ASCII para autenticação WPA.
8	O protocolo de gerenciamento de chaves a ser usado. Este exemplo define o WPA-PSK. Algoritmos de criptografia aceitos pelo ponto de acesso. Neste exemplo, apenas a codificação CCMP (AES) é aceita. O CCMP é uma alternativa ao TKIP e é fortemente preferido quando possível. O TKIP só deve ser permitido quando houver estações incapazes de usar o CCMP.

O próximo passo é iniciar hostapd(8) :

# service hostapd forcestart

# ifconfig wlan0
wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 04:f0:21:16:8e:10
	inet6 fe80::6f0:21ff:fe16:8e10%wlan0 prefixlen 64 scopeid 0x9
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11na <hostap>
	status: running
	ssid No5ignal channel 36 (5180 MHz 11a ht/40+) bssid 04:f0:21:16:8e:10
	country US ecm authmode WPA2/802.11i privacy MIXED deftxkey 2
	AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 17 mcastrate 6 mgmtrate 6
	scanvalid 60 ampdulimit 64k ampdudensity 8 shortgi wme burst
	dtimperiod 1 -dfs
	groups: wlan

Quando o AP está em execução, os clientes podem associar-se a ele. Veja WPA para maiores detalhes. É possível ver as estações associadas ao AP usando o ifconfig wlan0 list sta .

31.3.6.4. Ponto de acesso baseado em host WEP

Não é recomendado o uso do WEP para configurar um AP, já que não há mecanismo de autenticação e a criptografia é facilmente quebrada. Algumas placas sem fio legadas suportam apenas o WEP e essas placas suportarão apenas um AP sem autenticação ou criptografia.

O dispositivo sem fio agora pode ser colocado no modo hostap e configurado com o endereço SSID e IP corretos:

# ifconfig wlan0 create wlandev ath0 wlanmode hostap
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 \
	ssid freebsdap wepmode on weptxkey 3 wepkey 3:0x3456789012 mode 11g

O weptxkey indica qual a chave WEP será usada na transmissão. Este exemplo usa a terceira chave, pois a numeração de chaves começa com 1 . Esse parâmetro deve ser especificado para criptografar os dados.
O wepkey define a chave WEP selecionada. Ela deve estar no formato index:key . Se o índice não for fornecido, a chave 1 será configurada. O índice precisa ser definido ao usar chaves diferentes da primeira chave.

Use o ifconfig(8) para ver o status da interface wlan0 :

# ifconfig wlan0
  wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  ether 00:11:95:c3:0d:ac
	  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
	  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
	  status: running
	  ssid freebsdap channel 4 (2427 Mhz 11g) bssid 00:11:95:c3:0d:ac
	  country US ecm authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit
	  txpower 21.5 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs

De uma outra máquina sem fio, agora é possível iniciar uma varredura para encontrar o AP:

# ifconfig wlan0 create wlandev ath0
# ifconfig wlan0 up scan
SSID            BSSID              CHAN RATE  S:N   INT CAPS
freebsdap       00:11:95:c3:0d:ac    1   54M 22:1   100 EPS

Neste exemplo, a máquina cliente encontrou o AP e pode associá-lo usando os parâmetros corretos. Veja WEP para maiores detalhes.

31.3.7. Usando conexões com fio e sem fio

Uma conexão com fio oferece melhor desempenho e confiabilidade, enquanto uma conexão sem fio fornece flexibilidade e mobilidade. Os usuários de laptop normalmente querem se movimentar perfeitamente entre os dois tipos de conexão.

No FreeBSD, é possível combinar duas ou mais interfaces de rede em um "failover". Esse tipo de configuração usa a conexão mais prioritária e disponível de um grupo de interfaces de rede, e o sistema operacional alterna automaticamente quando o estado do link é alterado.

A agregação de links e o failover são cobertos em Agregação de links e failover e um exemplo para usar conexões com e sem fio é fornecido em Modo de failover entre interfaces Ethernet e sem fio .

31.3.8. Solução de problemas

Esta seção descreve várias etapas para ajudar a solucionar problemas comuns de rede sem fio.

Se o ponto de acesso não estiver listado durante a verificação, verifique se a configuração não limitou o dispositivo sem fio a um conjunto limitado de canais.
Se o dispositivo não puder se associar a um ponto de acesso, verifique se a configuração corresponde às configurações no ponto de acesso. Isso inclui o esquema de autenticação e qualquer protocolo de segurança. Simplifique a configuração tanto quanto possível. Se estiver usando um protocolo de segurança, como o WPA ou o WEP, configure o ponto de acesso para autenticação aberta e nenhuma segurança para ver se o tráfego irá passar.

O suporte a depuração é fornecido pelo wpa_supplicant(8) . Tente executar este utilitário manualmente com a opção -dd e examine os logs do sistema.
Uma vez que o sistema possa se associar com o ponto de acesso, diagnostique a configuração da rede usando ferramentas como o ping(8) .
Existem muitas ferramentas de depuração de nível inferior. As mensagens de depuração podem ser ativadas na camada de suporte do protocolo 802.11 usando o wlandebug(8) . Por exemplo, para habilitar mensagens do console relacionadas à varredura de pontos de acesso e aos handshakes do protocolo 802.11 necessários para organizar a comunicação:
```
# wlandebug -i wlan0 +scan+auth+debug+assoc
  net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
```
Muitas estatísticas úteis são mantidas pela camada 802.11 e o wlanstats , encontrado em /usr/src/tools/tools/net80211 , vai despejar esta informação. Essas estatísticas devem exibir todos os erros identificados pela camada 802.11. No entanto, alguns erros são identificados nos drivers de dispositivo que estão abaixo da camada 802.11, portanto eles podem não aparecer. Para diagnosticar problemas específicos do dispositivo, consulte a documentação do driver.

Se as informações acima não ajudarem a esclarecer o problema, envie um relatório de problemas e inclua a saída das ferramentas acima.

31.4. USB Tethering

Muitos telefones celulares oferecem a opção de compartilhar sua conexão de dados sobre o USB (muitas vezes chamado de "tethering"). Este recurso usa o RNDIS, CDC ou um protocolo personalizado Apple™iPhone™/iPad™.

Os dispositivos Android™ geralmente utilizam o driver urndis(4) .
Os dispositivos Apple™ utilizam o driver ipheth(4) .
Dispositivos mais antigos geralmente utilizam o driver cdce(4) .

Antes de conectar um dispositivo, carregue o driver apropriado no kernel:

# kldload if_urndis
# kldload if_cdce
# kldload if_ipheth

Uma vez que o dispositivo esteja conectado, ue 0 estará disponível para uso como um dispositivo de rede normal. Certifique-se de que a opção "USB Tethering" esteja ativada no dispositivo.

Para tornar essa alteração permanente e carregar o driver como um módulo no momento da inicialização, coloque a linha apropriada abaixo em /boot/loader.conf :

 if_urndis_load="YES"
if_cdce_load="YES"
if_ipheth_load="YES"

31.5. Bluetooth

O bluetooth é uma tecnologia sem fio para a criação de redes pessoais que operam na faixa não licenciada de 2,4 GHz, com um alcance de 10 metros. As redes geralmente são formadas em modo ad-hoc a partir de dispositivos portáteis, como telefones celulares, computadores de mão e laptops. Ao contrário da tecnologia sem fio Wi-Fi, o Bluetooth oferece perfis de serviços de nível superior, como servidores de arquivos semelhantes ao FTP, envio de arquivos, transporte de voz, emulação de linha serial e muito mais.

Esta seção descreve o uso de um dongle Bluetooth USB em um sistema FreeBSD. Em seguida, descreve os vários protocolos e utilitários Bluetooth.

31.5.1. Carregando o Suporte Bluetooth

A pilha Bluetooth no FreeBSD é implementada usando o framework netgraph(4) . Uma ampla variedade de dongles Bluetooth USB é suportada pelo ng_ubt(4) . Os dispositivos Bluetooth baseados no Broadcom BCM2033 são suportados pelos drivers ubtbcmfw(4) e ng_ubt(4) . A placa 3Com Bluetooth PC Card 3CRWB60-A é suportada pelo driver ng_bt3c(4) . Dispositivos Bluetooth baseados em Portas Seriais e UART são suportados por sio(4) , ng_h4(4) , e hcseriald(8) .

Antes de conectar um dispositivo, determine qual dos drivers acima ele usa e, em seguida, carregue o driver. Por exemplo, se o dispositivo usar o driver ng_ubt(4) :

# kldload ng_ubt

Se o dispositivo Bluetooth for conectado ao sistema durante a inicialização do sistema, o sistema pode ser configurado para carregar o módulo no momento da inicialização, adicionando o driver ao /boot/loader.conf :

ng_ubt_load="YES"

Quando o driver estiver carregado, conecte o dongle USB. Se a carga do driver tiver sido bem-sucedida, uma saída semelhante à seguinte deve aparecer no console e em /var/log/messages :

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
      wMaxPacketSize=49, nframes=6, buffer size=294

Para iniciar e parar a stack Bluetooth, use seu script de inicialização. É uma boa ideia parar a stack antes de desconectar o dispositivo. Iniciar a stack bluetooth pode exigir que o hcsecd(8) seja iniciado. Ao iniciar a stack, a saída deve ser semelhante à seguinte:

# service bluetooth start ubt0
BD_ADDR: 00:02:72:00:d4:1a
Features: 0xff 0xff 0xf 00 00 00 00 00
<3-Slot> <5-Slot> <Encryption> <Slot offset>
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
<Park mode> <RSSI> <Channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<Paging scheme> <Power control> <Transparent SCO data>
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8

31.5.2. Encontrando outros dispositivos Bluetooth

A Interface do Controlador do Host (HCI) fornece um método uniforme para acessar os recursos de banda básica do Bluetooth. No FreeBSD, um nó netgraph HCI é criado para cada dispositivo Bluetooth. Para mais detalhes, consulte ng_hci(4) .

Uma das tarefas mais comuns é a descoberta de dispositivos Bluetooth dentro da proximidade RF. Esta operação é chamada inquiry . Investigação e outras operações relacionadas a HCI são feitas usando hccontrol(8) . O exemplo abaixo mostra como descobrir quais dispositivos Bluetooth estão ao alcance. A lista de dispositivos deve ser exibida em alguns segundos. Note que um dispositivo remoto só irá responder a pergunta se estiver configurado para o modo detectável .

% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
       BD_ADDR: 00:80:37:29:19:a4
       Page Scan Rep. Mode: 0x1
       Page Scan Period Mode: 00
       Page Scan Mode: 00
       Class: 52:02:04
       Clock offset: 0x78ef
Inquiry complete. Status: No error [00]

O BD_ADDR é o endereço exclusivo de um dispositivo Bluetooth, semelhante ao endereço MAC de uma placa de rede. Este endereço é necessário para uma comunicação posterior com um dispositivo e é possível atribuir um nome legível a um BD_ADDR . Informações sobre os hosts Bluetooth conhecidos estão contidas em /etc/bluetooth/hosts . O exemplo a seguir mostra como obter o nome legível que foi atribuído ao dispositivo remoto:

% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
BD_ADDR: 00:80:37:29:19:a4
Name: Pav's T39

Se uma consulta for realizada em um dispositivo Bluetooth remoto, ele encontrará o computador como "your.host.name (ubt0)". O nome atribuído ao dispositivo local pode ser alterado a qualquer momento.

Dispositivos remotos podem receber aliases em /etc/bluetooth/hosts . Maiores informações sobre o arquivo /etc/bluetooth/hosts podem ser encontradas em bluetooth.hosts(5) .

O sistema Bluetooth fornece uma conexão ponta-a-ponto entre duas unidades Bluetooth ou uma conexão ponto-a-multiponto que é compartilhada entre vários dispositivos Bluetooth. O exemplo a seguir mostra como criar uma conexão a um dispositivo remoto:

% hccontrol -n ubt0hci create_connection BT_ADDR

O create_connection aceita BT_ADDR , bem como aliases de host em /etc/bluetooth/hosts .

O exemplo a seguir mostra como obter a lista de conexões de banda base ativas para o dispositivo local:

% hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
00:80:37:29:19:a4     41  ACL    0 MAST    NONE       0     0 OPEN

Um identificador de conexão é útil quando a finalização da conexão de banda base é necessária, embora normalmente não seja necessário fazer isso manualmente. A stack terminará automaticamente as conexões de banda básica inativas.

# hccontrol -n ubt0hci disconnect 41
Connection handle: 41
Reason: Connection terminated by local host [0x16]

Digite hccontrol help para obter uma lista completa dos comandos HCI disponíveis. A maioria dos comandos HCI não requer privilégios de superusuário.

31.5.3. Emparelhamento de dispositivos

Por padrão, a comunicação Bluetooth não é autenticada e qualquer dispositivo pode conversar com qualquer outro dispositivo. Um dispositivo Bluetooth, como um telefone celular, pode optar por exigir autenticação para fornecer um serviço específico. A autenticação Bluetooth é normalmente feita com um PIN code , uma string ASCII com até 16 caracteres de comprimento. O usuário é obrigado a digitar o mesmo código de PIN em ambos os dispositivos. Depois que o usuário inserir o código de PIN, ambos os dispositivos gerarão uma chave de link . Depois disso, a chave de link pode ser armazenada nos dispositivos ou em um armazenamento persistente. Na próxima vez, os dois dispositivos usarão a chave de link gerada anteriormente. Este procedimento é chamado de emparelhamento . Observe que, se a chave de link for perdida por um dos dispositivos, o emparelhamento deverá ser repetido.

O daemon hcsecd(8) é responsável por tratar os pedidos de autenticação Bluetooth. O arquivo de configuração padrão é o /etc/bluetooth/hcsecd.conf . Uma seção de exemplo para um telefone celular com o código PIN definido como 1234 é mostrada abaixo:

device {
        bdaddr  00:80:37:29:19:a4;
        name    "Pav's T39";
        key     nokey;
        pin     "1234";
      }

A única limitação nos códigos de PIN é o comprimento. Alguns dispositivos, como fones de ouvido Bluetooth, podem ter um código PIN integrado fixo. A opção -d força o hcsecd(8) a ficar em primeiro plano, então é fácil ver o que está acontecendo. Configure o dispositivo remoto para receber o emparelhamento e inicie a conexão Bluetooth ao dispositivo remoto. O dispositivo remoto deve indicar que o pareamento foi aceito e solicitar o código de PIN. Digite o mesmo código de PIN listado em hcsecd.conf . Agora o computador e o dispositivo remoto estão emparelhados. Alternativamente, o emparelhamento pode ser iniciado no dispositivo remoto.

A seguinte linha pode ser adicionada ao /etc/rc.conf para configurar o hcsecd(8) para iniciar automaticamente quando o sistema inicializar:

hcsecd_enable="YES"

A seguir, um exemplo da saída do daemon hcsecd(8) :

hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4

31.5.4. Acesso à rede com perfis PPP

Um perfil de rede dial-up (DUN) pode ser usado para configurar um telefone celular como um modem sem fio para a conexão a um servidor de acesso à Internet dial-up. Também pode ser usado para configurar um computador para receber chamadas de dados de um telefone celular.

O acesso à rede com um perfil PPP pode ser usado para fornecer acesso LAN a um único dispositivo Bluetooth ou a vários dispositivos Bluetooth. Ele também pode fornecer uma conexão PC para PC usando uma rede PPP sobre uma emulação de cabo serial.

No FreeBSD, esses perfis são implementados com o ppp(8) e o wrapper rfcomm_pppd(8) que converte uma conexão Bluetooth em algo que o PPP pode usar. Antes que um perfil possa ser usado, um novo label PPP deve ser criado em /etc/ppp/ppp.conf . Consulte rfcomm_pppd(8) para exemplos.

Neste exemplo, o rfcomm_pppd(8) é usado para abrir uma conexão com um dispositivo remoto com um BD_ADDR de 00:80:37:29:19:a4 em um canal DUNRFCOMM:

# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup

O número real do canal será obtido a partir do dispositivo remoto usando o protocolo SDP. É possível especificar manualmente o canal RFCOMM e, nesse caso, o rfcomm_pppd(8) não executará a consulta SDP. Use o sdpcontrol(8) para descobrir o canal RFCOMM no dispositivo remoto.

Para fornecer acesso à rede com o serviço PPPLAN, o sdpd(8) precisa estar sendo executado e uma nova entrada para clientes LAN deve ser criada em /etc/ppp/ppp.conf . Consulte rfcomm_pppd(8) para exemplos. Por fim, inicie o servidor RFCOMMPPP em um número de canal RFCOMM válido. O servidor RFCOMMPPP registrará automaticamente o serviço Bluetooth LAN com o daemon local SDP. O exemplo abaixo mostra como iniciar o servidor RFCOMMPPP.

# rfcomm_pppd -s -C 7 -l rfcomm-server

31.5.5. Protocolos Bluetooth

Esta seção fornece uma visão geral dos vários protocolos Bluetooth, suas funções e utilitários associados.

31.5.5.1. Controle de Link Lógico e Protocolo de Adaptação (L2CAP)

O Protocolo de Adaptação e Controle de Link Lógico (L2CAP) fornece serviços de dados orientados a conexão e sem conexão para protocolos de camada superior. O L2CAP permite que protocolos e aplicativos de alto nível transmitam e recebam pacotes de dados L2CAP de até 64 kilobytes de comprimento.

O L2CAP é baseado no conceito de canais . Um canal é uma conexão lógica em cima de uma conexão de banda base, na qual cada canal é vinculado a um único protocolo de maneira many-to-one. Vários canais podem ser vinculados ao mesmo protocolo, mas um canal não pode ser vinculado a vários protocolos. Cada pacote L2CAP recebido em um canal é direcionado para o protocolo apropriado de nível superior. Vários canais podem compartilhar a mesma conexão de banda base.

No FreeBSD, um nó netgraph L2CAP é criado para cada dispositivo Bluetooth. Esse nó é normalmente conectado ao nó Bluetooth HCI downstream e aos nós de soquete Bluetooth upstream. O nome padrão para o nó L2CAP é "devicel2cap". Para mais detalhes, consulte ng_l2cap(4) .

Um comando útil é o l2ping(8) , que pode ser usado para executar ping em outros dispositivos. Algumas implementações Bluetooth podem não retornar todos os dados enviados para elas, portanto, a saída 0 bytes no exemplo a seguir é normal.

# l2ping -a 00:80:37:29:19:a4
0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0

O utilitário l2control(8) é usado para executar várias operações em nós L2CAP. Este exemplo mostra como obter a lista de conexões lógicas (canais) e a lista de conexões de banda base para o dispositivo local:

% l2control -a 00:02:72:00:d4:1a read_channel_list
L2CAP channels:
Remote BD_ADDR     SCID/ DCID   PSM  IMTU/ OMTU State
00:07:e0:00:0b:ca    66/   64     3   132/  672 OPEN
% l2control -a 00:02:72:00:d4:1a read_connection_list
L2CAP connections:
Remote BD_ADDR    Handle Flags Pending State
00:07:e0:00:0b:ca     41 O           0 OPEN

Outra ferramenta de diagnóstico é o btsockstat(1) . Ele é semelhante ao netstat(1) , mas para estruturas de dados relacionadas à rede Bluetooth. O exemplo abaixo mostra a mesma conexão lógica que l2control(8) acima.

% btsockstat
Active L2CAP sockets
PCB      Recv-Q Send-Q Local address/PSM       Foreign address   CID   State
c2afe900      0      0 00:02:72:00:d4:1a/3     00:07:e0:00:0b:ca 66    OPEN
Active RFCOMM sessions
L2PCB    PCB      Flag MTU   Out-Q DLCs State
c2afe900 c2b53380 1    127   0     Yes  OPEN
Active RFCOMM sockets
PCB      Recv-Q Send-Q Local address     Foreign address   Chan DLCI State
c2e8bc80      0    250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3    6    OPEN

31.5.5.2. Comunicação por radiofrequência (RFCOMM)

O protocolo RFCOMM fornece emulação de portas seriais sobre o protocolo L2CAP. O RFCOMM é um protocolo de transporte simples, com disposições adicionais para emular os 9 circuitos das portas seriais RS-232 (EIATIA-232-E). Suporta até 60 conexões simultâneas (canais RFCOMM) entre dois dispositivos Bluetooth.

Para fins do RFCOMM, um caminho de comunicação completo envolve dois aplicativos em execução nos terminais de comunicação com um segmento de comunicação entre eles. O RFCOMM destina-se a abranger aplicativos que fazem uso das portas seriais dos dispositivos em que residem. O segmento de comunicação é um link Bluetooth de conexão direta de um dispositivo para outro.

O RFCOMM está relacionado apenas com a conexão entre os dispositivos no caso de conexão direta ou entre o dispositivo e um modem no caso de rede. O RFCOMM pode suportar outras configurações, como módulos que se comunicam via tecnologia sem fio Bluetooth de um lado e fornecem uma interface com fio no outro lado.

No FreeBSD, o RFCOMM é implementado na camada de sockets do Bluetooth.

31.5.5.3. Protocolo de Descoberta de Serviços (SDP)

O Protocolo de Descoberta de Serviços (SDP) fornece os meios para os aplicativos clientes descobrirem a existência de serviços fornecidos por aplicativos de servidor, bem como os atributos desses serviços. Os atributos de um serviço incluem o tipo ou classe de serviço oferecido e as informações de mecanismo ou protocolo necessárias para utilizar o serviço.

O SDP envolve a comunicação entre um servidor SDP e um cliente SDP. O servidor mantém uma lista de registros de serviço que descrevem as características dos serviços associados ao servidor. Cada registro de serviço contém informações sobre um único serviço. Um cliente pode recuperar informações de um registro de serviço mantido pelo servidor SDP emitindo uma solicitação SDP. Se o cliente, ou um aplicativo associado ao cliente, decidir usar um serviço, ele deverá abrir uma conexão separada com o provedor de serviços para utilizar o serviço. O SDP fornece um mecanismo para descobrir serviços e seus atributos, mas não fornece um mecanismo para utilizar esses serviços.

Normalmente, um cliente SDP procura serviços baseados em algumas características desejadas dos serviços. No entanto, há momentos em que é desejável descobrir quais tipos de serviços são descritos pelos registros de serviço de um servidor SDP, sem qualquer informação prévia sobre os serviços. Este processo de procurar por qualquer serviço oferecido é chamado de navegação .

O servidor Bluetooth SDP, sdpd(8) e o cliente de linha de comandos, sdpcontrol(8) , estão incluídos na instalação padrão do FreeBSD. O exemplo a seguir mostra como executar uma consulta de navegação SDP.

% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
        Service Discovery Server (0x1000)
Protocol Descriptor List:
        L2CAP (0x0100)
                Protocol specific parameter #1: u/int/uuid16 1
                Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
        Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
        LAN Access Using PPP (0x1102)
Protocol Descriptor List:
        L2CAP (0x0100)
        RFCOMM (0x0003)
                Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
        LAN Access Using PPP (0x1102) ver. 1.0

Observe que cada serviço tem uma lista de atributos, como o canal RFCOMM. Dependendo do serviço, o usuário pode precisar anotar alguns dos atributos. Algumas implementações Bluetooth não suportam a navegação de serviço e podem retornar uma lista vazia. Nesse caso, é possível procurar pelo serviço específico. O exemplo abaixo mostra como pesquisar o serviço OBEX Object Push (OPUSH) :

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

A oferta de serviços no FreeBSD para clientes Bluetooth é feita com o servidor sdpd(8) . A seguinte linha pode ser adicionada ao /etc/rc.conf :

sdpd_enable="YES"

Então o daemon sdpd(8) pode ser iniciado com:

# service sdpd start

O aplicativo de servidor local que deseja fornecer um serviço Bluetooth a clientes remotos registrará o serviço com o daemon SDP local . Um exemplo de tal aplicativo é o rfcomm_pppd(8) . Uma vez iniciado, ele registrará o serviço LAN Bluetooth com o daemon local SDP.

A lista de serviços registrados no servidor SDPlocal pode ser obtida através da emissão de uma consulta de navegação SDP através do canal de controle local:

# sdpcontrol -l browse

31.5.5.4. OBEX Object Push (OPUSH)

Object Exchange (OBEX) é um protocolo amplamente utilizado para transferências de arquivos simples entre dispositivos móveis. Seu principal uso é na comunicação por infravermelho, onde é usado para transferências de arquivos genéricos entre notebooks ou PDAs, e para enviar cartões de visita ou entradas de calendário entre telefones celulares e outros dispositivos com Personal Information Manager (PIM).

O servidor e o cliente OBEX são implementados pelo obexapp, que pode ser instalado usando o pacote ou port comms/obexapp .

O cliente OBEX é usado para empurrar e/ou puxar objetos do servidor OBEX. Um exemplo de objeto é um cartão de visita ou um compromisso. O cliente OBEX pode obter o número do canal RFCOMM do dispositivo remoto via SDP. Isso pode ser feito especificando o nome do serviço em vez do número do canal RFCOMM. Os nomes de serviços suportados são: IrMC , FTRN e OPUSH . Também é possível especificar o canal RFCOMM como um número. Abaixo está um exemplo de uma sessão OBEX em que o objeto de informações do dispositivo é extraído do telefone celular e um novo objeto, o cartão de visita, é inserido no diretório do telefone.

% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get telecom/devinfo.txt devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)

Para fornecer o serviço OPUSH, o sdpd(8) deve estar em execução e uma pasta raiz, onde todos os objetos recebidos serão armazenados, deve ser criado. O caminho padrão para a pasta raiz é /var/spool/obex . Por fim, inicie o servidor OBEX em um número de canal RFCOMM válido. O servidor OBEX registrará automaticamente o serviço OPUSH com o daemon SDP local. O exemplo abaixo mostra como iniciar o servidor OBEX.

# obexapp -s -C 10

31.5.5.5. Perfil de porta serial (SPP)

O perfil de porta serial (SPP) permite que dispositivos Bluetooth executem emulação de cabo serial. Este perfil permite que aplicativos legados usem o Bluetooth como um substituto de cabos, através de uma abstração de porta serial virtual.

No FreeBSD, o rfcomm_sppd(1) implementa o SPP e uma pseudo tty é usada como uma abstração de porta serial virtual. O exemplo abaixo mostra como se conectar ao serviço de porta serial de um dispositivo remoto. Um canal RFCOMM não precisa ser especificado uma vez que o rfcomm_sppd(1) pode obtê-lo a partir do dispositivo remoto via SDP. Para sobrescrever isso, especifique um canal RFCOMM na linha de comando.

# rfcomm_sppd -a 00:07:E0:00:0B:CA -t
rfcomm_sppd[94692]: Starting on /dev/pts/6...
/dev/pts/6

Uma vez conectado, o pseudo-tty pode ser usado como porta serial:

# cu -l /dev/pts/6

A pseudo-tty é impressa no stdout e pode ser lida por scripts de wrapper:

PTS=`rfcomm_sppd -a 00:07:E0:00:0B:CA -t`
cu -l $PTS

31.5.6. Solução de problemas

Por padrão, quando o FreeBSD está aceitando uma nova conexão, ele tenta executar uma troca de função e se tornar o mestre. Alguns dispositivos Bluetooth mais antigos que não suportam a troca de função não poderão se conectar. Como a troca de função é executada quando uma nova conexão está sendo estabelecida, não é possível perguntar ao dispositivo remoto se ele suporta a troca de função. No entanto, há uma opção HCI para desativar a alternância de funções no lado local:

# hccontrol -n ubt0hci write_node_role_switch 0

Para exibir pacotes Bluetooth, use o pacote de terceiros hcidump, que pode ser instalado usando o pacote ou port comms/hcidump . Este utilitário é semelhante ao tcpdump(1) e pode ser usado para exibir o conteúdo dos pacotes Bluetooth no terminal e para descarregar os pacotes Bluetooth para um arquivo.

31.6. Bridging

Às vezes, é útil dividir uma rede, como um segmento Ethernet, em segmentos de rede sem precisar criar subnets IP e usar um roteador para conectar os segmentos. Um dispositivo que conecta duas redes dessa maneira é chamado de "bridge".

Uma bridge funciona aprendendo os endereços MAC dos dispositivos em cada uma das suas interfaces de rede. Ele encaminha o tráfego entre as redes somente quando os endereços de origem e destino MAC estão em redes diferentes. Em muitos aspectos, uma brifge é como um switch Ethernet com poucas portas. Um sistema FreeBSD com múltiplas interfaces de rede pode ser configurado para atuar como uma bridge.

Construir uma bridge pode ser útil nas seguintes situações:

Conectar Redes: A operação básica de uma bridge é unir dois ou mais segmentos de rede. Existem muitas razões para usar uma bridge baseada em host em vez de equipamentos de rede, tais como restrições de cabeamento ou firewall. Uma bridge também pode conectar uma interface sem fio em execução no modo hostap a uma rede com fio e atuar como um ponto de acesso.
Firewall de Filtragem / Limitação de Trafego: Uma bridge pode ser usada quando a funcionalidade de firewall é necessária sem a realização de roteamento ou conversão de endereços de rede (NAT).

Um exemplo é uma pequena empresa conectada via DSL ou ISDN a um ISP. Existem treze endereços IP públicos do ISP e dez computadores na rede. Nessa situação, é difícil usar um firewall baseado em roteador devido a problemas de sub-rede. Um firewall baseado em bridge pode ser configurado sem qualquer problema de endereçamento IP.
Inspeção de Rede: Uma bridge pode unir dois segmentos de rede para inspecionar todos os pacotes Ethernet que passam entre elas usando bpf(4) e tcpdump(1) na interface de bridge ou enviando uma cópia de todos os frames para uma interface adicional conhecida como span port.
VPN de Camada 2: Duas redes Ethernet podem ser unidas através de um link IP ligando as redes a um túnel EtherIP ou a uma solução baseada no tap(4) tal como o OpenVPN.
Redundância de Camada 2: Uma rede pode ser conectada com vários links e usar o protocolo Spanning Tree (STP) para bloquear caminhos redundantes.

Esta seção descreve como configurar um sistema FreeBSD como uma bridge usando o if_bridge(4) . Um driver de bridge netgraph também está disponível e é descrito em ng_bridge(4) .

A filtragem de pacotes pode ser usada com qualquer pacote de firewall que se conecte ao framework pfil(9) . A bridge pode ser usada como um modelador de tráfego com o altq(4) ou dummynet(4) .

31.6.1. Habilitando a Bridge

No FreeBSD, o if_bridge(4) é um módulo do kernel que é carregado automaticamente pelo ifconfig(8) ao criar uma interface de bridge. Também é possível compilar o suporte de bridge em um kernel customizado adicionando device if_bridge ao arquivo de configuração do kernel personalizado.

A bridge é criada usando clonagem de interface. Para criar a interface da bridge:

# ifconfig bridge create
bridge0
# ifconfig bridge0
bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 96:3d:4b:f1:79:7a
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0

Quando uma interface de bridge é criada, ela recebe automaticamente um endereço Ethernet gerado aleatoriamente. Os parâmetros maxaddr e timeout controlam quantos endereços MAC a bridge manterá em sua tabela de encaminhamento e quantos segundos o sistema irá esperar antes de cada entrada ser removida após um endereço MAC ser visto pela última vez. Os outros parâmetros controlam como o STP opera.

Em seguida, especifique quais interfaces de rede adicionar como membros da bridge. Para a bridge encaminhar pacotes, todas as interfaces de membros e a bridge precisam estar ativas:

# ifconfig bridge0 addm fxp0 addm fxp1 up
# ifconfig fxp0 up
# ifconfig fxp1 up

A bridge agora pode encaminhar quadros Ethernet entre fxp0 e fxp1 . Adicione as seguintes linhas ao /etc/rc.conf para que a bridge seja criada na inicialização:

cloned_interfaces="bridge0"
ifconfig_bridge0="addm fxp0 addm fxp1 up"
ifconfig_fxp0="up"
ifconfig_fxp1="up"

Se o host de ponte precisar de um endereço IP, defina-o na interface de bridge, não nas interfaces de membro. O endereço pode ser definido estaticamente ou via DHCP. Este exemplo define um endereço IP estático:

# ifconfig bridge0 inet 192.168.0.1/24

Também é possível atribuir um endereço IPv6 a uma interface de bridge. Para tornar as mudanças permanentes, adicione as informações de endereçamento ao /etc/rc.conf .

Quando a filtragem de pacotes está habilitada, os pacotes passarão pela entrada do filtro na interface de origem na interface da bridge e na saída nas interfaces apropriadas. Qualquer estágio pode ser desativado. Quando a direção do fluxo de pacotes é importante, é melhor usar o firewall nas interfaces de membros, em vez da própria bridge.

A bridge tem várias opções configuráveis para o trafego de pacotes IP e não-IP, e a filtragem de pacotes layer2 com o ipfw(8) . Veja if_bridge(4) para maiores informações.

31.6.2. Ativando o Spanning Tree

Para que uma rede Ethernet funcione corretamente, somente um caminho ativo pode existir entre dois dispositivos. O protocolo STP detecta loops e coloca links redundantes em um estado bloqueado. Se um dos links ativos falhar, o STP calcula uma árvore diferente e habilita um dos caminhos bloqueados para restaurar a conectividade a todos os pontos da rede.

O protocolo Rapid Spanning Tree (RSTP ou 802.1w) fornece compatibilidade retroativa com o STP legado. O RSTP fornece uma convergência mais rápida e troca informações com os switches vizinhos para fazer a transição rápida para o modo de encaminhamento sem criar loops. O FreeBSD suporta o RSTP e o STP como modos de operação, com o RSTP sendo o modo padrão.

O STP pode ser ativado nas interfaces de membro usando o ifconfig(8) . Para uma bridge com fxp0 e fxp1 como as interfaces atuais, ative o STP com:

# ifconfig bridge0 stp fxp0 stp fxp1
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether d6:cf:d5:a0:94:6d
        id 00:01:02:4b:d4:50 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:01:02:4b:d4:50 priority 32768 ifcost 0 port 0
        member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                port 3 priority 128 path cost 200000 proto rstp
                role designated state forwarding
        member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                port 4 priority 128 path cost 200000 proto rstp
                role designated state forwarding

Essa ponte possui um spanning tree ID de 00:01:02:4b:d4:50 e uma prioridade de 32768 . Como o root id é o mesmo, indica que esta é a bridge raiz para a árvore.

Outra bridge na rede também tem o STP ativado:

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 96:3d:4b:f1:79:7a
        id 00:13:d4:9a:06:7a priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4
        member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                port 4 priority 128 path cost 200000 proto rstp
                role root state forwarding
        member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                port 5 priority 128 path cost 200000 proto rstp
                role designated state forwarding

A linha root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 mostra que a bridge raiz é 00:01:02:4b:d4:50 e tem um custo de caminho de 400000 desta bridge. O caminho para a bridge raiz é via port 4 , que é fxp0 .

31.6.3. Parâmetros da Interface de Bridge

Vários parâmetros do ifconfig são exclusivos para interligar interfaces. Esta seção resume alguns usos comuns para esses parâmetros. A lista completa de parâmetros disponíveis é descrita em ifconfig(8) .

privado

Uma interface privada não encaminha qualquer tráfego para qualquer outra porta que também seja designada como uma interface privada. O tráfego é bloqueado incondicionalmente para que nenhum quadro Ethernet seja encaminhado, incluindo pacotes ARP. Se o tráfego precisar ser bloqueado seletivamente, um firewall deve ser usado no lugar.

span

Uma porta span transmite uma cópia de cada quadro Ethernet recebido pela bridge. O número de portas de span configuradas em uma bridge é ilimitado, mas se uma interface for designada como uma porta de span, ela também não poderá ser usada como uma porta de bridge comum. Isso é mais útil para espionar passivamente uma rede em bridge a partir de outro host conectado a uma das portas da bridge. Por exemplo, para enviar uma cópia de todos os quadros para fora da interface denominada fxp4 :

# ifconfig bridge0 span fxp4

sticky

Se uma interface de membro de uma bridge estiver marcada como fixa, as entradas de endereço aprendidas dinamicamente serão tratadas como entradas estáticas no cache de encaminhamento. Entradas fixas nunca são eliminadas do cache ou substituídas, mesmo que o endereço seja visto em uma interface diferente. Isso oferece o benefício de entradas de endereço estático sem a necessidade de preencher previamente a tabela de encaminhamento. Os clientes aprendidos em um segmento específico da bridge não podem se deslocar para outro segmento.

Um exemplo do uso de endereços fixos é combinar a bridge com VLANs para isolar redes de clientes sem desperdiçar espaço de endereço IP. Considere que CustomerA está em vlan100 , CustomerB está em vlan101 , e a bridge tem o endereço 192.168.0.1 :

# ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101
# ifconfig bridge0 inet 192.168.0.1/24

Neste exemplo, os dois clientes vêem 192.168.0.1 como seu gateway padrão. Como o cache da bridge é fixo, um host não pode falsificar o endereço MAC do outro cliente para interceptar o tráfego.

Qualquer comunicação entre as VLANs pode ser bloqueada usando um firewall ou, como visto neste exemplo, interfaces privadas:

# ifconfig bridge0 private vlan100 private vlan101

Os clientes são completamente isolados uns dos outros e o intervalo completo de endereços /24 pode ser alocado sem criação de sub-redes.

O número de endereços MAC de origem exclusivos por trás de uma interface pode ser limitado. Quando o limite é atingido, os pacotes com endereços de origem desconhecidos são descartados até que uma entrada de cache do host existente expire ou seja removida.

O exemplo a seguir define o número máximo de dispositivos Ethernet para CustomerA em vlan100 para 10:

# ifconfig bridge0 ifmaxaddr vlan100 10

As interfaces de bridge também suportam o modo monitor, onde os pacotes são descartados após processamento do bpf(4) e não são processados ou encaminhados. Isso pode ser usado para multiplexar a entrada de duas ou mais interfaces em um único fluxo bpf(4) . Isso é útil para reconstruir o tráfego de taps de rede que transmitem os sinais RX/TX através de duas interfaces separadas. Por exemplo, para ler a entrada de quatro interfaces de rede como um fluxo:

# ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up
# tcpdump -i bridge0

31.6.4. Monitoramento SNMP

A interface de bridge e os parâmetros de STP podem ser monitorados via o bsnmpd(1) o qual está incluído no sistema básico do FreeBSD. A MIB exportada da bridge está em conformidade com os padrões IETF, portanto, qualquer cliente ou pacote de monitoramento SNMP pode ser usado para recuperar os dados.

Para ativar o monitoramento na bridge, descomente esta linha em /etc/snmpd.config removendo o símbolo inicial # :

begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so"

Outras configurações, como nomes de comunidades e listas de acesso, podem precisar ser modificadas nesse arquivo. Consulte bsnmpd(1) e snmp_bridge(3) para maiores informações. Depois que essas edições forem salvas, adicione esta linha ao /etc/rc.conf :

bsnmpd_enable="YES"

Em seguida, inicie o bsnmpd(1) :

# service bsnmpd start

Os exemplos a seguir usam o software Net-SNMP ( net-mgmt/net-snmp ) para consultar uma bridge a partir de um sistema cliente. O port net-mgmt/bsnmptools também pode ser usado. Do cliente SNMP que está executando o Net-SNMP, adicione as seguintes linhas ao $HOME/.snmp/snmp.conf para importar as definições da bridge MIB:

mibdirs +/usr/shared/snmp/mibs
mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB

Para monitorar uma única bridge usando o IETF BRIDGE-MIB (RFC4188):

% snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge
BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44
BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 1 ports
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (189959) 0:31:39.59 centi-seconds
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 2
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 80 00 00 01 02 4B D4 50
...
BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 200000
BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 80 00 00 01 02 4B D4 50
BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 0
BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 01 02 4B D4 50
BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 03 80
BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1
RSTP-MIB::dot1dStpVersion.0 = INTEGER: rstp(2)

O valor dot1dStpTopChanges.0 é dois, indicando que a topologia da bridge STP foi alterada duas vezes. Uma alteração de topologia significa que um ou mais links na rede foram alterados ou falharam e uma nova árvore foi calculada. O valor de dot1dStpTimeSinceTopologyChange.0 será exibido quando isso acontecer.

Para monitorar várias interfaces de bridge, o BEGEMOT-BRIDGE-MIB privado pode ser usado:

% snmpwalk -v 2c -c public bridge1.example.com
enterprises.fokus.begemot.begemotBridge
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge0" = STRING: bridge0
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge2" = STRING: bridge2
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge0" = STRING: e:ce:3b:5a:9e:13
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge2" = STRING: 12:5e:4d:74:d:fc
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge0" = INTEGER: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge2" = INTEGER: 1
...
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge0" = Timeticks: (116927) 0:19:29.27 centi-seconds
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge2" = Timeticks: (82773) 0:13:47.73 centi-seconds
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge0" = Counter32: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge2" = Counter32: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge0" = Hex-STRING: 80 00 00 40 95 30 5E 31
BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00 00 50 8B B8 C6 A9

Para alterar a interface da bridge que está sendo monitorada através da subárvore mib-2.dot1dBridge :

% snmpset -v 2c -c private bridge1.example.com
BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2

31.7. Agregação de links e failover

O FreeBSD fornece a interface lagg(4) que pode ser usada para agregar várias interfaces de rede em uma interface virtual para fornecer failover e agregação de links. O failover permite que o tráfego continue a fluir, desde que pelo menos uma interface de rede agregada tenha um link estabelecido. A agregação de links funciona melhor em switches compatíveis com LACP, pois esse protocolo distribui o tráfego bidirecionalmente ao responder à falha de links individuais.

Os protocolos de agregação suportados pela interface lagg determinam quais portas são usadas para o tráfego de saída e se uma porta específica aceita tráfego de entrada. Os seguintes protocolos são suportados pelo lagg(4) :

failover: Este modo envia e recebe tráfego somente através da porta principal. Se a porta principal ficar indisponível, a próxima porta ativa será usada. A primeira interface adicionada à interface virtual é a porta principal e todas as interfaces adicionadas posteriormente são usadas como dispositivos de failover. Se ocorrer um failover em uma porta não mestre, a porta original se tornará a principal quando estiver disponível novamente.
fec / loadbalance: Cisco™ Fast EtherChannel™ (FEC) é encontrado em versões anteriores de switches Cisco ™. Ele fornece uma configuração estática e não negocia a agregação com o par ou troca quadros para monitorar o link. Se o switch suportar LACP, isso deve ser usado em seu lugar.
lacp: O protocolo de controle de agregação de links IEEE™ 802.3ad (LACP) negocia um conjunto de links agregáveis com o peer em um ou mais grupos agregados de links (LAGs). Cada LAG é composto de portas da mesma velocidade, configuradas para operação full-duplex e o tráfego é balanceado entre as portas no LAG com a maior velocidade total. Normalmente, há apenas um LAG que contém todas as portas. No caso de alterações na conectividade física, o LACP convergirá rapidamente para uma nova configuração.

O LACP equilibra o tráfego de saída nas portas ativas com base nas informações de hash do cabeçalho do protocolo e aceita tráfego de entrada de qualquer porta ativa. O hash inclui o endereço Ethernet de origem e destino e, se disponível, a tag VLAN e o endereço de origem e destino IPv4 ou IPv6.
roundrobin: Esse modo distribui o tráfego de saída usando um agendador round-robin por meio de todas as portas ativas e aceita tráfego de entrada de qualquer porta ativa. Como esse modo viola a ordenação de quadros Ethernet, ele deve ser usado com cautela.

31.7.1. Exemplos de configuração

Esta seção demonstra como configurar um switch Cisco™ e um sistema FreeBSD para balanceamento de carga LACP. Em seguida, ele mostra como configurar duas interfaces Ethernet no modo de failover, além de como configurar o modo de failover entre uma Ethernet e uma interface sem fio.

Exemplo 1. Agregação LACP com um switch Cisco™

Este exemplo conecta duas interfaces Ethernet fxp(4) em uma máquina FreeBSD às duas primeiras portas Ethernet em um switch Cisco™ como um link de carga única balanceada e tolerante a falhas. Mais interfaces podem ser adicionadas para aumentar o rendimento e a tolerância a falhas. Substitua os nomes das portas Cisco™, dos dispositivos Ethernet, do número do grupo de canais e do endereço IP mostrado no exemplo para corresponder à configuração local.

A ordenação de quadros é obrigatória em links Ethernet e qualquer tráfego entre duas estações sempre flui pelo mesmo link físico, limitando a velocidade máxima àquela de uma interface. O algoritmo de transmissão tenta usar o máximo de informações possível para distinguir diferentes fluxos de tráfego e equilibrar os fluxos entre as interfaces disponíveis.

No switch Cisco™, adicione as interfaces FastEthernet0/1 e FastEthernet0/2 ao grupo de canais 1 :

 interface FastEthernet0/1
 channel-group 1 mode active
 channel-protocol lacp
!
interface FastEthernet0/2
 channel-group 1 mode active
 channel-protocol lacp

No sistema FreeBSD, crie a interface lagg(4) usando as interfaces físicas fxp0 e fxp1 e suba as interfaces com o endereço IP de 10.0.0.3/24 :

# ifconfig fxp0 up
# ifconfig fxp1 up
# ifconfig lagg0 create
# ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24

Em seguida, verifique o status da interface virtual:

# ifconfig lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:05:5d:71:8d:b8
        inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet autoselect
        status: active
        laggproto lacp
        laggport: fxp1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
        laggport: fxp0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Portas marcadas como ACTIVE fazem parte do LAG que foi negociado com o switch remoto. O tráfego será transmitido e recebido através dessas portas ativas. Adicione -v ao comando acima para ver os identificadores LAG.

Para ver o status da porta no switch Cisco™:

switch# show lacp neighbor
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode

Channel group 1 neighbors

Partner's information:

                  LACP port                        Oper    Port     Port
Port      Flags   Priority  Dev ID         Age     Key     Number   State
Fa0/1     SA      32768     0005.5d71.8db8  29s    0x146   0x3      0x3D
Fa0/2     SA      32768     0005.5d71.8db8  29s    0x146   0x4      0x3D

Para mais detalhes, digite show lacp neighbor detail .

Para manter esta configuração através de reinicializações, adicione as seguintes entradas ao /etc/rc.conf no sistema FreeBSD:

ifconfig_fxp0="up"
ifconfig_fxp1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24"

Exemplo 2. Modo de Failover

O modo de failover pode ser usado para alternar para uma interface secundária se o link for perdido na interface principal. Para configurar o failover, certifique-se de que as interfaces físicas subjacentes estejam ativadas e crie a interface lagg(4) . Neste exemplo, fxp0 é a interface principal, fxp1 é a interface secundária e a interface virtual recebeu um endereço IP de 10.0.0.15/24 :

# ifconfig fxp0 up
# ifconfig fxp1 up
# ifconfig lagg0 create
# ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24

A interface virtual deve ser algo como isto:

# ifconfig lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:05:5d:71:8d:b8
        inet 10.0.0.15 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet autoselect
        status: active
        laggproto failover
        laggport: fxp1 flags=0<>
        laggport: fxp0 flags=5<MASTER,ACTIVE>

O tráfego será transmitido e recebido em fxp0 . Se o link for perdido em fxp0 , fxp1 se tornará o link ativo. Se o link for restaurado na interface principal, ele se tornará novamente o link ativo.

Para manter essa configuração através de reinicializações, adicione as seguintes entradas ao /etc/rc.conf :

ifconfig_fxp0="up"
ifconfig_fxp1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24"

Exemplo 3. Modo de failover entre interfaces Ethernet e sem fio

Para usuários de laptop, geralmente é desejável configurar o dispositivo sem fio como secundário, que é usado somente quando a conexão Ethernet não está disponível. Com lagg(4) , é possível configurar um failover que preferia a conexão Ethernet por motivos de desempenho e de segurança, mantendo a capacidade de transferência dados através da conexão sem fio.

Isso é obtido substituindo o endereço MAC da interface Ethernet com o da interface wireless.

Em teoria, o endereço MAC da Ethernet ou da wireless pode ser alterado para corresponder ao outro. No entanto, algumas interfaces wireless populares não têm suporte para substituir o endereço MAC. Portanto, recomendamos substituir o endereço MAC da Ethernet para esse fim.

Se o driver para a interface wireless não estiver carregado no kernel GENERIC ou customizado, e o computador estiver rodando o FreeBSD 12.1, carregue o .ko correspondente no arquivo /boot/loader.conf adicionando _driver__load="YES" e reiniciando a maquina. Outra forma melhor, é carregar o driver no arquivo /etc/rc.conf adicionando a variável kld_list (veja rc.conf(5) para maiores detalhes) nesse arquivo e reiniciar. Isso é necessário porque de outra forma o driver não estará carregado no tempo em que a interface lagg(4) for configurada.

Neste exemplo, a interface Ethernet, re0 , é a interface principal e a interface sem fio, wlan0 , é o failover. A interface wlan0 foi criada a partir da interface wireless ath0 , e a interface Ethernet será configurada com o endereço MAC da interface wireless. Primeiro, determine o endereço MAC da interface wireless:

# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether b8:ee:65:5b:32:59
	groups: wlan
	ssid Bbox-A3BD2403 channel 6 (2437 MHz 11g ht/20) bssid 00:37:b7:56:4b:60
	regdomain ETSI country FR indoor ecm authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
	protmode CTS ampdulimit 64k ampdudensity 8 shortgi -stbctx stbcrx
	-ldpc wme burst roaming MANUAL
	media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
	status: associated
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Substitua wlan0 para corresponder ao nome da interface wireless do sistema. A linha ether conterá o endereço MAC da interface especificada. Agora, altere o endereço MAC da interface Ethernet subjacente:

# ifconfig re0 ether b8:ee:65:5b:32:59

Suba a interface sem fio (substituindo FR pelo seu próprio código de país com duas letras), mas não defina um endereço IP:

# ifconfig wlan0 create wlandev ath0 country FR ssid my_router up

Certifique-se de que a interface re0 esteja ativa, então crie a interface lagg(4) com a re0 como master com failover para a_wlan0_:

# ifconfig re0 up
# ifconfig lagg0 create
# ifconfig lagg0 up laggproto failover laggport re0 laggport wlan0

A interface virtual deve ser algo como isto:

# ifconfig lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether b8:ee:65:5b:32:59
        laggproto failover lagghash l2,l3,l4
        laggport: re0 flags=5<MASTER,ACTIVE>
        laggport: wlan0 flags=0<>
        groups: lagg
        media: Ethernet autoselect
        status: active

Em seguida, inicie o cliente DHCP para obter um endereço IP:

# dhclient lagg0

Para manter essa configuração através de reinicializações, adicione as seguintes entradas ao /etc/rc.conf :

ifconfig_re0="ether b8:ee:65:5b:32:59"
wlans_ath0="wlan0"
ifconfig_wlan0="WPA"
create_args_wlan0="country FR"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 DHCP"

31.8. Operação Diskless com PXE

O Ambiente de execução de pré-inicialização da Intel™ (PXE) permite que um sistema operacional inicialize pela rede. Por exemplo, um sistema FreeBSD pode inicializar através da rede e operar sem um disco local, usando sistemas de arquivos montados a partir de um servidor NFS. O suporte para PXE geralmente está disponível no BIOS. Para usar o PXE quando a máquina iniciar, selecione a opção Inicialização da rede na configuração do BIOS ou digite uma tecla de função durante a inicialização do sistema.

Para fornecer os arquivos necessários para um sistema operacional inicializar pela rede, uma configuração do PXE também requer o DHCP, TFTP configurado corretamente e Servidores NFS, onde:

Parâmetros iniciais, como endereço de IP, nome e localização do arquivo de inicialização executável, nome do servidor e caminho do root são obtidos do servidor DHCP.
O arquivo do carregador do sistema operacional é inicializado usando TFTP.
Os sistemas de arquivos são carregados usando o NFS.

Quando um computador PXE inicializa, ele recebe informações por meio do DHCP sobre onde obter o arquivo inicial do carregador de boot. Depois que o computador host recebe essa informação, ele faz o download do carregador de boot via TFTP e, em seguida, executa o carregador de boot. No FreeBSD, o arquivo do gerenciador de boot é o /boot/pxeboot . Depois que o /boot/pxeboot é executado, o kernel do FreeBSD é carregado e o resto da seqüência de inicialização do FreeBSD continua, como descrito em O processo de inicialização do FreeBSD .

Esta seção descreve como configurar estes serviços em um sistema FreeBSD para que outros sistemas possam inicializar o PXE a partir do FreeBSD. Consulte diskless(8) para obter maiores informações.

Conforme descrito, o sistema que fornece esses serviços é inseguro. Ele deve ficar em uma área protegida de uma rede e não deve ser considerado confiável por outros hosts.

31.8.1. Configurando o ambiente PXE

As etapas mostradas nesta seção configuram os servidores internos de NFS e TFTP. A próxima seção demonstra como instalar e configurar o servidor DHCP. Neste exemplo, o diretório que conterá os arquivos usados pelos usuários do PXE é o /b/tftpboot/FreeBSD/install . É importante que este diretório exista e que o mesmo nome de diretório seja configurado no /etc/inetd.conf e no /usr/local/etc/dhcpd.conf .

Crie o diretório raiz que irá conter uma instalação do FreeBSD para ser montado por NFS:
```
# export NFSROOTDIR=/b/tftpboot/FreeBSD/install
# mkdir -p ${NFSROOTDIR}
```
Ative o servidor NFS adicionando esta linha ao /etc/rc.conf :
```
nfs_server_enable="YES"
```
Exporte o diretório raiz sem disco via NFS adicionando o seguinte ao /etc/exports :
```
/b -ro -alldirs -maproot=root
```
Inicie o servidor NFS:
```
# service nfsd start
```
Ative o inetd(8) adicionando a seguinte linha ao /etc/rc.conf :
```
inetd_enable="YES"
```

Descomente a seguinte linha no /etc/inetd.conf certificando-se de que ela não comece com um símbolo # :

tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /b/tftpboot

Algumas versões do PXE exigem a versão TCP do TFTP. Neste caso, remova o comentário da segunda linha tftp que contém stream tcp .

Inicie o inetd(8) :
```
# service inetd start
```
Instale o sistema básico em ${NFSROOTDIR} , seja descompactando os arquivos oficiais ou recompilando o kernel do FreeBSD e o userland (consulte Atualizando o FreeBSD a partir do código fonte para instruções mais detalhadas, mas não esqueça de adicionar DESTDIR= ${NFSROOTDIR} ao executar os comandos make installkernel e make installworld .
Teste que o servidor TFTP funciona e que pode baixar o gerenciador de boot que será obtido via PXE:
```
# tftp localhost
tftp> get FreeBSD/install/boot/pxeboot
Received 264951 bytes in 0.1 seconds
```
Edite o ${NFSROOTDIR}/etc/fstab e crie uma entrada para montar o sistema de arquivos raiz por meio do NFS:
```
# Device                                         Mountpoint    FSType   Options  Dump Pass
myhost.example.com:/b/tftpboot/FreeBSD/install       /         nfs      ro        0    0
```
Substitua myhost.example.com pelo nome do host ou pelo endereço IP do servidor NFS. Neste exemplo, o sistema de arquivos raiz é montado como somente leitura para evitar que os clientes do NFS excluam potencialmente o conteúdo do sistema de arquivos raiz.
Defina a senha de root no ambiente PXE para as máquinas clientes que serão inicializadas por PXE:
```
# chroot ${NFSROOTDIR}
# passwd
```
Se necessário, ative o login do root via ssh(1) para as máquinas clientes que estão inicializando por PXE editando o ${NFSROOTDIR}/etc/ssh/sshd_config e habilitando o PermitRootLogin . Esta opção está documentada em sshd_config(5) .
Execute qualquer outra customização necessária do ambiente PXE no ${NFSROOTDIR} . Estas customizações podem incluir coisas como instalar pacotes ou editar o arquivo de senha com o vipw(8) .

Ao inicializar de um volume raiz NFS, o /etc/rc detecta a inicialização do NFS e executa o /etc/rc.initdiskless . Neste caso, o /etc e /var precisam ser sistemas de arquivos montados em memória para que estes diretórios sejam graváveis mas o diretório raiz NFS seja apenas de leitura:

# chroot ${NFSROOTDIR}
# mkdir -p conf/base
# tar -c -v -f conf/base/etc.cpio.gz --format cpio --gzip etc
# tar -c -v -f conf/base/var.cpio.gz --format cpio --gzip var

Quando o sistema inicializar, os sistemas de arquivos em memória para o /etc e o /var serão criados e montados e o conteúdo dos arquivos cpio.gz será copiado para eles. Por padrão, esses sistemas de arquivos têm uma capacidade máxima de 5 megabytes. Se seus arquivos não couberem, o que geralmente é o caso do /var quando pacotes binários foram instalados, solicite um tamanho maior colocando o número de setores de 512 bytes necessários (por exemplo, 5 megabytes é 10240 setores) nos arquivos ${NFSROOTDIR}/conf/base/etc/md_size e ${NFSROOTDIR}/conf/base/var/md_size para os sistemas de arquivos /etc e o /var respectivamente.

31.8.2. Configurando o servidor DHCP

O servidor DHCP não precisa ser a mesma máquina que o servidor TFTP e NFS, mas ele precisa estar acessível na rede.

O DHCP não faz parte do sistema básico do FreeBSD, mas pode ser instalado usando o port ou pacote net/isc-dhcp44-server .

Uma vez instalado, edite o arquivo de configuração, /usr/local/etc/dhcpd.conf . Configure as diretivas next-server , filename e root-path conforme mostrado neste exemplo:

subnet 192.168.0.0 netmask 255.255.255.0 {
   range 192.168.0.2 192.168.0.3 ;
   option subnet-mask 255.255.255.0 ;
   option routers 192.168.0.1 ;
   option broadcast-address 192.168.0.255 ;
   option domain-name-servers 192.168.35.35, 192.168.35.36 ;
   option domain-name "example.com";

   # IP address of TFTP server
   next-server 192.168.0.1 ;

   # path of boot loader obtained via tftp
   filename "FreeBSD/install/boot/pxeboot" ;

   # pxeboot boot loader will try to NFS mount this directory for root FS
   option root-path "192.168.0.1:/b/tftpboot/FreeBSD/install/" ;

}

A diretiva next-server é usada para especificar o endereço IP do servidor TFTP.

A diretiva filename define o caminho para o /boot/pxeboot . Um nome de arquivo relativo é usado, significando que /b/tftpboot não está incluído no caminho.

A diretiva root-path define o caminho para o sistema de arquivos raiz a ser montado por NFS.

Depois que as edições forem salvas, ative o DHCP no momento da inicialização adicionando a seguinte linha ao /etc/rc.conf :

dhcpd_enable="YES"

Então inicie o serviço DHCP:

# service isc-dhcpd start

31.8.3. Depurando problemas de PXE

Uma vez que todos os serviços estejam configurados e iniciados, os clientes de PXE devem poder carregar automaticamente o FreeBSD pela rede. Se um determinado cliente não conseguir se conectar, quando a máquina cliente inicializar, entre no menu de configuração da BIOS e confirme se ela está configurada para inicializar a partir da rede.

Esta seção descreve algumas dicas de solução de problemas para isolar a origem do problema de configuração, caso nenhum cliente seja capaz de inicializar o PXE.

Use o pacote ou port net/wireshark para depurar o tráfego de rede envolvido durante o processo de inicialização do PXE, que está ilustrado no diagrama abaixo.

Figura 1. Processo de inicialização PXE com o sistema de arquivos raiz montado por NFS
No servidor TFTP, leia o /var/log/xferlog para garantir que o pxeboot esteja sendo recuperado do local correto. Para testar esta configuração de exemplo:
```
# tftp 192.168.0.1
tftp> get FreeBSD/install/boot/pxeboot
Received 264951 bytes in 0.1 seconds
```
As seções de BUGS do tftpd(8) e tftp(1) documenta algumas limitações com o TFTP.
Certifique-se de que o sistema de arquivos raiz possa ser montado via NFS. Para testar esta configuração de exemplo:
```
# mount -t nfs 192.168.0.1:/b/tftpboot/FreeBSD/install /mnt
```

31.9. IPv6

O IPv6 é a nova versão do conhecido protocolo IP, também conhecido como IPv4. O IPv6 oferece várias vantagens sobre o IPv4, além de muitos recursos novos:

Seu espaço de endereços de 128 bits permite 340.282.366.920.938.463.463.374.607.431.768.211.456 endereços. Isso corrige a falta de endereços do IPv4 e o eventual esgotamento do endereço de IPv4.
Os roteadores armazenam apenas endereços de agregação de rede em suas tabelas de roteamento, reduzindo assim o espaço médio de uma tabela de roteamento para 8192 entradas. Isso resolve os problemas de escalabilidade associados ao IPv4, que exigia que cada bloco alocado de endereços IPv4 fossem trocados entre roteadores da Internet, fazendo com que suas tabelas de roteamento ficassem muito grandes para permitir um roteamento eficiente .
Autoconfiguração de endereço ( RFC2462 ).
Endereços multicast obrigatórios.
IPsec Embutido (Segurança IP).
Estrutura simplificada do cabeçalho.
Suporte para mobile IP.
Mecanismos de transição IPv6-to-IPv4.

O FreeBSD inclui a implementação de referência do http://www.kame.net/ IPv6 e vem com tudo necessário usar o IPv6. Esta seção se concentra em configurar e executar o IPv6.

31.9.1. Informações sobre endereços de IPv6

Existem três tipos diferentes de endereços de IPv6:

Unicast: Um pacote enviado para um endereço unicast chega à interface pertencente ao endereço.
Anycast: Esses endereços são sintaticamente indistinguíveis dos endereços unicast, mas eles tratam de um grupo de interfaces. O pacote destinado a um endereço anycast chegará à interface do roteador mais próxima. Endereços anycast são usados apenas por roteadores.
Multicast: Esses endereços identificam um grupo de interfaces. Um pacote destinado a um endereço multicast chegará a todas as interfaces pertencentes ao grupo multicast. O endereço de broadcast IPv4 , geralmente xxx.xxx.xxx.255 , é expresso por endereços multicast em IPv6.

Ao ler um endereço IPv6, a forma canônica é representada como x:x:x:x:x:x:x:x , onde cada x representa um valor hexadecimal de 16 bits. Um exemplo é FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 .

Muitas vezes, um endereço terá substrings longas apenas com zeros. Um :: (dois-pontos duplos) pode ser usado para substituir uma subcadeia por endereço. Além disso, até três valores 0 s iniciais por valor hexadecimal podem ser omitidos. Por exemplo, fe80::1 corresponde à forma canônica fe80:0000:0000:0000:0000:0000:0000:0001 .

Uma terceira forma é escrever os últimos 32 bits usando a conhecida notação IPv4. Por exemplo, 2002::10.0.0.1 corresponde à representação canônica hexadecimal 2002:0000:0000:0000:0000:0000:0a00:0001 , que por sua vez é equivalente a 2002::a00:1 .

Para visualizar o endereço IPv6 do sistema FreeBSD, use ifconfig(8) :

# ifconfig

rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
         inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
         inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1
         ether 00:00:21:03:08:e1
         media: Ethernet autoselect (100baseTX )
         status: active

Neste exemplo, a interface rl0 está usando fe80::200:21ff:fe03:8e1%rl0 , um endereço local de link auto-configurado que foi gerado automaticamente a partir do endereço MAC.

Alguns endereços do IPv6 são reservados. Um resumo destes endereços reservados é visto em Endereços IPv6 reservados :

Tabela 3. Endereços IPv6 reservados
endereço IPv6	Prefixlength (Bits)	Descrição	Notas
`::`	128 bits	não especificado	Equivalente a `0.0.0.0` em IPv4.
`::1`	128 bits	endereço de loopback	Equivalente ao `127.0.0.1` no IPv4.
`::00:xx:xx:xx:xx`	96 bits	IPv4 Embarcado	Os 32 bits inferiores são o endereço IPv4 compatível.
`::ff:xx:xx:xx:xx`	96 bits	O endereço IPv4 mapeado do endereço IPv6	Os 32 bits mais baixos são o endereço IPv4 para hosts que não suportam o IPv6.
`fe80::/10`	10 bits	link-local	Equivalente a 169.254.0.0/16 em IPv4.
`fc00::/7`	7 bits	unique-local	Endereços locais exclusivos são destinados à comunicação local e só podem ser roteados dentro de um conjunto de sites cooperantes.
`ff00::`	8 bits	multicast
`2000::-3fff::`	3 bits	unicast global	Todos os endereços unicast globais são atribuídos a partir desse pool. Os primeiros 3 bits são `001` .

Para maiores informações sobre a estrutura dos endereços do IPv6, consulte a RFC3513 .

31.9.2. Configurando o IPv6

Para configurar um sistema FreeBSD como um cliente IPv6, adicione estas duas linhas ao rc.conf :

ifconfig_rl0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"

A primeira linha permite que a interface especificada receba mensagens de solicitação do roteador. A segunda linha ativa o daemon de solicitação do roteador, rtsol(8) .

Se a interface precisar de um endereço IPv6 atribuído estaticamente, adicione uma entrada para especificar o endereço estático e o comprimento do prefixo associado:

ifconfig_rl0_ipv6="inet6 2001:db8:4672:6565:2026:5043:2d42:5344 prefixlen 64"

Para atribuir um roteador padrão, especifique seu endereço:

ipv6_defaultrouter="2001:db8:4672:6565::1"

31.9.3. Conectando-se a um provedor

Para se conectar a outras redes IPv6, é necessário ter um provedor ou um túnel que suporte IPv6:

Entre em contato com um provedor de serviços de Internet para saber se eles oferecem IPv6.
O Hurricane Electric oferece túneis com endpoints em todo o mundo.

Instale o pacote ou port net/freenet6 para uma conexão dial-up.

Esta seção demonstra como obter as direções de um provedor de túneis e convertê-las em configurações do /etc/rc.conf que persistirão durante as reinicializações.

A primeira entrada /etc/rc.conf cria a interface de encapsulamento genérica gif0 :

cloned_interfaces="gif0"

Em seguida, configure essa interface com os endereços IPv4 dos pontos de extremidade locais e remotos. Substitua MY_IPv4_ADDR e REMOTE_IPv4_ADDR pelos endereços atuais de IPv4:

create_args_gif0="tunnel MY_IPv4_ADDR REMOTE_IPv4_ADDR"

Para aplicar o endereço IPv6 que foi atribuído para uso como o ponto final do túnel IPv6, adicione esta linha, substituindo MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR pelo endereço atribuído:

ifconfig_gif0_ipv6="inet6 MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR"

Em seguida, defina a rota padrão para o outro lado do túnel IPv6. Substitua MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR pelo endereço do gateway padrão atribuído pelo provedor:

ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR"

Se o sistema FreeBSD irá rotear pacotes IPv6 entre o resto da rede e o mundo, habilite o gateway usando esta linha:

ipv6_gateway_enable="YES"

31.9.4. Anúncio do roteador e configuração automática do host

Esta seção demonstra como configurar o rtadvd(8) para anunciar a rota padrão de IPv6.

Para ativar rtadvd(8) , inclua o seguinte no /etc/rc.conf :

rtadvd_enable="YES"

É importante especificar a interface na qual fazer a solicitação do roteador IPv6. Por exemplo, para informar o rtadvd(8) para usar rl0 :

rtadvd_interfaces="rl0"

Em seguida, crie o arquivo de configuração, /etc/rtadvd.conf como visto neste exemplo:

rl0:\
	:addrs#1:addr="2001:db8:1f11:246::":prefixlen#64:tc=ether:

Substitua rl0 com a interface a ser usada e 2001:db8:1f11:246:: com o prefixo da alocação.

Para uma sub-rede /64 dedicada, nada mais precisa ser alterado. Caso contrário, altere o prefixlen# para o valor correto.

31.9.5. IPv6 e o mapeamento de endereços IPv6

Quando o IPv6 está habilitado em um servidor, pode ser necessário ativar a comunicação de endereços IPv4 mapeados para IPv6. Esta opção de compatibilidade permite que endereços IPv4 sejam representados como endereços de IPv6. Permitir que aplicativos IPv6 se comuniquem com IPv4 e vice-versa pode ser um problema de segurança.

Essa opção pode não ser necessária na maioria dos casos e está disponível apenas para compatibilidade. Esta opção permitirá que os aplicativos que suportam apenas o IPv6 funcionem com IPv4 em um ambiente de pilha dupla. Isso é mais útil para aplicativos de terceiros que podem não suportar um ambiente somente de IPv6. Para habilitar esse recurso, adicione o seguinte ao /etc/rc.conf :

ipv6_ipv4mapping="YES"

Revisar as informações da RFC 3493, seção 3.6 e 3.7, bem como da RFC 4038 seção 4.2, pode ser útil para alguns administradores.

31.10. Protocolo Comum de Redundância de Endereços (CARP)

O Protocolo Comum de Redundância de Endereços (CARP) permite que vários hosts compartilhem o mesmo endereço IP e ID de Host Virtual (VHID) para fornecer alta disponibilidade para um ou mais serviços. Isso significa que um ou mais hosts podem falhar e os outros hosts assumem o controle de modo transparente, de modo que os usuários não percebam uma falha de serviço.

Além do endereço IP compartilhado, cada host tem seu próprio endereço IP para gerenciamento e configuração. Todas as máquinas que compartilham um endereço IP têm o mesmo VHID. O VHID para cada endereço virtual de IP deve ser exclusivo no domínio de broadcast da interface de rede.

A alta disponibilidade usando o CARP é nativa no FreeBSD, embora os passos para configurá-lo variem um pouco dependendo da versão do FreeBSD. Esta seção fornece a mesma configuração de exemplo para versões anteriores, iguais ou posteriores ao FreeBSD 10.

Este exemplo configura o suporte a failover com três hosts, todos com endereços exclusivos de IP, mas que fornecem o mesmo conteúdo da web. Ele tem dois mestres diferentes chamados hosta.example.org e hostb.example.org , com um backup compartilhado chamado hostc.example.org .

O balanceamento de carga destas máquinas é feito por meio de uma configuração de DNS Round Robin. As máquinas principais e de backup são configuradas de forma idêntica, exceto por seus nomes de host e endereços de gerenciamento IP. Esses servidores devem ter a mesma configuração e executar os mesmos serviços. Quando o failover ocorre, as solicitações para o serviço no endereço IP compartilhado só podem ser respondidas corretamente se o servidor de backup tiver acesso ao mesmo conteúdo. A máquina de backup tem duas interfaces CARP adicionais, uma para cada endereço IP do servidor de conteúdo mestre. Quando ocorre uma falha, o servidor de backup selecionará o endereço IP da máquina mestre com falha.

31.10.1. Usando CARP no FreeBSD 10 e Posteriores

Ative o suporte para CARP na inicialização do sistema, adicionando uma entrada para o módulo do kernel carp.ko em /boot/loader.conf :

carp_load="YES"

Para carregar o módulo agora sem reiniciar:

# kldload carp

Para usuários que preferem usar um kernel personalizado, inclua a seguinte linha no arquivo de configuração do kernel personalizado e compile o kernel como descrito em Configurando o kernel do FreeBSD :

device	carp

O nome do host, o endereço IP de gerenciamento e a máscara de sub-rede, o endereço IP compartilhado e o VHID são definidos adicionando entradas ao /etc/rc.conf . Este exemplo é para o hosta.example.org :

hostname="hosta.example.org"
ifconfig_em0="inet 192.168.1.3 netmask 255.255.255.0"
ifconfig_em0_alias0="inet vhid 1 pass testpass alias 192.168.1.50/32"

O próximo conjunto de entradas é para o hostb.example.org . Como ele representa um segundo mestre, ele usa um endereço IP compartilhado diferente e VHID. No entanto, as senhas especificadas com pass devem ser idênticas, pois o CARP somente ouvirá e aceitará anúncios de máquinas com a senha correta.

hostname="hostb.example.org"
ifconfig_em0="inet 192.168.1.4 netmask 255.255.255.0"
ifconfig_em0_alias0="inet vhid 2 pass testpass alias 192.168.1.51/32"

A terceira máquina, hostc.example.org , é configurada para lidar com o failover de um dos mestres. Esta máquina é configurada com dois CARPVHIDs, um para manipular o endereço IP virtual para cada um dos hosts principais. O desvio de publicidade CARP, advskew , é definida para garantir que o host de backup seja anunciado depois do mestre, pois advskew controla a ordem de precedência quando existem vários servidores de backup.

hostname="hostc.example.org"
ifconfig_em0="inet 192.168.1.5 netmask 255.255.255.0"
ifconfig_em0_alias0="inet vhid 1 advskew 100 pass testpass alias 192.168.1.50/32"
ifconfig_em0_alias1="inet vhid 2 advskew 100 pass testpass alias 192.168.1.51/32"

Ter dois CARPVHIDs configurados significa que o hostc.example.org notará se um dos servidores principais ficar indisponível. Se um mestre falhar em anunciar antes do servidor de backup, o servidor de backup selecionará o endereço IP compartilhado até que o mestre se torne disponível novamente.

Se o servidor mestre original se tornar disponível novamente, o hostc.example.org não liberará o endereço virtual IP de volta a ele automaticamente. Para que isso aconteça, a preempção deve ser ativada. O recurso está desabilitado por padrão, ele é controlado por meio da variável sysctl(8) net.inet.carp.preempt . O administrador pode forçar o servidor de backup a retornar o endereço IP para o mestre:

# ifconfig em0 vhid 1 state backup

Quando a configuração estiver concluída, reinicie a rede ou reinicie cada um dos sistemas. A alta disponibilidade está agora ativada.

A funcionalidade CARP pode ser controlada através de diversas variáveis sysctl(8) documentadas nas páginas de manual do carp(4) . Outras ações podem ser acionadas a partir de eventos CARP usando devd(8) .

31.10.2. Usando CARP no FreeBSD 9 e Anteriores

A configuração para estas versões do FreeBSD é similar àquela descrita na seção anterior, exceto que o dispositivo CARP deve ser criado primeiro e referenciado na configuração.

Ative o suporte de tempo de inicialização para o CARP carregando o módulo do kernel if_carp.ko no /boot/loader.conf :

if_carp_load="YES"

Para carregar o módulo agora sem reiniciar:

# kldload carp

Para usuários que preferem usar um kernel personalizado, inclua a seguinte linha no arquivo de configuração do kernel personalizado e compile o kernel como descrito em Configurando o kernel do FreeBSD :

device	carp

Em seguida, em cada host, crie um dispositivo CARP:

# ifconfig carp0 create

Defina o nome do host, o endereço IP de gerenciamento, o endereço IP compartilhado e o VHID adicionando as linhas necessárias ao /etc/rc.conf . Como um dispositivo virtual CARP é usado em vez de um alias, uma máscara de subrede real /24 é usada em vez de uma /32 . Aqui estão as entradas para o hosta.example.org :

hostname="hosta.example.org"
ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0"
cloned_interfaces="carp0"
ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24"

Em hostb.example.org :

hostname="hostb.example.org"
ifconfig_fxp0="inet 192.168.1.4 netmask 255.255.255.0"
cloned_interfaces="carp0"
ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24"

A terceira máquina, hostc.example.org , está configurada para lidar com o failover de qualquer um dos hosts principais:

hostname="hostc.example.org"
ifconfig_fxp0="inet 192.168.1.5 netmask 255.255.255.0"
cloned_interfaces="carp0 carp1"
ifconfig_carp0="vhid 1 advskew 100 pass testpass 192.168.1.50/24"
ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24"

A preempção está desabilitada no kernel GENERIC do FreeBSD. Se a preempção tiver sido ativada com um kernel personalizado, o hostc.example.org poderá não liberar o endereço IP de volta ao servidor de conteúdo original. O administrador pode forçar o servidor de backup a retornar o endereço IP para o mestre com o comando:

# ifconfig carp0 down && ifconfig carp0 up

Isso deve ser feito na interface carp , que corresponde ao host correto.

Quando a configuração estiver concluída, reinicie a rede ou reinicie cada um dos sistemas. A alta disponibilidade está agora ativada.

31.11. VLANs

As VLANs são uma forma de dividir virtualmente uma rede em várias sub-redes diferentes, também conhecida como segmentação. Cada segmento terá seu próprio domínio de broadcast e será isolado de outras VLANs.

No FreeBSD, as VLANs devem ser suportadas pelo driver da placa de rede. Para ver quais drivers suportam vlans, consulte a página de manual vlan(4) .

Ao configurar uma VLAN, algumas informações devem ser conhecidas. Primeiro, qual a interface de rede? Segundo, qual é a tag da VLAN?

Para configurar uma VLANs em tempo de execução, com uma NIC em0 e uma tag VLAN de 5 o comando ficaria assim:

# ifconfig em0.5 create vlan 5 vlandev em0 inet 192.168.20.20/24

Viu como o nome da interface inclui o nome do driver da NIC e a tag VLAN, separados por um ponto final? Essa é uma prática recomendada para facilitar a manutenção da configuração de VLAN quando muitas VLANs estiverem presentes em uma máquina.

Para configurar uma VLANs no momento da inicialização, o /etc/rc.conf deve ser atualizado. Para duplicar a configuração acima, será necessário adicionar o seguinte:

vlans_em0="5"
ifconfig_em0_5="inet 192.168.20.20/24"

VLANs adicionais podem ser inseridas, simplesmente adicionando a tag ao campo vlans_em0 e incrementando uma linha de configuração da rede nessa interface da tag VLAN.

É útil atribuir um nome simbólico a uma interface para que, quando o hardware associado for alterado, apenas algumas variáveis de configuração precisem ser atualizadas. Por exemplo, câmeras de segurança precisam ser executadas pela VLAN 1 em em0 . Posteriormente, se a placa em0 for substituída por uma placa que use o driver ixgb(4) , todas as referências a em0.1 não precisarão ser alterado para ixgb0.1 .

Para configurar a VLAN 5 , na NIC em0 , atribua o nome de interface cameras , e atribua à interface um endereço IP de 192.168.20.20 com um prefixo 24 -bit, use este comando:

# ifconfig em0.5 create vlan 5 vlandev em0 name cameras inet 192.168.20.20/24

Para uma interface denominada video , use o seguinte:

# ifconfig video.5 create vlan 5 vlandev video name cameras inet 192.168.20.20/24

Para aplicar as mudanças no momento da inicialização, adicione as seguintes linhas ao /etc/rc.conf :

vlans_video="cameras"
create_args_cameras="vlan 5"
ifconfig_cameras="inet 192.168.20.20/24"

Índice

31.1. Sinopse

31.2. Gateways e Rotas

31.2.1. Fundamentos de roteamento

31.2.2. Configurando um roteador com rotas estáticas

31.2.3. Solução de problemas

31.2.4. Considerações sobre Multicast

31.3. Rede sem fio

31.3.1. Noções básicas sobre redes sem fio

31.3.2. Inicio Rápido

31.3.3. Configuração básica

31.3.3.1. Configuração do Kernel

31.3.3.2. Definindo a Região Correta

31.3.4. Modo de Infraestrutura

31.3.4.1. Clientes do FreeBSD

31.3.4.1.1. Como encontrar pontos de acesso

31.3.4.1.2. Configurações básicas

31.3.4.1.2.1. Selecionando um ponto de acesso

31.3.4.1.2.2. Autenticação

31.3.4.1.2.3. Obtendo um endereço IP com DHCP

31.3.4.1.2.4. Endereço IP estático

31.3.4.1.3. WPA

31.3.4.1.3.1. WPA-PSK

31.3.4.1.3.2. WPA com EAP-TLS

31.3.4.1.3.3. WPA com EAP-TTLS

31.3.4.1.3.4. WPA com EAP-PEAP

31.3.4.1.4. WEP

31.3.5. Modo Ad-hoc

31.3.6. Pontos de Acesso com um host FreeBSD

31.3.6.1. Configurações básicas

31.3.6.2. Ponto de acesso baseado em host sem autenticação ou criptografia

31.3.6.3. Ponto de acesso baseado em host com WPA2

31.3.6.3.1. WPA2-PSK

31.3.6.4. Ponto de acesso baseado em host WEP

31.3.7. Usando conexões com fio e sem fio

31.3.8. Solução de problemas

31.4. USB Tethering

31.5. Bluetooth

31.5.1. Carregando o Suporte Bluetooth

31.5.2. Encontrando outros dispositivos Bluetooth

31.5.3. Emparelhamento de dispositivos

31.5.4. Acesso à rede com perfis PPP

31.5.5. Protocolos Bluetooth

31.5.5.1. Controle de Link Lógico e Protocolo de Adaptação (L2CAP)

31.5.5.2. Comunicação por radiofrequência (RFCOMM)

31.5.5.3. Protocolo de Descoberta de Serviços (SDP)

31.5.5.4. OBEX Object Push (OPUSH)

31.5.5.5. Perfil de porta serial (SPP)

31.5.6. Solução de problemas

31.6. Bridging

31.6.1. Habilitando a Bridge

31.6.2. Ativando o Spanning Tree

31.6.3. Parâmetros da Interface de Bridge

31.6.4. Monitoramento SNMP

31.7. Agregação de links e failover

31.7.1. Exemplos de configuração

31.8. Operação Diskless com PXE

31.8.1. Configurando o ambiente PXE

31.8.2. Configurando o servidor DHCP

31.8.3. Depurando problemas de PXE

31.9. IPv6

31.9.1. Informações sobre endereços de IPv6

31.9.2. Configurando o IPv6

31.9.3. Conectando-se a um provedor

31.9.4. Anúncio do roteador e configuração automática do host

31.9.5. IPv6 e o mapeamento de endereços IPv6

31.10. Protocolo Comum de Redundância de Endereços (CARP)

31.10.1. Usando CARP no FreeBSD 10 e Posteriores

31.10.2. Usando CARP no FreeBSD 9 e Anteriores

31.11. VLANs