O que o bypass-dhcp realmente acrescenta a um plano de rotas OpenVPN

Um perfil com redirect-gateway def1 bypass-dhcp combina uma substituição da rota IPv4 padrão com uma única exceção estreita. As pessoas leem a última palavra e esperam uma solução geral para conexões móveis, depois passam uma tarde com uma teoria de DHCP que a flag nunca apoiou. Cada parte faz uma coisa, e a exceção é muito menor do que a sua reputação.

Separe as flags antes de atribuir uma falha que só ocorre em rede móvel à atribuição de endereços. As duas metades dessa string não têm nada a ver uma com a outra.

Duas flags, duas tarefas sem relação

Com def1, o cliente adiciona duas meias rotas IPv4 padrão em vez de substituir a rota padrão que já existe. 0.0.0.0/1 cobre a metade inferior do espaço de endereços e 128.0.0.0/1 a metade superior, de modo que juntas alcançam qualquer destino enquanto cada uma continua mais específica que 0.0.0.0/0. A rota padrão original permanece, portanto, na tabela sem ganhar essas consultas, o que mantém o gateway antigo alcançável para tudo o que o cliente encaminha explicitamente. Isso também deixa duas rotas padrão sobrepostas na tabela, e por isso um dump de rotas pode parecer mais estranho do que o perfil sugere.

bypass-dhcp é separado e não toca na rota padrão de forma alguma. O manual do OpenVPN 2.6 documenta-o como a adição de uma rota direta para um servidor DHCP que não está na sub-rede local, de modo que o tráfego de concessão sai fora do túnel, e observa que o comportamento é implementado em clientes Windows e pode não estar disponível em outros lugares.

A razão da sua existência é mecânica. Assim que as meias rotas padrão capturam o tráfego de saída, uma renovação de DHCP dirigida a um servidor na rede física seria encaminhada para dentro do túnel, a menos que algo fixe esse endereço à interface real. A flag fixa-o.

A que a exceção está realmente limitada

Uma tabela ilustrativa após uma conexão bem-sucedida mostra a forma: duas meias rotas padrão pelo túnel e uma rota de host para o servidor DHCP pelo gateway físico. Leia-a como uma forma, não como os seus próprios endereços.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Essa terceira linha nomeia um único destino. Não é uma configuração do resolvedor, não é uma permissão geral para a rede local e não é uma regra de saída no servidor. Um telefone numa operadora móvel pode não ter nenhum servidor DHCP que o cliente consiga identificar desta forma, e é por isso que a flag não muda nada ali.

Verifique o que o cliente realmente instalou

Distinga uma opção escrita num perfil, uma opção oferecida pelo servidor e uma rota que o proprietário da conexão realmente aplicou. Um cliente que rejeita uma flag não suportada pode manter o resto da configuração, então o túnel sobe e a exceção simplesmente está ausente. Leia o log do próprio cliente e a tabela de rotas resultante em vez de presumir que a linha no ficheiro entrou em vigor. Três dessas coisas podem ser verdadeiras ao mesmo tempo, e só a última muda para onde os pacotes realmente vão.

Mantenha a rota para o ponto final da VPN utilizável ao mesmo tempo. Essa exceção do ponto final é um requisito diferente da exceção DHCP, e sem ela o túnel pode capturar o transporte que o mantém.

Para um destino de aplicação, examine a consulta efetiva no contexto em que falha. Rotas locais mais específicas, encaminhamento por políticas e exclusões por aplicação alteram todas a resposta, portanto a presença de duas meias rotas padrão não é um inventário de todos os fluxos.

O resto do caminho não está nesta flag

O servidor ainda precisa de permissão para encaminhar o tráfego de internet do cliente e de uma disposição de saída que o possa devolver. Nenhuma rota do lado do cliente cria um encaminhamento ou uma tradução de origem em falta no servidor, e nenhuma flag substitui um caminho de retorno funcional.

A resolução de nomes e o IPv6 precisam cada um da sua própria política. Uma substituição de IPv4 não aponta o resolvedor para um servidor do lado do túnel nem estabelece cobertura IPv6, e um cliente que só redireciona v4 deixa o caminho v6 intacto.

Compare um pedido inofensivo aprovado num caminho de acesso funcional e num que falha, mantendo o perfil e o destino fixos. Registe se a diferença está na resolução de nomes, no estabelecimento do túnel, na seleção de rotas ou no tráfego encaminhado, e guarde a resposta com o perfil. Esse registo é o que impede a próxima pessoa de culpar o DHCP por um problema que ele não consegue alcançar.