O mesmo IP de servidor, dois caminhos: marcar o fluxo externo do OpenVPN

A proteção de loop habitual é uma rota de host: envie o tráfego para o endereço público do servidor VPN pelo uplink para que a sessão cifrada nunca entre no seu próprio túnel. Isso funciona exatamente até o momento em que você também quer alcançar um serviço web nesse mesmo servidor pelo túnel, porque a isenção está ligada ao destino e o destino é idêntico. A saída é parar de classificar por destino e começar a classificar por qual socket enviou o pacote.

Comece pelos dois fluxos que você quer separar

Um fluxo é o próprio transporte OpenVPN cifrado, que precisa sair pelo uplink, senão o túnel carregaria a sua própria conexão externa. O outro é uma requisição HTTPS comum ao mesmo endereço público, que você quer dentro do túnel para que chegue ao serviço a partir de uma origem de túnel. Mesmo destino, em muitos casos mesmo número de porta, caminho necessário diferente.

Para este percurso, suponha um cliente em 10.90.0.10 sobre tun1, um endereço público de servidor de 198.51.100.25 e uma tabela principal intacta cuja rota padrão aponta para o uplink comum. O lado do servidor também precisa aceitar o serviço web no caminho interno e devolver o tráfego à origem do túnel; enviar um pacote para um endereço público não anula o listener nem a política de firewall do servidor.

Antes de mudar qualquer coisa, capture as regras atuais do host e escolha valores que ninguém mais usa: uma marca, um número de tabela e três prioridades de regra. Mantenha um caminho de volta à máquina que não passe por esta conexão, porque um erro aqui remove o seu próprio acesso remoto em vez de apenas quebrar uma aba do navegador.

Marque o socket que carrega o envelope

A configuração do cliente ganha uma marca para os seus pacotes cifrados de saída, e deixa de instalar rotas por conta própria para que a política de substituição seja a única coisa que decide os caminhos:

mark 42
route-noexec
disable-dco

O decimal 42 é hexadecimal 0x2a, e a forma hexadecimal é a que as regras de roteamento vão corresponder. A referência de link-options descreve mark como algo que se aplica aos pacotes cifrados de saída no Linux, que é exatamente o socket cujo caminho você precisa controlar. Desativar o offload do canal de dados mantém este exemplo no caminho do espaço do usuário, onde o comportamento da marca é o que se descreve.

route-noexec suprime as adições e remoções automáticas de rotas do OpenVPN. Não instala nada no lugar delas, então a partir deste momento o dono das rotas precisa manter todas as rotas que o túnel exige. Se um destino privado desaparecer depois da mudança, isso é a política de substituição em falta, não uma falha na marca.

Não mantenha uma rota de host na tabela principal para 198.51.100.25 enquanto faz isto. Uma rota assim reintroduz exatamente a isenção que o desenho tenta restringir, e vai vencer para o fluxo HTTPS antes de qualquer uma das políticas abaixo ser consultada.

Envie todo o resto para a tabela do túnel

Assim que a interface do túnel existe e tem o seu endereço, a política fica assim:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

A primeira regra mantém visíveis as rotas específicas do host, incluindo qualquer rede local aprovada, enquanto torna invisível a rota padrão da tabela principal para esta consulta. Essa distinção importa: suprimir a padrão não é o mesmo que ignorar a tabela, e as exceções locais de que ainda precisa sobrevivem por isso. Leia essas exceções uma a uma em vez de presumir que o resultado é um interruptor de paragem universal.

O tráfego não marcado cai então na tabela do túnel, assume a origem do túnel e sai pela VPN. O tráfego marcado falha o teste fwmark nas duas regras seguintes e continua para a consulta principal comum mais abaixo na lista, onde a padrão do uplink ainda está. A regra unreachable final é a que impede um fluxo não marcado de cair silenciosamente de volta no uplink quando a rota do túnel falta. O seletor é a marca do início ao fim, e o endereço de destino nunca entra na decisão.

Mantenha essa guarda no lugar entre desconexões, e instale-a com o resto da política em vez de à mão. Uma regra que desaparece com a interface não é uma política, é uma coincidência. Apagar a política quando o túnel cai muda o modo de falha de “bloqueado” para “filtrado”, e uma rota de túnel obsoleta que expira depois é um problema muito mais fácil de explicar do que tráfego que saiu pela interface errada.

Faça o caminho de volta ver a mesma marca

As marcas de saída são apenas metade do mecanismo, e esta é a parte que a maioria das reproduções omite. As respostas à sessão cifrada chegam pelo uplink e estão sujeitas à validação de caminho de volta, que pergunta se a origem encaminharia de volta pelo mesmo caminho por onde veio. Sem ajuda, essa consulta aplica a sua política de túnel não marcada e conclui que o pacote está na interface errada.

A correção pertence ao dono da firewall: guarde a marca na conexão de saída, restaure-a nos pacotes de entrada correspondentes e ative o tratamento de marcas validado pela origem para o caminho relevante. O OpenVPN definir uma marca de socket não faz nenhuma dessas três coisas, e uma receita que só lista as opções do cliente está incompleta. Peça essa integração por escrito, porque é a parte menos visível do desenho e a mais fácil de perder numa reconstrução.

A verificação laxista do caminho de volta também não é substituta. O modo laxista ainda precisa que exista alguma rota para a origem, e a guarda unreachable que você adicionou remove deliberadamente uma para as consultas não marcadas. Faça a integração da marca de conexão ficar concluída e revista antes de confiar neste desenho, e trate os filtros de host como uma questão à parte: uma marca é um sinal de roteamento, não uma permissão. Se a integração faltar, o sintoma é uma sessão que se estabelece e depois fica em silêncio assim que as respostas começam a chegar.

Prove-o com duas consultas de rota

Compare o que o núcleo decide para os dois contextos, e leia os campos dev e src em vez do estado de saída:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

A primeira consulta deve resolver para tun1 com a origem do túnel, e a segunda para o uplink. São consultas sintéticas, por isso provam a política e não o processo em execução: confirme o caminho de transporte real do cliente em execução em separado e depois faça uma requisição HTTPS real com a verificação de certificados ativada.

Anote o que o desenho não cobre antes de o declarar terminado. DNS, IPv6 e o ciclo de vida das regras precisam cada um da sua própria decisão, e isto é um exemplo de roteamento IPv4 em vez de uma configuração de privacidade completa. O seu valor é o seletor: o envelope recebe a isenção do uplink, e um serviço comum no mesmo endereço não tem de a herdar.