[OpenBSD]

[Índice da FAQ] [Seção 5 - Construção do Sistema a partir do Código Fonte] [Seção 7 - Controle do Teclado e da Tela]

6 - Redes


Conteúdo


6.1 - Antes de seguirmos adiante

A fim de melhor compreender este documento, você deve ler e assimilar, no mínimo parcialmente, a seção da FAQ sobre Configuração e configuração do Kernel, e as páginas de manual ifconfig(8) e netstat(1).

Se você é um administrador de redes e está configurando protocolos de roteamento, e se está usando o OpenBSD como roteador, se você precisar entender com mais profundidade redes IP, você realmente precisa ler "Understanding IP Addressing". Esse é um excelente documento. "Understanding IP Addressing" contém os conhecimentos fundamentais para trabalhar com redes IP, especialmente quando você trabalha com uma ou é responsável por mais de uma rede.

Se você está trabalhando com aplicações como servidores Web, servidores ftp e servidores de correio eletrônico, você pode se beneficiar e muito lendo as RFCs. Normalmente você não precisa ler todas elas. Escolha alguns tópicos que você está interessado, ou que você usa no ambiente da sua rede. As RFCs definem muitos (milhares de) padrões para protocolos na Internet e como eles supostamente devem funcionar.

6.2 - Configuração da rede

Normalmente, o OpenBSD é inicialmente configurado pelo processo de instalação. No entanto, é bom entender o que acontece nesse processo e como ele funciona. Todas as configurações de rede são feitas usando arquivos de texto simples no diretório /etc.

6.2.1 - Identificação e configuração das interfaces de rede

No OpenBSD, as interfaces são nomeadas pelo tipo de placa, não pelo tipo de conexão. Você pode ver sua placa de rede sendo carregada durante o processo de inicialização, ou após esse processo usando o comando dmesg(8). Você também tem a chance de visualizar sua interface de rede usando o comando ifconfig(8). Por exemplo, aqui está a saída do dmesg para uma placa de rede Intel Fast Ethernet, a qual usa o nome de dispositivo fxp.

fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4

Se você não sabe que nome seu dispositivo tem, por favor olhe a lista de hardware suportado da sua plataforma. Você achará uma lista de muitos nomes de placas comuns e seus nomes de dispositivos no OpenBSD. Combine o nome alfabético curto do dispositivo (tal como fxp) com um número atribuído pelo kernel e você tem um nome de interface (tal como fxp0). O número é atribuído baseando-se em vários critérios, dependendo da placa e outros detalhes do sistema. Algumas placas recebem a atribuição pela ordem em que elas são encontradas durante a inicialização. Outras podem ser por meio de configurações de hardware ou endereço MAC.

Você pode encontrar quais interfaces de rede foram identificadas usando o utilitário ifconfig(8). O seguinte comando mostra todas as interfaces de rede no seu sistema. Esta amostra de saída nos mostra somente uma interface Ethernet física, uma fxp(4).

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 33224
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:04:ac:dd:39:6a
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
        inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 2020
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
tun0: flags=10<POINTOPOINT> mtu 3000
tun1: flags=10<POINTOPOINT> mtu 3000
enc0: flags=0<> mtu 1536
bridge0: flags=0<> mtu 1500
bridge1: flags=0<> mtu 1500
vlan0: flags=0<> mtu 1500
        address: 00:00:00:00:00:00
vlan1: flags=0<> mtu 1500
        address: 00:00:00:00:00:00
gre0: flags=9010<POINTOPOINT,LINK0,MULTICAST> mtu 1450
carp0: flags=0<> mtu 1500
carp1: flags=0<> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

Como você pode ver aqui, o ifconfig(8) nos dá muita informação que nós precisamos neste ponto. Ele ainda nos permite ver nossa interface. Isso é óbvio, porque uma rede IP está configurada em fxp0, com os valores "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Além disso, os sinalizadores UP e RUNNING estão marcados.

E finalmente, você pode notar muitas outras interfaces que vêm ativadas por padrão. Estas são interfaces virtuais que servem para várias funções. As seguintes páginas de manual as descrevem:

A interface é configurada no momento da inicialização usando os arquivos /etc/hostname.if(5), onde if é trocado pelo nome completo da sua interface; para o exemplo acima, /etc/hostname.fxp0.

O layout desse arquivo é simples:

família_de_endereços endereço máscara_de_rede broadcast [outras opções]
Mais detalhes sobre o formato desse arquivo podem ser encontrados na página de manual hostname.if(5). Você precisa ler isso para fazer as configurações menos triviais.

Um típico arquivo de configuração de interface, configurado para usar um endereço IPv4, deve se parecer com isto:

$ cat /etc/hostname.fxp0
inet 10.0.0.38 255.255.255.0 NONE

Nesse caso, nós definimos um endereço IPv4 (inet), com o endereço IP 10.0.0.38, uma máscara de sub-rede 255.255.255.0, e não especificamos o endereço broadcast (que nesse caso será 10.0.0.255 por padrão).

Você também pode especificar o tipo de mídia para uma conexão Ethernet; por exemplo, se você quer forçar o modo 100baseTX full-duplex.

inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex

(Obviamente, você nunca deve forçar o modo "full duplex", a menos que ambos os lados da conexão estejam configurados para fazer isso! Na ausência de necessidades especiais, configurações de mídia podem ser excluídas. Um caso mais comum pode ser forçar para 10base-T ou "half duplex" quando sua infraestrutura o requer.)

Ou você talvez queira usar alguns sinalizadores especiais específicos para uma certa interface. O formato do arquivo hostname não deve mudar muito!

$ cat /etc/hostname.vlan0
inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev fxp1

6.2.2 - Gateway padrão

Coloque o IP do seu gateway no arquivo /etc/mygate. Isso permite que seu gateway seja configurado na inicialização. O arquivo é formado por uma linha, com apenas o endereço da máquina que é o gateway:
10.0.0.1
É possível usar um nome simbólico aqui, mas com cuidado: você não pode assumir que o resolvedor está configurado, nem mesmo acessível, até DEPOIS que o gateway padrão estiver configurado. Em outras palavras, é melhor ter um endereço IP ou um objeto definido no arquivo /etc/hosts.

6.2.3 - Resolução DNS

A resolução DNS é controlada pelo arquivo /etc/resolv.conf. Este é um exemplo de arquivo /etc/resolv.conf:
search exemplo.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
Nesse caso, o nome de domínio padrão é exemplo.com, existem dois resolvedores DNS especificados, 125.2.3.4 e 125.2.3.5, e o arquivo /etc/hosts é consultado antes dos resolvedores DNS.

Como acontece na prática com qualquer sistema Unix (e outros não-Unix), há um arquivo /etc/hosts que pode ser usado para especificar sistemas que não estão (ou, se usado com a prioridade "lookup" acima, não são desejados) no sistema DNS formal.

Se você está usando DHCP, talvez queira ler 6.4 - Protocolo de Atribuição Dinâmica de Endereços (DHCP), tomando nota do resolv.conf.tail(5).

6.2.4 - Nome da máquina

Toda máquina Unix possui um nome. No OpenBSD, o nome é especificado como FQDN ("Fully Qualified Domain Name", ou Nome de Domínio Completamente Qualificado) em uma linha no arquivo /etc/myname. Se a máquina é nomeada "puffy" e seu domínio é "exemplo.com", o arquivo contém a linha:
puffy.exemplo.com

6.2.5 - Ativação das mudanças

Aqui, você pode tanto reinicializar quanto executar o script /etc/netstart. Você pode fazer isso simplesmente digitando (como root):
# sh /etc/netstart
writing to routing socket: File exists
add net 127: gateway 127.0.0.1: File exists
writing to routing socket: File exists
add net 224.0.0.0: gateway 127.0.0.1: File exists

Note que alguns erros foram produzidos. Ao executar esse script, você está reconfigurando coisas que já estão configuradas. Por exemplo, algumas rotas que já existem na tabela de roteamento do kernel. Aqui seu sistema deve estar ativo e em funcionamento. Novamente, você pode verificar com o ifconfig(8) para ter certeza que sua interface foi configurada corretamente.

Mesmo que você possa reconfigurar a rede em um sistema OpenBSD sem reinicializar, uma reinicialização é ALTAMENTE recomendada após qualquer reconfiguração significante. A razão para isso é que o ambiente no momento da inicialização é diferente daquele que é quando o sistema está completamente ativo e em funcionamento. Por exemplo, se você especificou um nome simbólico resolvido por DNS em qualquer arquivo, você provavelmente vai perceber que ele está funcionando depois da reconfiguração, mas no momento da inicialização seu resolvedor externo pode não estar disponível, então a configuração falha.

6.2.6 - Verificação das rotas

Você pode verificar suas rotas por meio do netstat(1) ou route(8). Se você está tendo problemas com roteamento, você pode usar o sinalizador -n no route(8), que mostra o endereço IP em vez de fazer uma consulta DNS e mostrar o nome da máquina. Este é um exemplo de visualização das suas tabelas de roteamento usando ambos os programas.
$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            10.0.0.1           UGS         0       86      -  fxp0
127/8              127.0.0.1          UGRS        0        0      -  lo0
127.0.0.1          127.0.0.1          UH          0        0      -  lo0
10.0.0/24          link#1             UC          0        0      -  fxp0
10.0.0.1           aa:0:4:0:81:d      UHL         1        0      -  fxp0
10.0.0.38          127.0.0.1          UGHS        0        0      -  lo0
224/4              127.0.0.1          URS         0        0      -  lo0

Encap:
Source             Port  Destination        Port  Proto SA(Address/SPI/Proto)

$ route show
Routing tables

Internet:
Destination      Gateway            Flags
default          10.0.0.1           UG
127.0.0.0        LOCALHOST          UG
localhost        LOCALHOST          UH
10.0.0.0         link#1             U
10.0.0.1         aa:0:4:0:81:d      UH
10.0.0.38        LOCALHOST          UGH
BASE-ADDRESS.MCA LOCALHOST          U

6.2.7 - Como configurar seu OpenBSD como um gateway

Esta é a informação básica que você precisa para configurar seu OpenBSD como um gateway (também chamado de roteador). Se você está usando o OpenBSD como um roteador na Internet, nós sugerimos que você também leia as instruções abaixo sobre configuração do Filtro de Pacotes, para bloquear tráfego potencialmente malicioso. Também, devido à baixa disponibilidade de endereços IPv4 dos providenciadores de serviços de rede e registros regionais, você talvez queira procurar sobre Tradução de Endereço de Rede (NAT) para obter informações a fim de economizar seu endereçamento IP.

O kernel GENERIC já é configurado para permitir o roteamento IP, mas precisa ser ativado. Você deve fazer isso usando o utilitário sysctl(8). Para mudar isso permanentemente, você deve editar o arquivo /etc/sysctl.conf e adicionar a seguinte linha:

net.inet.ip.forwarding=1

Para fazer essa mudança sem reinicializar, você deve usar diretamente o sysctl(8). Lembre-se que essa mudança não vai mais existir após a reinicialização, e que ela precisa ser executada como root.

# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1

Agora modifique as rotas nas outras máquinas, em ambos os lados. Existem muitos usos possíveis do OpenBSD como um roteador ao usar softwares tais como o próprio OpenBGPD do OpenBSD, routed(8), mrtd, zebra e quagga. O OpenBSD tem o suporte na coleção de portes para zebra, quagga e o mrtd. O OpenBGPD e o routed são instalados como parte do sistema base. O OpenBSD suporta diferentes interfaces T1, HSSI, ATM, FDDI, Ethernet e serial (PPP/SLIP).

6.2.8 - Configuração de apelidos em uma interface

O OpenBSD possui um mecanismo simples para configurar apelidos de IP em uma interface. Para fazer isso, simplesmente edite o arquivo /etc/hostname.<if>. O arquivo é lido no momento da inicialização pelo script /etc/netstart(8), o qual faz parte da hierarquia de inicialização rc. Para este exemplo, nós assumimos que o usuário tem uma interface dc0 e está na rede 192.168.0.0. Outra informação importante:

Algumas notas sobre apelidos. No OpenBSD você usa somente o nome da interface. Não existem diferenças entre o primeiro e o segundo apelido. Diferentemente de alguns outros sistemas operacionais, o OpenBSD não se refere aos apelidos como dc0:0, dc0:1. Se você está fazendo referência a um apelido de endereço IP com o ifconfig, ou adicionando um apelido, tenha certeza de utilizar a linha de comando "ifconfig int alias" em vez de apenas "ifconfig int". Você pode excluir apelidos com "ifconfig int delete".

Assumindo que você está usando múltiplos endereços IP que estão na mesma sub-rede IP com os apelidos, sua configuração de máscara de rede para cada apelido torna-se 255.255.255.255. Eles não precisam seguir a máscara de rede do primeiro IP atribuído à interface. Neste exemplo, /etc/hostname.dc0, dois apelidos são adicionados ao dispositivo dc0, que foi configurado com o endereço 192.168.0.2 e a máscara de rede 255.255.255.0.

# cat /etc/hostname.dc0
inet 192.168.0.2 255.255.255.0 NONE media 100baseTX
inet alias 192.168.0.3 255.255.255.255
inet alias 192.168.0.4 255.255.255.255

Depois desse arquivo ser criado, é preciso apenas uma reinicialização para ele ter efeito. Você pode, no entanto, ativar os apelidos usando manualmente o utilitário ifconfig(8). Para ativar o primeiro apelido você deve usar o comando:

# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
(novamente, uma reinicialização é recomendada para ter certeza de que você especificou a configuração que você esperava!)

Para ver esses apelidos, você deve usar o comando:

$ ifconfig -A
dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
        media: Ethernet manual
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3

6.3 - Como filtrar pacotes e usar um firewall no OpenBSD?

O "Packet Filter" (Filtro de Pacotes; referenciado aqui como PF) é o sistema do OpenBSD para filtragem do tráfego IP e para Tradução de Endereço de Rede (NAT). O PF também é capaz de normalizar e condicionar tráfego IP, e providenciar controle de largura de banda e priorização de pacotes, e pode ser usado para criar firewalls poderosos e flexíveis. Ele está descrito no Guia para usuários do PF.

6.4 - Protocolo de Atribuição Dinâmica de Endereços (DHCP)

O Protocolo de Atribuição Dinâmica de Endereços (DHCP - "Dynamic Host Configuration Protocol") permite a configuração automática de interfaces de rede. O OpenBSD pode ser um servidor DHCP (configurando outras máquinas), um cliente DHCP (configurado por outra máquina) e, em alguns casos, pode ser ambos.

6.4.1 - Cliente DHCP

Para usar o cliente DHCP dhclient(8) incluído no OpenBSD, edite /etc/hostname.xl0 (assumindo que sua interface Ethernet principal é xl0. As suas podem ser ep0 ou fxp0 ou outra coisa). Tudo que você precisa colocar no arquivo hostname é 'dhcp':

# echo dhcp > /etc/hostname.xl0

Isso faz com que o OpenBSD inicie automaticamente o cliente DHCP na inicialização. O OpenBSD pega seu endereço IP, seu gateway padrão e seus servidores DNS com o servidor DHCP.

Se você deseja iniciar o cliente DHCP a partir da linha de comando, tenha certeza de que /etc/dhclient.conf existe, então digite o comando:

# dhclient fxp0

Onde fxp0 é a interface que você quer configurar por DHCP.

Não importa como você iniciou o cliente DHCP, você pode editar o arquivo /etc/dhclient.conf para não atualizar seu DNS, de acordo com a intenção do servidor dhcp, descomentando as linhas 'request' (elas são exemplos da configuração padrão, mas você precisa descomentá-las para sobrescrever os padrões do dhclient.)

request subnet-mask, broadcast-address, time-offset, routers,
      domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;

e então remova domain-name-servers. Naturalmente, você talvez queira remover host-name, ou outras configurações também.

Ao mudar opções em seu arquivo dhclient.conf(5), você está dizendo para o cliente DHCP como construir seu arquivo resolv.conf(5). O cliente DHCP sobrescreve qualquer informação que você tem atualmente no resolv.conf(5) com a informação que ele recebeu do servidor DHCP. Então, você perde quaisquer mudanças que você fez manualmente no resolv.conf.

Há dois mecanismos disponíveis para prevenir isso:

Imagine que você está usando DHCP, mas você quer anexar lookup file bind ao arquivo resolv.conf(5) criado pelo dhclient(8). Não existe opção para isso no dhclient.conf, então você deve usar o resolv.conf.tail para guardar isso.

# echo "lookup file bind" > /etc/resolv.conf.tail
Agora seu resolv.conf(5) deve incluir "lookup file bind" no final.
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind

6.4.2 - Servidor DHCP

Se você quer usar o OpenBSD como um servidor DHCP dhcpd(8), edite o /etc/rc.conf.local a fim de colocar nele a linha dhcpd_flags="interface", trocando interface pela lista de interfaces que o dhcpd(8) deve escutar; por exemplo:

     # echo 'dhcpd_flags="xl1 xl2 xl3"' >>/etc/rc.conf.local

Então edite o /etc/dhcpd.conf. As opções são autoexplicativas.

        option  domain-name "exemplo.com";
        option  domain-name-servers 192.168.1.3, 192.168.1.5;

        subnet 192.168.1.0 netmask 255.255.255.0 {
                option routers 192.168.1.1;

                range 192.168.1.32 192.168.1.127;
        }

Isso diz aos seus clientes DHCP que o domínio para anexar as requisições DNS é exemplo.com (assim, se um usuário executa o comando 'telnet joe', ele será enviado para joe.exemplo.com). Os clientes usam os servidores DNS 192.168.1.3 e 192.168.1.5. Para as máquinas que estão na mesma rede correspondente à interface do servidor OpenBSD, o qual está na faixa 192.168.1.0/24, será atribuído a elas endereços IP entre 192.168.1.32 e 192.168.1.127. O gateway padrão é 192.168.1.1.

Se você deseja iniciar o dhcpd(8) a partir da linha de comando, depois de editar o /etc/dhcpd.conf, digite:

     # touch /var/db/dhcpd.leases
     # dhcpd fxp0

A linha touch é necessária para criar um arquivo dhcpd.leases vazio antes do dhcpd(8) poder iniciar. Os scripts de inicialização do OpenBSD criam esse arquivo na inicialização se for necessário, mas se você está inicializando o dhcpd(8) manualmente, você deve criá-lo primeiro. A fxp0 é a interface que você quer que responda às requisições DHCP.

Se você está servindo DHCP para máquinas executando Windows, você talvez queira que o dhcpd(8) dê ao cliente um endereço de servidor 'WINS'. Para fazer isso acontecer, apenas adicione a seguinte linha no seu /etc/dhcpd.conf:

     option    netbios-name-servers    192.168.92.55;

(onde 192.168.92.55 é o IP do servidor Windows ou Samba.) Veja o manual dhcp-options(5) se seus clientes DHCP precisam de mais opções.

6.5 - PPP

O Protocolo Ponto a Ponto (PPP - "Point to Point Protocol") é geralmente usado para criar uma conexão com o seu provedor de acesso à Internet através de um modem discado. O OpenBSD possui dois jeitos de se fazer isso:

Tanto ppp quando pppd executam funções similares, de diferentes formas. O pppd trabalha no kernel com o driver ppp(4), e o ppp trabalha no espaço de usuário utilizando o tun(4). Este documento trata apenas do daemon PPP no espaço de usuário, que é mais fácil de corrigir problemas e interagir com ele. Para começar, você precisa de algumas informações simples sobre seu provedor de acesso à Internet. Esta é uma lista de informações úteis que você deve ter.

Certas opções não são obrigatórias, mas são de grande ajuda para configurar o ppp. O daemon PPP do espaço de usuário usa o arquivo /etc/ppp/ppp.conf como seu arquivo de configuração. Há muitos arquivos úteis em /etc/ppp, que contêm diferentes configurações para as mais diversas situações. Você deve dar uma olhada nesse diretório.

Configuração Inicial - para o PPP(8)

A Configuração Inicial do daemon PPP consiste na edição do arquivo /etc/ppp/ppp.conf. Esse arquivo não existe por padrão, mas há um arquivo /etc/ppp/ppp.conf.sample, no qual você pode se basear para criar seu próprio arquivo ppp.conf. Aqui começarei com uma configuração simples e geralmente a mais usada. Este é um arquivo ppp.conf curto, que simplesmente define alguns valores:

default:
  set log Phase Chat LCP IPCP CCP tun command     
  set device /dev/cua01                           
  set speed 115200     
  set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"

A seção definida pela etiqueta default: será executada a cada vez que é realizado um requerimento para uma conexão. Nessa seção nós configuramos as informações importantes. Com "set log" nós configuramos os níveis de registro de dados. Isso pode ser alterado; para mais informação sobre a configuração dos níveis de registro de dados, consulte a página de manual ppp(8). Nosso dispositivo é configurado com "set device". Esse é o dispositivo onde o modem está ligado. Nesse exemplo, o modem está na porta COM 2. Então a porta COM 1 deve ser /dev/cua00. Com "set speed" nós configuramos a velocidade de nossa conexão discada, e com "set dial" nós configuramos os parâmetros da discada. Com isso nós podemos mudar o tempo de expiração da conexão, etc. Essa linha não deve variar muito.

Agora nós podemos continuar e configurar as informações específicas do nosso provedor de acesso. Nós faremos isso adicionando outra etiqueta abaixo da nossa seção default:. Você pode dar o nome que quiser a essa etiqueta - mas é mais fácil usar o nome do provedor. Aqui eu usarei myisp: como a opção que referencia nosso provedor. Esta é uma configuração simples incorporando tudo que nós precisamos para conectar:

myisp:
  set phone 1234567   
  set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp"
  set timeout 120   
  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
  add default HISADDR 
  enable dns

Aqui nós configuramos todas as informações essenciais para aquele provedor específico. A primeira opção, "set phone", configura o número de telefone do provedor. A "set login" configura nossas opções de início de sessão. Nosso tempo de expiração ("timeout") está configurado para 5; isso significa que nós iremos interromper nossa tentativa de início de sessão após 5 segundos se nenhum carregador for encontrado. Caso contrário, ele espera pelo "login:" ser mandado, para então enviar seu nome de usuário e senha.

Nesse exemplo, nosso nome de usuário é "ppp" e a senha é "ppp". Esses valores precisam ser mudados. A linha "set timeout" configura o tempo de expiração de todo o processo de conexão para 120 segundos. A linha "set ifaddr" é um pouco complicada. Aqui há uma explicação mais extensa sobre ela:

set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0

Nós configuramos a linha acima com o formato "set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeraddr]]]] ". Assim, o primeiro IP determina o que nós queremos como nosso IP. Se você tem um IP estático, você define ele aqui. No nosso exemplo usamos /0, que indica que nenhum bit desse endereço IP precisa corresponder, e a coisa toda pode ser substituída. O segundo IP especificado é o que nós esperamos como endereço IP do nosso provedor. Se você conhece este, especifique. Na nossa linha, nós não sabemos qual o IP será atribuído, então deixamos que nosso provedor nos diga. A terceira opção é nossa máscara de rede, aqui definida como 255.255.255.0. Se "triggeraddr" é especificado, ele é usado no lugar de "myaddr" na negociação IPCP inicial. No entanto, somente um endereço na faixa do "myaddr" é aceito. Isso é útil quando negociamos com algumas implementações PPP que não atribuem um número IP, a menos que a conexão faça uma requisição ``0.0.0.0''.

A próxima opção, "add default HISADDR", configura nossa rota padrão com o endereço IP do provedor. Essa entrada permite a configuração automática da nossa rota padrão em caso de mudança do endereço IP. "enable dns" é utilizado a fim de recuperar a lista de servidores DNS do provedor. NÃO faça isso se você está executando um servidor DNS local; o ppp logra seu uso introduzindo algumas linhas nameserver no arquivo /etc/resolv.conf.

No lugar dos tradicionais métodos de início de sessão, muitos provedores de acesso agora usam tanto autenticação CHAP quanto PAP. Nesse caso, note que a configuração será um pouco diferente:

myisp:
  set phone 1234567   
  set authname ppp
  set authkey ppp
  set login
  set timeout 120   
  set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
  add default HISADDR 
  enable dns

No exemplo acima, nós especificamos nosso nome de usuário (ppp) e a senha (ppp) usando authname e authkey, respectivamente. Não há necessidade de especificar o tipo de autenticação CHAP ou PAP usada - isso é negociado automaticamente. "set login" significa simplesmente tentar se conectar com o nome de usuário e senha previamente especificados.

Como usar o PPP(8)

Agora que nós temos o arquivo ppp.conf configurado, podemos tentar fazer uma conexão com o nosso provedor. Explicarei alguns argumentos comuns usados com o ppp:

Se as opções acima não funcionarem, tente executar /usr/sbin/ppp sem nenhuma opção - ele executa o ppp em modo interativo. As opções podem ser especificadas uma por uma para verificar erros ou outros problemas. Com a configuração descrita acima, o ppp registra dados em /var/log/ppp.log. Esse registro de dados, como também a página de manual, contém informações úteis.

Outras opções do ppp(8)

Em algumas situações, você talvez queira que comandos sejam executados quando sua conexão é feita ou quando é derrubada. Existem dois arquivos que você pode criar para essas situações: /etc/ppp/ppp.linkup e /etc/ppp/ppp.linkdown. Configurações de exemplo podem ser vistas aqui:

Variações do ppp(8)

Muitos provedores de acesso à Internet agora oferecem serviços xDSL, que são mais rápidos que os métodos discados tradicionais. Isso inclui variantes como ADSL e SDSL. Embora nenhum discador físico seja usado, a conexão é baseada no protocolo ponto a ponto. Exemplos incluem:

PPPoE/PPPoA

O Protocolo Ponto a Ponto sobre Ethernet (PPPoE - "Point to Point Protocol over Ethernet") é um método para enviar pacotes PPP em frames Ethernet. O Protocolo Ponto a Ponto sobre ATM (PPPoA - "Point to Point Protocol over ATM") é usado tipicamente em redes ATM, iguais àquelas encontradas no Reino Unido e na Bélgica.

Normalmente, isso significa que você quer estabelecer uma conexão com seu provedor usando uma placa Ethernet padrão e um modem DSL-Ethernet (o inverso dos modems USB).

Se você possui um modem compatível com PPPoE/PPPoA, é possível configurar o modem para fazer a conexão. Alternativamente, se o modem tem um modo "bridge", é possível ativar este a fim de fazer o modem "transitar" os pacotes para uma máquina executando o software PPPoE (veja a seguir).

A interface principal de software PPPoE/PPPoA no OpenBSD é o pppoe(8), que tem uma implementação no espaço de usuário (da mesma maneira que descrevemos o ppp(8), acima). Uma implementação do PPPoE no kernel, pppoe(4), foi incorporada no OpenBSD.

PPTP

O Protocolo de Tunelamento Ponto a Ponto (PPTP - "Point to Point Tunneling Protocol") é um protocolo proprietário da Microsoft. Um cliente pptp faz a interface com o pppd(8) e é capaz de se conectar a Redes Virtuais Privadas (VPN - "Virtual Private Network") baseadas no PPTP, utilizadas por alguns provedores a cabo e xDSL. O software pptp precisa ser instalado utilizando pacotes ou portes. Mais instruções a respeito da configuração e uso do pptp estão disponíveis na página de manual que é instalada junto com o pacote pptp.

6.6 - Otimização dos parâmetros de rede

Um objetivo do OpenBSD é ter um sistema que Simplesmente Funciona para a vasta maioria de nossos usuários. Modificar coisas que você não entende acaba resultando mais comumente na quebra do sistema do que na melhoria de seu desempenho. Sempre comece a partir das configurações padrão, e ajuste somente coisas com as quais você está realmente tendo problemas.

POUQUÍSSIMAS pessoas precisam ajustar os parâmetros de rede!

6.6.1 - Eu não quero que o kernel aloque dinamicamente uma certa porta

Há um comando sysctl para isso também. Direto da página de manual sysctl(8):

Para definir a lista de portas TCP reservadas que não devem ser alocadas
dinamicamente pelo kernel:

      # sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871

Isso pode ser utilizado para evitar que daemons roubem uma porta
específica que um outro programa necessita para funcionar. Os elementos
da lista podem ser separados por vírgulas e/ou espaço em branco.

Também é possível adicionar ou remover portas da lista atual:

      # sysctl net.inet.tcp.baddynamic=+748
      # sysctl net.inet.tcp.baddynamic=-871

6.7 - Utilização simples do NFS

NFS ("Network File System", ou Sistema de Arquivos em Rede) é usado para compartilhar um sistema de arquivos através de uma rede. Você deve ler algumas páginas de manual antes de tentar configurar um servidor NFS:

Esta seção detalha as etapas para uma configuração NFS simples. Este exemplo detalha um servidor em uma LAN, com clientes acessando o NFS dentro dela. Nesta seção não será abordado sobre a segurança do NFS. Nós assumimos que você já configurou seu filtro de pacotes (PF) ou outra proteção do tipo firewall para prevenir acesso externo. Se você está liberando o acesso externo para seu servidor NFS, e você tem algum tipo de dado sensível armazenado nele, nós recomendamos fortemente que você use IPsec. Caso contrário, pessoas podem potencialmente ver o que faz parte do seu tráfego NFS. Qualquer um pode usurpar o endereço IP que você está liberando em seu servidor NFS. Vários tipos de ataques podem ser feitos. Quando configurado apropriadamente, o IPsec oferece uma proteção contra esses tipos de ataques.

Configuração de um servidor NFS

Estes serviços precisam estar ativos e em execução no servidor:

Por padrão, cada um destes está desativado no OpenBSD. Adicione as seguintes linhas no rc.conf.local(8) para ativá-los:

portmap=YES
nfs_server=YES

O próximo passo é configurar a lista de sistemas de arquivos que estarão disponíveis para os clientes montarem.

Neste exemplo, nós temos um servidor com o ip 10.0.0.1. Este servidor servirá NFS somente para os clientes dentro da rede. Toda esta parte é configurada no arquivo /etc/exports. Esse arquivo lista quais sistemas de arquivos você deseja ter acesso através do NFS e define quem pode acessá-los. Há muitas opções que você pode usar no /etc/exports, e é melhor que você leia a página de manual exports(5). Para nosso exemplo de servidor, temos que configurar um arquivo exports que se parece com este:

#
# Base de dados do NFS exports
# Veja exports(5) para mais informação.  Seja muito cuidadoso, uma má
# configuração deste arquivo pode fazer com que seu sistema de arquivos
# se torne legível para todo o mundo.
/work -alldirs -ro -network=10.0.0 -mask=255.255.255.0

Isso significa que o sistema de arquivos /work local será disponibilizado por NFS. A opção -alldirs determina que os clientes podem montar em qualquer ponto dentro do ponto de montagem /work, como também o próprio /work. Por exemplo, se existe um diretório chamado /work/monday, clientes podem montar /work (e ter acesso a todos os arquivos/diretórios abaixo daquele diretório) ou eles podem montar /work/monday e ter acesso apenas aos arquivos/diretórios dele. A opção -ro determina que os clientes somente ganharão acesso para leitura ("read-only"). Os dois últimos argumentos determinam que somente os clientes dentro da rede 10.0.0.0 com a máscara de 255.255.255.0 estão autorizados a montar esse sistema de arquivos. Isso é importante para alguns servidores que são acessados por redes diferentes.

Uma outra nota de segurança: não adicione um sistema de arquivos no /etc/exports sem uma espécie de lista de máquinas permitidas. Sem uma lista de máquinas que podem montar um diretório em particular, será possível a qualquer um que possa alcançar seu servidor, montar seus diretórios NFS exportados.

Agora você pode iniciar os serviços do servidor. Você pode tanto reinicializar (depois de ativá-los com as instruções acima) ou rodá-los manualmente.

# /usr/sbin/portmap
# echo -n >/var/db/mountdtab
# /sbin/mountd
# /sbin/nfsd -tun 4

Os argumentos passados para o nfsd ativam as conexões TCP (-t) e UDP (-u), e ativam 4 instâncias (-n) de execução do nfsd. Você deve definir um número apropriado de instâncias do servidor NFS para controlar o número máximo de requisições simultâneas que você quer servir.

Você agora está pronto para montar os sistemas de arquivos exportados a partir do(s) cliente(s).

Lembre-se: se você fez mudanças no /etc/exports enquanto o NFS estava em execução, você precisa fazer o mountd saber disso! Envie um sinal HUP para o mountd e as mudanças terão efeito.

# kill -HUP `cat /var/run/mountd.pid`

Montagem de sistemas de arquivos NFS

Sistemas de arquivos NFS podem ser montados a partir de um cliente, sem a necessidade de ativar quaisquer serviços ou daemons. Eles podem ser montados da mesma maneira que outro sistema de arquivos.

Sistemas de arquivos NFS devem ser montados através do mount(8) ou, mais especificamente, mount_nfs(8). Para montar um sistema de arquivos /work na máquina 10.0.0.1 em um sistema de arquivos /mnt local, faça isto (note que você não precisa usar um endereço IP: o mount resolve nomes de máquinas):

# mount -t nfs 10.0.0.1:/work /mnt

Para ter um sistema de arquivos montado na inicialização, adicione algo semelhante a isto no /etc/fstab:

10.0.0.1:/work /mnt nfs rw 0 0

É importante que você use 0 0 no final dessa linha, assim seu computador não vai tentar executar o fsck no sistema de arquivos NFS na inicialização. As outras opções de segurança padrão, tais como noexec, nodev e nosuid também devem ser usadas quando aplicáveis. Por exemplo:

10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0

Dessa forma, nenhum dispositivo ou programas setuid no servidor NFS pode subverter as medidas de segurança no cliente NFS. Se você não está montando programas para executar no cliente NFS, adicione noexec nessa lista.

No acesso a um ponto de montagem NFS como usuário root, o servidor automaticamente mapeia o acesso do root para o nome de usuário "nobody" e grupo "nobody". Isso é importante para saber quando considerar as permissões de arquivo. Por exemplo, pegue um arquivo com estas permissões:

-rw-------    1 root     wheel           0 Dec 31 03:00 _daily.B20143

Se esse arquivo estava sendo compartilhado através do NFS e o usuário root tentasse acessá-lo, o acesso seria negado. Isso é porque o servidor usa a credencial do usuário "nobody" quando o root tenta acessar o arquivo. Desde que o usuário nobody não tem permissões de acessar o arquivo, o acesso é negado.

O usuário e o grupo que o root está mapeado são configurados através do arquivo exports(5) no servidor NFS.

Verificação de estatísticas no NFS

Uma coisa a ser feita para assegurar que o NFS está operando corretamente é verificar se todos os daemons estão apropriadamente registrados com o RPC. Para fazer isso, use o rpcinfo(8).

$ rpcinfo -p 10.0.0.1
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    633  mountd
    100005    3   udp    633  mountd
    100005    1   tcp    916  mountd
    100005    3   tcp    916  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

Durante o uso normal, existem alguns outros utilitários que permitem que você veja o que está acontecendo com o NFS. Um deles é o showmount(8), que permite que você visualize o que está montado atualmente e quem é o responsável pela montagem. Existe também o nfsstat(1), que mostra mais mensagens de estatísticas. Para usar o showmount(8), tente /usr/bin/showmount -a máquina. Por exemplo:

$ /usr/bin/showmount -a 10.0.0.1
All mount points on 10.0.0.1:
10.0.0.37:/work

Essa saída mostra que o cliente 10.0.0.37 está com o diretório /work montado, diretório este exportado a partir do servidor no endereço 10.0.0.1.

6.9 - Configuração de uma interface de ponte ("bridge") no OpenBSD

Uma ponte ("bridge") é um link entre duas (ou mais) redes separadas. Ao contrário de um roteador, os pacotes são transferidos através de uma ponte de maneira "invisível" -- os dois segmentos de rede parecem ser, logicamente, um único segmento para os nós em ambos os lados da ponte. A ponte somente transfere pacotes que passam de um segmento para outro, então, além de outras coisas, ela fornece um modo fácil para reduzir o tráfego em uma rede complexa e ainda permite a qualquer nó acessar qualquer outro nó quando necessário.

Note que por causa dessa natureza "invisível", uma interface que faz parte de uma ponte pode ou não ter um endereço IP próprio. Se esse é o caso, a interface tem dois modos de operação, um como parte de uma ponte e o outro comporta-se como uma interface normal. Se nenhuma das interfaces têm um endereço IP, a ponte passa o tráfego de rede, mas não é administrada externamente (pode ser uma funcionalidade útil).

Exemplo de aplicação de uma ponte

Um dos meus racks possui vários sistemas antigos, nenhum deles têm uma placa de rede 10BASE-TX interna. Enquanto todos eles têm um conector AUI ou AAUI, meu estoque de transmissores está limitado a cabos coaxiais. Uma das máquinas nesse rack é um servidor de acesso a terminal baseado no OpenBSD, que está sempre ligado e conectado em uma rede de alta velocidade. Adicionar uma segunda placa com uma porta coaxial permitirá a utilização dessa máquina como uma ponte para a rede coaxial.

O sistema tem duas placas de rede no momento, uma Intel EtherExpress/100 (fxp0) e uma 3c590-Combo (ep0) para a porta coaxial. fxp0 é o link para o resto da minha rede e terá um endereço IP, ep0 será usada somente para a ponte e não terá um endereço IP. As máquinas ligadas ao segmento coaxial se comunicarão como se elas estivessem no resto da minha rede. Então, como nós fazemos para isso funcionar?

O arquivo hostname.fxp0 contém a configuração para a placa fxp0. Essa máquina é configurada usando DHCP, então seu arquivo se parece com isto:

$ cat /etc/hostname.fxp0
dhcp NONE NONE NONE

Nenhuma surpresa aqui.

Como você pode imaginar, a configuração da placa ep0 é um pouco diferente:

$ cat /etc/hostname.ep0
up media 10base2

Aqui, nós estamos instruindo o sistema a ativar essa interface usando o ifconfig(8) e configurar como 10BASE-2 (coaxial). Um endereço IP, ou outra informação similar, não precisa ser especificado para essa interface. As opções possíveis para a placa ep estão detalhadas em sua página de manual.

Agora nós precisamos configurar a ponte. Pontes são inicializadas pela existência de um arquivo do tipo hostname.bridge0. Este é um exemplo para a minha situação:

$ cat /etc/hostname.bridge0
add fxp0
add ep0
up

Isso está dizendo para configurar uma ponte constituída de duas interfaces, fxp0 e ep0, e ativá-las. A ordem em que as placas estão listadas é importante? Não, lembre-se que uma ponte é muito simétrica -- pacotes fluem entrando e saindo em ambas as direções.

É isso! Reinicialize e você agora tem uma ponte funcional.

Filtragem em uma ponte

Enquanto existem certos usos para uma ponte simples como essa, é comum que você queira FAZER alguma coisa com os pacotes que estão atravessando sua ponte. Como você deve ter imaginado, o Packet Filter pode ser usado para restringir o tráfego que atravessa a sua ponte.

Mantenha em mente que, pela natureza de uma ponte, o mesmo fluxo de dados atravessa ambas as interfaces, isso significa que você somente precisa filtrar em uma interface. Sua instrução "Pass all" padrão deve se parecer com o exemplo seguinte:

pass in  on ep0  all
pass out on ep0  all
pass in  on fxp0 all
pass out on fxp0 all

Agora, eu quero filtrar o tráfego que chega até essas máquinas velhas, eu quero somente tráfego Web e SSH alcançando-as. Nesse caso, nós estamos autorizando todo tráfego que entra e sai na interface ep0, mas nós filtramos na interface fxp0 e usamos keep state para cuidar do tráfego de retorno:

# Autoriza o tráfego que entra e sai pela ep0
pass in quick on ep0 all
pass out quick on ep0 all

# Bloqueia todo o tráfego na fxp0
block in  on fxp0 all
block out on fxp0 all

pass in quick on fxp0 proto tcp from any to any port {22, 80} \
     flags S/SA keep state

Note que esse conjunto de regras bloqueia tudo (exceto as requisições entrantes de HTTP e SSH), inclusive ver a máquina que faz a ponte ou quaisquer outros nós "atrás" dela. Outros resultados podem ser obtidos filtrando a outra interface.

Para monitorar e controlar a ponte que você criou use o comando ifconfig(8), que pode também ser usado para criar uma ponte depois da inicialização.

Dicas sobre pontes

6.10 - Como inicializar usando PXE? (i386, amd64)

PXE ("Preboot Execution Environment", ou Ambiente de Execução Antes da Inicialização) permite a inicialização de um computador através de uma rede em vez de um disco rígido, um disquete ou um CD-ROM. A tecnologia foi originalmente desenvolvida pela Intel, mas agora é suportada pela maioria das placas de rede e fabricantes de computadores. Note que existem diferentes protocolos de inicialização a partir da rede, PXE é relativamente recente. Tradicionalmente, a inicialização com PXE é feita usando ROMs presentes na placa de rede ou placa-mãe do sistema, mas disquetes que permitem a inicialização PXE também estão disponíveis a partir de várias fontes. Muitas ROMs e placas de rede antigas suportam a inicialização através da rede, mas NÃO suportam PXE; um sistema OpenBSD/i386 ou amd64 equipado com esses controladores não pode atualmente ser inicializado através de uma rede.

Como a inicialização PXE funciona?

Primeiramente, é necessário saber como o OpenBSD inicializa nas plataformas i386 e amd64. Na inicialização, a interface compatível com PXE emite uma requisição DHCP através da rede. O servidor DHCP atribui ao adaptador um endereço IP e um nome de arquivo para ser baixado de um servidor tftp(1) e ser executado. Esse arquivo então conduz o resto do processo de inicialização. Para o OpenBSD, o arquivo é o pxeboot, que toma o lugar do arquivo boot(8) padrão. O pxeboot(8) é então capaz de carregar e executar um kernel (como bsd ou bsd.rd) a partir de um servidor tftp(1).

Como se faz isso?

O primeiro, e óbvio, passo é você ter um computador ou um adaptador de rede que suporte PXE. Algumas documentações dizem que todas as placas de rede e computadores modernos são compatíveis com PXE, mas isso é simplesmente falso -- muitos sistemas de baixo custo não incluem ROMs PXE ou usam um protocolo antigo de inicialização através da rede. Você também precisa configurar corretamente o servidor DHCP e o servidor TFTP.

Assumindo uma máquina OpenBSD como a fonte dos arquivos de inicialização (isso não é obrigatório), seu arquivo dhcpd.conf do servidor DHCP precisa ter a seguinte linha:

    filename "pxeboot";
a fim de oferecer esse arquivo de inicialização a uma estação de trabalho. Por exemplo:
    shared-network LOCAL-NET {
            option  domain-name "exemplo.com";
            option  domain-name-servers 192.168.1.3, 192.168.1.5;

            subnet 192.168.1.0 netmask 255.255.255.0 {
                    option routers 192.168.1.1;
                    filename "pxeboot";
                    range 192.168.1.32 192.168.1.127;
                    default-lease-time 86400;
                    max-lease-time 90000;
            }
    }

Você também tem que ativar o daemon tftpd(8). Isso é tipicamente feito através do inetd(8). A instalação padrão do OpenBSD tem uma linha de exemplo em inetd.conf que deve satisfazer-lhe:

    #tftp  dgram   udp  wait  root  /usr/libexec/tftpd   tftpd -s /tftpboot
Simplesmente retire o caractere '#' e envie ao inetd(8) um sinal -HUP para recarregar o /etc/inetd.conf. O tftpd(8) serve arquivos de um diretório particular, no caso dessa linha o diretório é /tftpboot, que nós vamos usar neste exemplo. Obviamente, esse diretório precisa ser criado e deve conter os arquivos necessários. Tipicamente, você terá somente alguns arquivos para a inicialização PXE: Note que /etc/boot.conf somente é necessário se o kernel que você deseja inicializar não tem o nome bsd, ou outros valores padrões do pxeboot que não são aqueles que você precisa (por exemplo, você deseja usar um console serial). Você pode testar seu servidor tftpd(8) usando o cliente tftp(1) para ter certeza de que você pode baixar os arquivos necessários.

Quando seus servidores DHCP e TFTP estiverem em execução, você está pronto para tentar isto. Você tem que ativar a inicialização PXE em seu sistema ou placa de rede; consulte a documentação do seu sistema. Uma vez configurado, você deve ver algo similar a isto:

    Intel UNDI, PXE-2.0 (build 067)
    Copyright (C) 1997,1998 Intel Corporation

    For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420)

    DHCP MAC ADDR: 00 E0 C5 C8 CF E1
    CLIENT IP: 192.168.1.76  MASK: 255.255.255.0  DHCP IP: 192.168.1.252
    GATEWAY IP: 192.168.1.1
    probing: pc0 com0 com1 apm pxe![2.1] mem[540k 28m a20=on]
    disk: hd0*
    net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252
    >> OpenBSD/i386 PXEBOOT 2.03
    boot>
Neste ponto, você tem o prompt de inicialização padrão do OpenBSD. Se você simplesmente digitar "bsd.rd" aqui, você baixa o arquivo bsd.rd do servidor TFTP.
    >> OpenBSD/i386 PXEBOOT 2.03
    boot> bsd.rd
    booting tftp:bsd.rd: 4375152+733120 [58+122112+105468]=0x516d04
    entry point at 0x100120

    Copyright (c) 1982, 1986, 1989, 1991, 1993
            The Regents of the University of California.  All rights reserved.

    Copyright (c) 1995-2010 OpenBSD.  All rights reserved.  http://www.OpenBSD.org

    OpenBSD 4.8 (RAMDISK_CD) #89: Mon Aug 16 09:24:20 MDT 2010
      ...
O kernel de instalação bsd.rd agora continua a inicialização.

É possível inicializar outro kernel, além do bsd.rd, usando PXE?

Sim, embora que com as ferramentas presentes no OpenBSD, a inicialização PXE tem primariamente o propósito de instalar o sistema operacional.

6.11 - O Protocolo de Redundância de Endereço Comum (CARP)

6.11.1 - O que é CARP e como ele funciona?

CARP ("Common Address Redundancy Protocol", ou Protocolo de Redundância de Endereço Comum) é uma ferramenta para ajudar a atingir a redundância do sistema, com múltiplos computadores criando uma única interface de rede virtual entre eles, assim se uma máquina falha, uma outra pode responder no lugar e/ou liberar um grau de carga, compartilhando-a entre os sistemas. CARP é um aperfeiçoamento do VRRP ("Virtual Router Redundancy Protocol", ou Protocolo de Redundância de Roteador Virtual) padrão. Ele foi desenvolvido depois que o VRRP foi considerado como não suficientemente livre por causa de patentes da Cisco. Para mais informação sobre a origem do CARP e os problemas legais a respeito do VRRP, por favor visite esta página.

Para evitar problemas legais, Ryan McBride (com a ajuda de Michael Shalayeff, Marco Pfatschbacher e Markus Friedl) projetaram o CARP para ser fundamentalmente diferente. A inclusão de criptografia é a mudança mais visível, mas é apenas uma de muitas.

Como ele funciona? CARP é um protocolo "multicast". Ele agrupa vários computadores reais dentro de um ou mais endereços virtuais. Um destes é o mestre e responde todos os pacotes destinados ao grupo, os outros sistemas se comportam como "hot spares" (substitutos automáticos do mestre). Não importa qual é o IP ou endereço MAC da interface física local, pacotes enviados para o endereço CARP são retornados com as informações CARP.

Em intervalos programados, o mestre avisa sua operação através da porta IP 112. Se o mestre fica offline, os outros sistemas no grupo CARP são avisados. A máquina que está ativada para anunciar com mais frequência torna-se o novo mestre. Quando o sistema principal é reconectado, ele se torna por padrão uma máquina "backup", mas se for desejável que uma máquina seja o mestre sempre que possível (por exemplo, uma máquina é um Sun Fire V120 rápido, e as outras são SPARCstation IPCs, comparativamente mais lentas), você também pode configurá-la para isso.

Enquanto o uso de hardware de alta disponibilidade e tolerante a faltas minimiza a necessidade do CARP, isso não descarta sua utilidade. Não existe hardware tolerante a faltas que é capaz de ajudar se alguém desconecta o cabo de força, ou se o seu administrador de sistemas digita reboot na janela errada. CARP também torna o processo de aplicação de correções e reinicialização fácil para o administrador e transparente para os usuários, é fácil testar uma atualização de software ou hardware: se não funcionar, você pode deixar o trabalho para o resto do grupo até que o problema seja resolvido.

Existem, no entanto, situações nas quais o CARP não pode ajudar. O projeto do CARP não requer que os membros de um grupo estejam na mesma sub-rede física com um endereço IP estático, embora que com a introdução da diretiva carpdev, não há mais a necessidade de um endereço IP nas interfaces físicas. Similarmente, serviços que requerem conexão constante com o servidor (como SSH ou IRC) não serão transferidos de maneira transparente para o outro sistema, nesse caso o CARP pode ajudar minimizando o tempo desconectado. O CARP sozinho não sincroniza os dados entre as aplicações, isso deve ser feito através de "canais alternativos", tais como o pfsync(4) (para a filtragem redundante), rsync para a duplicação manual entre as máquinas, ou qualquer um que seja apropriado para a sua aplicação.

6.11.2 - Configuração

O controle do CARP é feito em dois lugares: sysctl(8) e ifconfig(8). Deixe-nos abordar por primeiro os parâmetros do sysctl.

A primeira variável do sysctl, net.inet.carp.allow, define se a máquina manipula ou não os pacotes CARP. Claramente, isso é necessário para a utilização do CARP. Essa variável do sysctl é ativada por padrão.

A segunda, net.inet.carp.log, registra as mudanças de estado do CARP, pacotes defeituosos e outros erros. Definida para registrar as mudanças de estado por padrão.

A terceira, net.inet.carp.preempt, ativa a seleção natural entre as máquinas CARP. O mais adequado para o trabalho (isto é, aquele que é capaz de anunciar mais frequentemente) torna-se o mestre. Ela está desativada por padrão, o que significa que um sistema que não é um mestre não tenta (re)ganhar o status de mestre.

Todas essas variáveis estão documentadas em sysctl(3).

Para o restante da configuração do CARP, nós contamos com o ifconfig(8). Os comandos advbase e advskew, específicos do CARP, lidam com intervalos entre os anúncios CARP. A fórmula (em segundos) é advskew dividido por 256, e então adicionado a advbase. advbase pode ser usada para diminuir o tráfego da rede ou autorizar uma grande latência antes que uma máquina de backup torne-se ativa; advskew pemite a você controlar qual máquina será o mestre sem muito atraso de "failover" (se isso é necessário).

Próximo, pass configura uma senha e vhid configura o número de identificação da máquina virtual de um grupo CARP. Você precisa atribuir um número único para cada grupo CARP, mesmo se (para propósitos de balanço de carga) eles compartilham o mesmo endereço IP. CARP tem um limite de 255 grupos.

E finalmente, carpdev especifica qual interface física pertence a esse grupo CARP em particular. Por padrão, qualquer interface que possui um endereço IP na mesma sub-rede que está atribuída à interface CARP será utilizada.

Deixe-nos colocar todos esses parâmetros juntos em uma configuração básica. Admitamos que você está configurando dois servidores Web, rachael (192.168.0.5) e pris (192.168.0.6), a fim de substituir um sistema antigo que estava em 192.168.0.7. Os comandos:

rachael# ifconfig carp0 create
rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \
    192.168.0.7 netmask 255.255.255.0

criam a interface carp0 e é dado a ela um vhid de valor 1, a senha tyrell, o endereço IP 192.168.0.7 com a máscara de rede 255.255.255.0. fxp0 é designada como a interface do membro. Para tornar isso permanente depois da reinicialização, você pode criar um arquivo /etc/hostname.carp0 que se parece com isto:

inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Note que o endereço de emissão ("broadcast") é especificado nessa linha, em adição ao vhid e à senha. Essa configuração é necessária e é uma causa comum de erros quando esquecida.

Faça o mesmo com pris. O sistema que carregar por primeiro a interface CARP será o mestre (assumindo que "preempt" está desativada; senão, o inverso será produzido).

Deixe-nos dizer que você não está configurando a partir do zero. Rachael já estava no lugar, no endereço 192.168.0.7. Como você contorna essa situação? Felizmente, CARP pode lidar com essa situação. Você simplesmente atribui o endereço à interface CARP e deixa a interface física especificada pela palavra-chave `carpdev' sem um endereço IP. De qualquer forma, é mais apropriado ter um IP para cada sistema -- isso torna o acesso e monitoramento individual mais simples.

Deixe-nos adicionar uma outra camada de complexidade; queremos que rachael seja o mestre sempre que possível. Há muitas razões para querermos isso: diferenças de hardware, pouco prejuízo, "se este sistema não é o mestre, temos um problema", ou simplesmente conhecer o mestre por padrão sem ter que usar scripts para analisar a saída do ifconfig e enviar por correio eletrônico.

Em rachael, nós iremos usar a variável do sysctl comentada acima; então edite o /etc/sysctl.conf para torná-la permanente.

rachael# sysctl net.inet.carp.preempt=1

Configuração em pris:

pris# ifconfig carp0 advskew 100

Isso gera atraso nos anúncios de pris, o que significa que rachael será o mestre sempre que estiver funcionando.

Note que se você está usando o PF em um computador com CARP, você precisa liberar "proto carp" em todas as interfaces envolvidas, com uma linha similar a esta:

pass on fxp0 proto carp keep state

6.11.3 - Balanço de carga ("load balancing")

Os meses passaram rápido. Nossa empresa do exemplo anterior cresceu ao ponto de que um único servidor Web interno está com dificuldades para gerenciar a carga. O que fazer? CARP para o salvamento. É hora de se fazer o balanço de carga. Crie uma nova interface CARP e um grupo em rachael:

rachael# ifconfig carp1 create
rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \
    192.168.0.7 netmask 255.255.255.0

Em pris, nós também criaremos o novo grupo e a interface, então configuramos a variável do sysctl "preempt":

pris# ifconfig carp1 create
pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 \
    192.168.0.7 netmask 255.255.255.0
pris# sysctl net.inet.carp.preempt=1

Agora nós temos dois grupos CARP com o mesmo endereço IP. Cada grupo é desviado em direção a uma máquina diferente, isso significa que rachael será o mestre do grupo original, mas pris será o mestre do segundo.

Enquanto esses exemplos são para um cluster de duas máquinas, o mesmo princípio aplica-se para mais sistemas. Note que isso não assegura que você consiga uma distribuição de 50/50 entre as duas máquinas: CARP usa uma dispersão do endereço IP de origem para determinar qual sistema responderá a requisição, independente da carga.

6.11.4 - Mais informação sobre CARP

6.12 - Como usar o OpenNTPD

Um horário preciso é importante para muitas aplicações na informática. Muitas pessoas observam que seus relógios de $5 (cinco dólares) são mais precisos que seus computadores de $2000 (dois mil dólares). Além de saber que horas são, é também importante sincronizar os computadores para que todos eles estejam de acordo com a hora atual. Por algum tempo, ntp.org produziu uma aplicação do Protocolo de Horário de Rede (NTP - "Network Time Protocol") (RFC1305, RFC2030), disponível através do portes, que pode ser usada para sincronizar os relógios das máquinas através da Internet. Esse programa, entretanto, é difícil de ser configurado, o código dele é difícil de ser auditado e ele necessita de uma grande quantidade de memória. Em suma, é um programa importante para certas pessoas, mas que está longe de ser uma solução para todos os usuários.

OpenNTPD é uma tentativa de resolver alguns desses problemas, criando um programa compatível com o NTP, que é fácil para o administrador configurar, seguro, simples, e que permite ter uma hora exata no seu computador. O ntpd(8) do OpenBSD é controlado através de um arquivo de configuração /etc/ntpd.conf fácil de compreender.

Ativando o ntpd(8) através do rc.conf.local, o relógio do seu computador avançará lentamente e estará sincronizado com os servidores pool.ntp.org, uma coleção de servidores de hora públicos. Uma vez que seu relógio está configurado precisamente, ntpd faz com que ele permaneça em um alto grau de precisão, mas se seu relógio fica desligado por alguns minutos, é altamente recomendado que você regule ele precisamente no momento da inicialização; a sincronização de um relógio que esteve desligado por muito tempo pode levar dias ou várias semanas. Você pode fazer isso usando a opção "-s" do ntpd(8) ou qualquer outra forma para configurar precisamente o relógio do seu sistema.

6.12.1 - "Mas o OpenNTPD não é tão preciso quanto o daemon ntp.org!"

Isso é provavelmente verdade. Esse não é um objetivo da concepção do OpenNTPD, ele é pensado para ser livre, simples, estável e seguro. Se você realmente necessita de uma precisão de microsegundos, mais do que os benefícios do OpenNTPD, sinta-se livre para usar o ntpd do ntp.org, ele permanecerá disponível através de portes ou pacotes. Não há plano ou desejo de ter um OpenNTPD inchado com todas as funcionalidades que se possa imaginar.

6.12.2 - "Alguém falou que o OpenNTPD é 'inútil'!"

Algumas pessoas não entendem os objetivos do OpenNTPD, um simples, seguro e fácil jeito de manter preciso o relógio do seu computador. Se manter um tempo preciso é importante, vários usuários têm informado melhores resultados com o OpenNTPD do que com o ntpd do ntp.org. Se a segurança é importante, o código do OpenNTPD é muito mais fácil de ler (e, dessa forma, pode ser auditado) e foi escrito usando chamadas de funções nativas do OpenBSD, como strlcpy, em vez de funções mais portáveis como strcpy, e foi escrito para ser seguro desde o início, sem "fazer a segurança depois". Se ter mais pessoas usando a sincronização de horário é valioso, o OpenNTPD torna muito fácil o uso para um grande número de pessoas. Se essas são coisas "inúteis", todos nós somos.

Existem aplicações onde o ntpd ntp.org é mais apropriado; entretanto, observa-se que o OpenNTPD é mais que suficiente para a maioria dos usuários.

Uma resposta mais completa para isso, feita por um dos mantenedores do OpenNTPD, pode ser lida aqui.

6.12.3 - Por que minhas outras máquinas não podem ser sincronizadas com o OpenNTPD?

Por padrão, ntpd(8) não escuta em qualquer endereço. Assim, para utilizar ele como um servidor, você precisa descomentar a linha "#listen on *" do arquivo /etc/ntpd.conf e reiniciar o daemon ntpd(8). Naturalmente, se você deseja que ele escute em um endereço IP específico em vez de todos os endereços e interfaces disponíveis, troque o "*" pelo endereço desejado.

Quando você tem o ntpd(8) escutando, pode acontecer de outras máquinas não conseguirem se sincronizar com ele! Uma inicialização rápida do daemon ntpd(8) (por exemplo, se você está reiniciando-o após modificar o ntpd.conf) se recusa a servir a informação do horário para outros clientes até que ele ajuste seu próprio relógio para um nível razoável de estabilidade. Quando o ntpd(8) considera estável sua própria informação de horário, ele anuncia com uma mensagem "clock now synced" em /var/log/daemon. Mesmo se o relógio do sistema está correto na inicialização, ele pode levar até 10 minutos para se sincronizar, e horas ou dias se o relógio não está configurado precisamente.

6.13 - Quais são minhas opções em rede sem fio?

O OpenBSD possui suporte para vários chipsets de rede sem fio: (AP) significa que a placa pode ser usada como ponto de acesso.
(NFF) significa que o chip necessita de um firmware não-livre que não pode ser incluído no OpenBSD.

Adaptadores baseados nesses chips podem ser usados como qualquer outro adaptador de rede para conectar um sistema OpenBSD em uma rede sem fio existente, configurados usando o ifconfig(8) padrão (por favor, veja as páginas de manual para detalhes precisos). Algumas dessas placas podem também ser usadas no modo "Host-Based Access Point", permitindo que elas sejam usadas como um ponto de acesso sem fio para sua rede, ou como uma parte do seu firewall.

Note que para usar algumas dessas placas, você vai precisar adquirir os arquivos de firmware que os fabricantes se recusam em permitir a livre distribuição, assim eles não podem ser incluídos no OpenBSD. Quando possível, as páginas de manual referenciadas acima incluem informações de contato, para que você possa contatar a pessoa certa dos fabricantes e falar o que pensa sobre isso, ou informar qual produto você comprou no lugar do produto deles.

Uma outra opção a ser considerada no uso de firewall baseado no OpenBSD para fornecer acesso sem fio, é usar uma placa de rede convencional e um ponto de acesso externo em modo ponte ("bridge"). Esse método tem a vantagem de permitir que você posicione facilmente a antena onde ela é mais eficiente, não diretamente atrás do seu firewall.

6.14 - Como posso fazer roteamento multicaminhos de custo igual?

O roteamento multicaminhos de custo igual ("equal-cost multipath routing") permite ter múltiplas rotas na tabela de roteamento da mesma rede, tal como a rota padrão 0.0.0.0/0. Quando o kernel faz uma pesquisa de rota para determinar onde enviar os pacotes destinados à rede, ele pode escolher qualquer uma das rotas de custo igual. Na maioria dos cenários, o roteamento multicaminhos é usado para prover conexões redundantes de "uplink"; por exemplo, conexões redundantes à Internet.

O comando route(8) é usado para adicionar/mudar/remover rotas na tabela de roteamento. O argumento -mpath é usado para adicionar rotas multicaminhos.

# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1

Verifique as rotas:

# netstat -rnf inet | grep default
default     10.130.128.1      UGS       2      134      -     fxp1
default     10.132.0.1        UGS       0      172      -     fxp2

Nesse exemplo nós podemos ver que uma rota padrão aponta para 10.130.128.1, sendo acessada pela interface fxp1, e a outra aponta para 10.132.0.1, sendo acessada pela fxp2.

O arquivo mygate(5) ainda não suporta rotas multicaminhos por padrão, os comandos acima devem ser adicionados no final dos arquivos hostname.if(5) das interfaces fxp1 e fxp2. O arquivo /etc/mygate deve então ser excluído.

/etc/hostname.fxp1
!route add -mpath default 10.130.128.1
/etc/hostname.fxp2
!route add -mpath default 10.132.0.1

E finalmente, não se esqueça de ativar o uso de rotas multicaminhos com a variável apropriada do sysctl(3).

# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1

Tenha certeza de editar o sysctl.conf(5) para que as mudanças sejam permanentes.

Agora tente um traceroute para destinos diferentes. O kernel faz o balanço de carga do tráfego sobre cada rota multicaminhos.

# traceroute -n 154.11.0.4
traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets
 1  10.130.128.1  19.337 ms  18.194 ms  18.849 ms
 2  154.11.95.170  17.642 ms  18.176 ms  17.731 ms
 3  154.11.5.33  110.486 ms  19.478 ms  100.949 ms
 4  154.11.0.4  32.772 ms  33.534 ms  32.835 ms

# traceroute -n 154.11.0.5
traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets
 1  10.132.0.1  14.175 ms  14.503 ms  14.58 ms
 2  154.11.95.38  13.664 ms  13.962 ms  13.445 ms
 3  208.38.16.151  13.964 ms  13.347 ms  13.788 ms
 4  154.11.0.5  30.177 ms  30.95 ms  30.593 ms

Para mais informação sobre como a rota é escolhida, use a referência RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".

É útil notar que se uma interface usada por um rota multicaminhos é derrubada (ou seja, perde seu sinal), o kernel continua tentando passar adiante os pacotes usando a rota que aponta para aquela interface. Esse tráfego será, naturalmente, perdido. É altamente recomendado usar o ifstated(8) para fazer a verificação de interfaces indisponíveis e ajustar a tabela de roteamento de acordo.

[Índice da FAQ] [Seção 5 - Construção do Sistema a partir do Código Fonte] [Seção 7 - Controle do Teclado e da Tela]


[voltar] www@openbsd.org
$OpenBSD: faq6.html,v 1.14 2010/11/15 18:41:58 ajacoutot Exp $