O que o route-nopull do OpenVPN realmente impede o servidor de enviar

Você colocou route-nopull num perfil de cliente para impedir que o túnel engolisse a sua rota predefinida, e agora a sub-rede do escritório está inacessível enquanto o cliente continua a dizer que está ligado. Ambas as observações são verdadeiras, e nada falhou. A flag diz ao cliente para ignorar as rotas e as entradas DHCP que o servidor envia, uma instrução mais estreita do que a maioria espera ao adicioná-la. O que resta é um túnel funcional sem opinião sobre quais destinos o devem usar.

Essa lacuna é toda a decisão de que trata este artigo. Ou o servidor descreve a rede, ou é o cliente, e a flag entrega essa tarefa ao cliente sem fazer nada dela por você.

O que a flag desliga ao ligar

Um cliente OpenVPN que puxa normalmente recebe do servidor, após a autenticação, um pacote: rotas, um redirecionamento da gateway predefinida, servidores DNS e algumas diretivas de afinação. Com route-nopull em vigor, o cliente continua a aceitar a sessão, continua a verificar certificados, continua a negociar cifras e keepalives, e continua a levantar a interface. O que descarta é a aplicação das linhas route enviadas e das linhas dhcp-option enviadas, DNS incluído.

A confusão vem de um indicador verde ao lado de uma aplicação morta. O túnel existe; o mapeamento dos destinos para esse túnel não. Nada no painel de estado do cliente distingue «ligado e a encaminhar» de «ligado e inerte», porque do ponto de vista do túnel ambos são o mesmo estado.

Porque um túnel vivo pode não encaminhar nada

A interface aparece com o seu próprio endereço e, numa ligação ponto a ponto, muitas vezes não tem nada mais específico do que uma rota de host para o par. Uma sub-rede privada só se torna alcançável quando alguma rota aponta para essa interface com o prefixo correto, e com o envio desativado essa rota nunca chega. O perfil descarregado também normalmente não ajuda, porque foi escrito assumindo que o servidor forneceria exatamente esta informação. É por isso que a interface pode parecer saudável enquanto a sub-rede permanece escura.

Ler o perfil prova, portanto, muito pouco. Leia o estado em execução, na máquina ligada:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Um endereço sem rota de sub-rede no segundo comando é a assinatura deste problema. O terceiro comando responde então à pergunta que realmente importa aos utilizadores, porque relata a interface que o núcleo escolheria para um destino específico em vez da lista que esperava que fosse usada. Se responder pela sua ligação física, o túnel não está no caminho de todo.

A resolução de nomes falha por uma razão relacionada, não por uma separada. As entradas dhcp-option DNS enviadas são ignoradas pela mesma flag, por isso as consultas de hosts internos vão para o resolver que a rede local tiver fornecido. Esse resolver não tem zona para o escritório, por isso a consulta falha ou devolve uma resposta pública, e a falha parece um problema do servidor quando é um problema de configuração do cliente. Testar um endereço antes de um nome é o que separa os dois.

Escolher entre a flag e um filtro de prefixo

As duas opções resolvem formas diferentes da mesma queixa, e é a má escolha que produz o estado ligado-mas-inútil. Uma substitui a política enviada por completo, enquanto a outra a edita por prefixo. A tabela dá a versão curta, e o parágrafo seguinte cobre a parte que apanha as pessoas.

pull-filter é um comparador de prefixos com três verbos, por isso pode aceitar uma família de linhas, ignorá-las em silêncio ou rejeitar a ligação de imediato quando aparece um prefixo. É esse último comportamento que vale a pena conhecer: uma regra de rejeição transforma um desacordo de política numa ligação falhada em vez de uma omissão silenciosa. O manual do OpenVPN 2.6 lista os prefixos aceites e a semântica exata de cada verbo.

Um caminho intermédio comum é rejeitar apenas redirect-gateway e deixar as rotas do escritório e o DNS chegar como pretendido. Isso mantém o envio a funcionar para as partes que o servidor entende melhor do que você, ao mesmo tempo que evita a única linha que assumiria a sua rota predefinida.

Adicionar rotas e um resolver à mão

Se mantiver a flag, o perfil tem de dizer o que o servidor teria dito. As diretivas route do lado do cliente são aplicadas depois de a ligação ser estabelecida, por isso funcionam ao lado da flag em vez de ficarem bloqueadas por ela. Coloque-as no perfil, não numa linha de comandos interativa, ou a próxima reconexão não reproduzirá o estado funcional.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

A linha DNS está numa posição incómoda: é uma diretiva do lado do cliente, mas alguns clientes só a aplicam através da integração DNS da plataforma, que pode substituí-la quando a ligação muda. Num anfitrião systemd, definir o resolver diretamente na interface do túnel é mais previsível do que esperar que o cliente ganhe o concurso de prioridades:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

O domínio de encaminhamento importa tanto como o endereço. Sem ele, as consultas de nomes públicos também podem ser enviadas para o resolver interno, e qualquer resolver interno que recuse a recursão quebrará a navegação enquanto a zona privada continua a funcionar. Com ele, só os nomes sob esse sufixo são encaminhados para o resolver do túnel e tudo o resto segue a ligação física.

Verificar o resultado: endereço, nome e o caminho exterior

Três testes separam as falhas possíveis. Obtenha o endereço privado por IP, depois o mesmo host por nome, depois um site público comum. Um IP que funciona com um nome que falha aponta para o resolver; um IP que falha com um nome que funciona aponta para o encaminhamento; falharem ambos significa normalmente que o túnel não está no caminho.

Depois olhe para fora em vez de para dentro. A rota própria do ponto final do túnel tem de sobreviver à mudança, e qualquer bloqueio de falha tem de ficar limitado ao túnel sem capturar o ponto final. Um cliente que continua a navegar depois de o túnel cair é um problema de política, não de encaminhamento, e não aparecerá em nenhum dos três testes acima.

Escreva a lista final na documentação do perfil: as rotas, o resolver, os domínios e a razão por que cada um existe. Uma reconexão que reproduza a mesma tabela é a única prova de que a política local está completa. Se as aplicações continuarem a falhar com o túnel levantado e os três testes passados, o próximo sítio onde olhar é a classe de problemas ligado-mas-offline e não certificados que já foram verificados.