Uma tabela VPN vazia não bloqueia nada por si só

Uma regra de política envia os pacotes marcados para uma tabela dedicada, e a expectativa habitual é que a perda da rota VPN os bloqueie. O mecanismo faz outra coisa. Quando uma tabela não contém nenhuma rota correspondente, a pesquisa continua para a regra seguinte em vez de parar, e a tabela main ainda mantém uma rota predefinida comum para o uplink. O resultado é uma configuração que parece fail-closed e se comporta como fail-open.

Nada está quebrado; é assim que o encaminhamento baseado em políticas é especificado.

A pesquisa continua quando uma tabela não tem nada

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Pegue esse conjunto de regras: uma pesquisa marcada vai para a tabela 42, e uma regra posterior envia a mesma marca para uma tabela chamada default. Enquanto a tabela 42 mantém uma rota predefinida utilizável, a primeira pesquisa fornece o caminho. Quando essa rota desaparece e nada mais na tabela 42 corresponde, a pesquisa não se torna um descarte; o processamento passa para a regra seguinte, e quando essa também não encontra nada, chega à tabela main. Nada nessa sequência informa qual regra produziu a resposta final, portanto uma conexão que funciona parece uma política que funciona.

A tabela 253, convencionalmente chamada default, é uma tabela de encaminhamento comum e normalmente está vazia. Seu nome não é uma instrução para descartar pacotes, e não é a mesma coisa que uma rota de destino predefinida dentro de uma tabela.

As ações terminais terminam a pesquisa

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Uma regra terminal pode seguir a pesquisa VPN em vez de uma pesquisa numa tabela vazia. Com a mesma marca, uma ação prohibit colocada depois da regra da tabela 42 termina a pesquisa quando essa tabela não devolve nada, retornando uma rejeição administrativa em vez de oferecer à tabela main outra chance. Unreachable e blackhole também são terminais, com comportamento de erro diferente para o remetente.

Uma rota do tipo throw é diferente: dentro dessa tabela comporta-se como se nada tivesse correspondido, portanto as regras posteriores ainda têm a sua vez. Isso torna throw útil para um retrocesso deliberado e errado como bloqueio final.

Verifique com a marca e a interface reais

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Inspecione as regras e a tabela reais em vez de um diagrama, e depois consulte o fluxo com o contexto de origem, marca e entrada que ele realmente tem. Uma pesquisa somente leitura dirigida a um destino, à qual se informam o endereço de origem, a interface e a marca, relata a rota que o kernel escolheria sem que um pacote saia. Fornecer uma marca na consulta não prova que o firewall marque o tráfego real; essa é uma verificação separada das regras de marcação. Confirme o valor com um contador ou um registo antes de tirar conclusões da consulta.

Os pedidos gerados localmente precisam do seu próprio contexto, porque o seu caminho de marcação difere frequentemente do do tráfego encaminhado. Verifique-os com a interface de saída que a aplicação realmente usaria.

Dois estados de falha, não um

Um estado de falha é o desaparecimento da rota VPN e o tráfego a cair para o uplink. Um túnel morto cuja rota permanece instalada é outro: os pacotes continuam dirigidos a um caminho inutilizável em vez de caírem, e o sintoma é perda silenciosa em vez de uma ligação direta visível. Teste ambos, e também o comportamento no arranque, na reconexão e na paragem do serviço.

Uma regra assim só ajuda enquanto existe e enquanto os pacotes ainda transportam a marca que a seleciona. Um script de encerramento que elimine a regra, ou um caminho que remova a marca, restaura o comportamento aberto. Vale a pena ensaiar essas transições.

Aplique a política ao IPv6 separadamente e mantenha explícitas, em vez de implícitas, as exceções de ponto final aprovadas.