Um cliente VPN no seu servidor web quebra as respostas dele?

O site carrega a partir de um portátil na mesma rede e expira em qualquer outro lugar, e o host também executa um cliente VPN para o seu próprio tráfego de saída. Essa combinação produz uma falha específica: a conexão de entrada chega, a resposta sai pelo caminho errado e o cliente do lado de fora nunca vê uma resposta. As duas metades aparecem na mesma captura de pacotes, então a ordem dos eventos é a parte que vale a pena ler.

Uma regra de roteamento baseada na origem frequentemente corrige o sintoma. Ela também costuma isentar mais tráfego do que o site que a motivou, e essa é a parte que vale a pena entender antes de guardar a regra.

O sintoma: responde localmente e não de fora

Dentro da rede a resposta não precisa atravessar o túnel, então a página carrega e o serviço parece saudável. De fora, o pedido chega ao host e a resposta é encaminhada para a VPN, onde a extremidade remota não tem motivo para aceitá-la. O navegador vê um tempo limite em vez de uma recusa, que é a assinatura de um caminho de mão única e não de uma porta fechada.

Confirme a forma antes de mudar o roteamento: o ouvinte está ativo, o pedido local tem sucesso e o pedido externo não produz resposta alguma. Essas três observações juntas apontam para o caminho de retorno e não para a configuração do servidor web. Uma assimetria tão limpa é mais útil do que qualquer linha de log, porque descarta o ouvinte antes que você leia uma única mensagem de erro.

Mantenha um caminho de administração independente aberto enquanto trabalha. Uma regra que quebra a sua própria sessão SSH transforma uma correção de dez minutos em uma visita física.

O que um seletor de origem realmente corresponde

No roteamento de políticas do Linux, uma regra como from 192.168.50.2 corresponde a pacotes cuja origem é esse endereço. Ela não codifica o fato de que o pacote continua uma conversa que entrou pelo roteador doméstico, e não sabe qual processo a criou. O endereço desse exemplo é ilustrativo; substitua-o pelo endereço que o seu host realmente usa. Trate a linha como uma afirmação sobre endereços e nada mais.

Se a tabela selecionada fornece uma rota padrão comum, cada pacote que carrega essa origem pode tomar a mesma exceção. Outro serviço vinculado ao mesmo endereço herda-a, e um aplicativo que se vincula deliberadamente a esse endereço também a herda. A referência de regras de política lista origem, destino, protocolo, porta, marca e prioridade como seletores separados, o que lembra que a origem sozinha é o mais grosseiro disponível.

A prioridade decide o resultado. As buscas ocorrem em ordem e a primeira tabela que produz um resultado pode encerrar a busca, então uma regra colocada cedo demais pode ocultar uma rota mais específica que uma tabela posterior teria fornecido. Leia a lista ordenada inteira em vez da única linha que você adicionou. Uma regra que nunca corresponde não custa nada, enquanto uma que corresponde cedo demais muda silenciosamente tudo o que está atrás.

Verifique o caminho de retorno e o tráfego que você não pretendia

Leia as regras e as tabelas, depois pergunte ao kernel qual rota um par específico de origem e destino tomaria. Testar a partir do próprio host não é o mesmo que testar de fora, então faça as duas coisas.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Depois aceite uma nova conexão externa e, separadamente, um pedido que ainda deve sair pela VPN. Se o segundo agora sai diretamente, a exceção é mais ampla do que o problema que você estava resolvendo, e o teste que importa é aquele que você não pretendia mudar.

Uma verificação de endereço público no navegador relata apenas os pedidos que aquele navegador fez. Ela não diz nada sobre as respostas do servidor web, sobre a seleção de origem de outro aplicativo local, nem sobre o que acontece com o tráfego de gestão após a próxima reconexão da VPN.

Decida quão estreita a exceção pode ser

Dois desenhos são defensáveis e devem ser escolhidos deliberadamente. Se o host existe para publicar este serviço e o seu tráfego de saída não é importante, um endereço local dedicado com uma política apenas para WAN é um arranjo razoável desde que você aceite todo o escopo. Se apenas conexões de entrada específicas devem ser qualificadas, a seleção de endereço é grosseira demais e um desenho consciente das conexões deve vir antes dela.

Registre o contrato em que você se apoia: o mapeamento público, o endereço do host ao qual o pedido é entregue e o caminho que a resposta deve tomar. Um serviço de entrada publicado através de um provedor de VPN é um contrato diferente daquele publicado através de um roteador doméstico, e uma exceção copiada de um exemplo costuma estar errada para o outro.

Persista a política no componente que possui o roteamento em vez de colar um comando num arquivo de inicialização. A ordem das regras, a limpeza após uma mudança de rede e a repetição após um reinício precisam sobreviver, e um arquivo de inicialização não testado costuma falhar no momento em que você não está olhando. Termine com o resultado de aceitação que você pode defender: um site publicado restaurado e um fluxo não relacionado inalterado.