Qual endereço o pool entregará na próxima reconexão?

Uma regra que correspondia ontem deixa de corresponder hoje porque o cliente voltou com outro endereço de túnel. O alocador, porém, não é aleatório, e conhecer a sua ordem transforma essa surpresa num evento previsível. Ele prefere o endereço que o mesmo cliente tinha antes, recorre ao livre usado há mais tempo e esquece tudo se não lhe der onde lembrar. As regras que pressupõem uma concessão continuam a corresponder até ao dia em que, em silêncio, deixam de o fazer.

A ordem que o alocador segue

Com uma sessão por common name, o alocador procura primeiro um endereço que o mesmo cliente usou antes e que está livre neste momento. Se esse endereço já não existir, toma o endereço livre que está inativo há mais tempo. Com sessões simultâneas ativadas para o mesmo nome, a preferência pelo endereço anterior não se aplica e, em vez disso, usa-se o primeiro endereço livre, porque as sessões são tratadas como pares separados.

Daí decorrem duas consequências imediatas. Um cliente que se reconecta depressa costuma manter o endereço, e é por isso que ninguém nota o mecanismo até ele mudar. E um outro dispositivo que se ligue durante essa pequena janela pode apanhar o endereço enquanto está brevemente livre, depois do que o primeiro cliente recebe outra coisa e toda a regra ligada ao número antigo fica errada. Nenhum dos dois eventos produz uma linha de registo que pareça uma falha.

Porque uma concessão parece estável e depois se desloca

A estabilidade aqui é uma propriedade emergente de reconexões que chegam antes de alguém reclamar o endereço. Não é uma promessa, e não é imposta enquanto o cliente está desligado. Planeie que o endereço mude em vez de ser surpreendido por isso. Um pool pouco maior do que o número de dispositivos torna as colisões rotineiras, porque o recurso ao endereço usado há mais tempo quase não tem por onde escolher.

A concorrência de pico é o número com que se dimensiona, não o número de utilizadores. Alguém que testa a partir de dois dispositivos ao mesmo tempo, ou um cliente que se reconecta antes de a sessão antiga expirar, ocupa duas concessões durante algum tempo. Um pool dimensionado apenas para o número de pessoas produzirá exatamente a rotação que as pessoas culpam no servidor.

O ficheiro de persistência lembra, não reserva

Um endereço que sobrevive a um reinício do serviço precisa de um ficheiro de persistência. Guarda o nome do cliente e o endereço ao encerrar e volta a lê-los quando o serviço arranca, e é por isso que um reinício planeado já não baralha todas as regras que escreveu.

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

O que ele não faz é reter o endereço enquanto o cliente está ausente. Nesse intervalo o alocador pode dar o número a outra pessoa, e o ficheiro regista então uma preferência desatualizada que a ligação seguinte não consegue cumprir. Trate-o como uma pista que melhora o comportamento no reinício, não como endereçamento estático.

Verifique o pool contra cada sub-rede encaminhada enquanto está no ficheiro. Um intervalo sobreposto entrega endereços para os quais o servidor não consegue encaminhar, e o sintoma é um cliente que se liga, recebe um endereço e não alcança nada.

Fixar um endereço corretamente

Quando uma regra de firewall ou um registo DNS precisa mesmo de um endereço fixo, atribua-o em vez de esperar por ele. Uma entrada de configuração por cliente pode enviar um endereço e uma máscara diretamente, e essa entrada é indexada pelo nome efetivo do cliente.

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

Mantenha os endereços fixos fora do pool dinâmico para que o alocador nunca entregue o mesmo número a outra sessão. Depois verifique a topologia do túnel, porque ela altera quantos endereços do pool cada cliente consome: a antiga disposição ponto a ponto consome um bloco pequeno por cliente, enquanto uma disposição em sub-rede usa apenas um endereço por cliente. Um pool que parece generoso sob uma topologia pode esgotar-se sob a outra.

Confirme o resultado no cliente em vez de confiar na contabilidade do servidor. Quando a sessão voltar, olhe para o endereço da interface e para a rota enviada, porque um registo no servidor pode indicar o endereço pedido enquanto a interface tem outro.

O endereço remoto é uma questão separada

O endereço na linha remota do cliente tem de ser alcançável antes de existir qualquer túnel. Colocar ali um endereço do pool, como o próprio ponto final do túnel do servidor, significa que o cliente tenta alcançar o ponto final através de um túnel que ainda não construiu, e o resultado é um ciclo ou um tempo limite silencioso em vez de um atalho.

Use o ponto final público fornecido pelo operador e reserve o pool para aquilo para que foi concebido: endereços dentro do túnel. Anotar o intervalo do pool, as atribuições fixas e o caminho de persistência num só lugar poupa a próxima pessoa de tratar cada concessão como arbitrária.