VPN site a site baseada em rotas vs. baseada em políticas: o que difere

Os dois desenhos protegem o mesmo tráfego com a mesma maquinaria IPsec, e diferem no que decide qual pacote entra no túnel. Numa conexão baseada em políticas, os seletores de tráfego negociados fazem esse trabalho; numa baseada em rotas, faz uma rota que aponta para uma interface de túnel. Confundir as duas produz a conversa de suporte familiar em que o túnel se declara estabelecido enquanto a aplicação não chega a nada. A distinção importa mais quando adiciona uma rede, executa um protocolo de encaminhamento ou depura um caminho que sai silenciosamente pela saída errada.

Duas formas de decidir o que entra no túnel

Uma VPN baseada em políticas constrói uma política de segurança que corresponde aos prefixos de origem e destino e depois cifra tudo o que se enquadra. O par tem de negociar seletores compatíveis, por isso o âmbito efetivo acaba por ser a interseção do que ambos os lados propuseram. Nada fora dessa interseção fica protegido, diga o que disser a tabela de encaminhamento.

Uma VPN baseada em rotas cria uma interface que representa o túnel e deixa a tabela de encaminhamento enviar tráfego para ela. O daemon IKE continua a instalar o estado e a política por interface, e é esse o detalhe que se salta quando se decide que as rotas substituíram a cifra. Os dois desenhos cifram com IPsec; só o mecanismo de seleção difere.

Leia a comparação abaixo como um conjunto de assinaturas de falha e não como um quadro de pontuação, porque nenhuma coluna vence por si.

Baseada em políticas: o seletor é o contrato

Os seletores são negociados, não apenas configurados. Proponha 10.10.0.0/16 de um lado e 10.10.1.0/24 do outro, e a associação cobre aquilo em que a negociação parou, enquanto todos os outros anfitriões ficam de fora.

Leia o estado instalado em vez do ficheiro de configuração. Num par Linux, as próprias tabelas do kernel são a verdade de base, e mostram o que sobreviveu à negociação. Uma política que nomeia os prefixos corretos sem estado correspondente significa que a associação nunca subiu. Estado emparelhado com uma política para o prefixo errado é o problema oposto, e produz o túnel que parece saudável enquanto uma sub-rede não chega a nada.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Compare as duas saídas com os prefixos que julga estar a proteger. Essa única comparação resolve a maioria dos relatos de um túnel a funcionar com um servidor inalcançável. Também indica qual par alterar, porque a divergência costuma ser visível apenas numa direção.

Baseada em rotas: a interface é o contrato

Uma interface XFRM dá ao túnel um nome e uma identidade, e o tráfego chega-lhe porque a tabela de encaminhamento o diz. Vários prefixos remotos passam então a ser um problema de encaminhamento e não um problema de seletor, e um protocolo de encaminhamento pode anunciá-los. Esse é o ganho real, não a cifra.

A interface não elimina a necessidade de política. O daemon instala regras por interface ligadas à identidade da interface, pelo que um pacote que chega à interface errada continua a falhar. Um endereço de origem que o par não aceitar também falha, mesmo com uma rota perfeita. Baseada em rotas significa que a rota decide a entrada, não que a política desapareceu.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Observe os contadores da interface depois de a rota estar no lugar. Uma rota que existe enquanto os contadores ficam em zero significa que nada está a ser encaixado no túnel, o que normalmente aponta para um estado em falta e não para uma rota em falta.

Onde os dois desenhos realmente divergem

Adicionar uma rede é o teste mais limpo de qual modelo lhe serve. Um desenho baseado em rotas adiciona uma rota e no máximo alarga o seletor uma vez, enquanto um desenho baseado em políticas edita pares de prefixos nos dois pares e renegocia. Duas sub-redes estáveis tornam essa edição trivial, e vinte tornam-na um projeto.

Nenhum dos modelos substitui uma firewall, e as comparações costumam parar antes deste ponto. Um seletor largo ou uma rota larga decidem o que é cifrado, não o que é permitido.

O comportamento do MTU também difere na prática. A encapsulação reduz a carga útil disponível, e uma interface baseada em rotas transporta o seu próprio MTU, pelo que fixar o MSS nas duas portas de ligação evita o sintoma do buraco negro em que chegam respostas pequenas e as grandes desaparecem. Os túneis baseados em políticas encontram a mesma parede do outro lado, porque um seletor não diz nada sobre o tamanho do pacote. Defina a fixação de propósito em vez de culpar o par.

Migrar sem perder o caminho de volta

Registe os pares de prefixos existentes antes de mudar seja o que for, depois mova um caminho de aplicação e acompanhe-o de ponta a ponta. Um túnel que se estabelece não é um túnel que encaminha, e a diferença aparece na direção da resposta.

Quando os pares ligam mas os anfitriões da LAN não, inspecione a rota de retorno e o endereço de origem que o anfitrião remoto vai usar. Um anfitrião com duas interfaces pode responder pela errada, e nenhuma alteração de seletor repara isso. Capture tráfego nas duas pontas antes de editar algoritmos.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Mantenha um caminho de gestão que não dependa do túnel enquanto trabalha. Reverter é mais fácil quando o próprio acesso da porta de ligação não viaja na conexão que está a depurar.