Encaminhamento por origem para dois pools VPN: o que a sua regra deixa passar

Dois pools de clientes, um gateway e o plano parece trivial: uma regra manda o primeiro pool pela ligação rápida, outra manda o segundo pool por um túnel de parceiro. Depois as regras estão no lugar e o segundo pool continua a sair pela rota predefinida. A regra não está quebrada. A origem do pacote não é o que o autor esperava no momento da consulta, porque a tradução e a consulta acontecem em pontos diferentes da viagem do mesmo pacote, e a ordem é o contrário do diagrama mental que quase todos desenham.

A consulta acontece antes de a origem ser reescrita

Para um pacote encaminhado de um cliente VPN, o kernel executa uma sequência fixa. Chega à interface do túnel, passa pelo prerouting onde vivem conntrack e DNAT, depois é tomada a decisão de encaminhamento, depois o encaminhamento, depois o postrouting onde o SNAT é aplicado por último. Uma regra da forma from é consultada durante essa decisão de encaminhamento, o que significa que vê o endereço original do cliente, não o traduzido.

Acrescentar uma regra de masquerade não muda, portanto, qual política corresponde ao fluxo de saída. O que muda é o que o extremo remoto vê e, por consequência, que caminho de regresso existe. São duas consequências diferentes, e as revisões de alterações confundem-nas constantemente. Separe-as e o desenho costuma ficar claro num minuto.

É na direção da resposta que o endereço traduzido aparece nas regras. Um pacote que volta ao gateway é endereçado ao endereço traduzido, e se tiver regras de política baseadas no destino ou na interface por onde entrou, é esse o valor que vai comparar. A mesma ligação, uma fonte de verdade diferente em cada direção.

Dois pools com origens diferentes precisam mesmo de tabelas diferentes, e o desenho é sólido. O que a tabela acima exclui é o atalho de depurar olhando para o que o site remoto recebeu e deduzir a regra a partir disso.

Um teste a partir do gateway não é um teste do pool

O tráfego gerado pelo próprio gateway nunca passa pelo prerouting, porque não chegou por nenhuma interface. É encaminhado no percurso de saída, com o endereço do próprio gateway como origem, e uma regra from baseada num intervalo de clientes não vai corresponder. Cada ticket nesta área que diz que funciona a partir da máquina mas não do cliente é esse mesmo facto repetido.

Simule o cliente em vez de o aproximar. A consulta de encaminhamento pode ser feita diretamente, com uma origem e uma interface de entrada fornecidas:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Execute-o uma vez por pool. Se os dois comandos devolverem a mesma interface, as regras não separam os pools, e a razão é ou uma regra em falta ou uma regra de prioridade mais alta que corresponde a ambas. Se devolverem interfaces diferentes mas o cliente continuar a falhar, a falha está depois da consulta e pode deixar de olhar para as regras.

Prioridade, não posição no ficheiro

As regras são avaliadas por ordem crescente de prioridade, e o número é o que conta, não a ordem em que as escreveu. A tabela local está na prioridade 0, a tabela main na 32766 e a regra predefinida na 32767, por isso uma regra acrescentada com a prioridade predefinida fica perto do fim da lista e perde contra quase tudo.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Uma prioridade explícita torna a ordem pretendida visível no ficheiro e na revisão. Também impede que uma adição posterior se antecipe silenciosamente a uma regra existente, que é a causa mais frequente de uma política que funcionava deixar de funcionar após uma alteração não relacionada.

Uma regra correspondente que aponta para uma tabela incompleta é a outra armadilha. Se a tabela 201 contiver uma rota predefinida mas nenhuma rota para o destino, o pacote é descartado ou enviado para o lugar errado, e a regra parece perfeitamente correta isolada. Leia a tabela, não só a regra. Uma regra é um ponteiro, e uma tabela vazia é um ponteiro para nada.

O caminho de regresso tem de existir na mesma

A política de origem escolhe uma saída. Não cria um caminho de regresso. Se o segundo pool sair por um túnel de parceiro, o parceiro tem de saber como chegar a 172.31.8.0/24, quer por uma rota de volta para o gateway, quer recebendo endereços traduzidos que já conhece.

Escolher entre as duas é uma decisão de desenho com consequências visíveis. Encaminhar o intervalo de clientes de volta preserva a identidade de cada cliente no parceiro e exige que ele aceite o seu prefixo. A tradução esconde o pool atrás de um endereço e exige que o parceiro aceite apenas esse endereço, à custa de os seus registos e os dele deixarem de concordar sobre quem se ligou.

Escolha o que escolher, escreva-o ao lado da definição do pool. Uma rota de regresso que só existe na memória de alguém é exatamente o tipo de coisa que sobrevive até o parceiro mudar uma firewall, e depois leva um dia a reconstruir.

Não apanhe o túnel do próprio gateway na política

As regras que escreve para clientes também se aplicam ao tráfego gerado pelo gateway, a menos que o exclua. Uma regra ampla baseada numa marca ou na interface de saída pode apanhar a ligação do próprio gateway ao parceiro, e então o túnel que transporta a política é encaminhado pela política. Isso produz um ciclo ou uma interrupção que parece uma falha do fornecedor.

Limite cada regra tanto quanto o desenho permitir: prefixo de origem, interface de entrada e, onde for suportado, uma marca que só os pacotes de clientes transportam. Depois teste a conetividade do próprio gateway após cada alteração de regras, porque a falha é autorreferente e não aparece num teste a partir do cliente.

A página de manual do ip-rule documenta a semântica do seletor e da prioridade. Combine-a com um teste de consulta por pool e o desenho torna-se verificável, que é a diferença entre um encaminhamento por política que dura um ano e um que todos receiam tocar.