VPN de sitio a sitio baseada en rutas fronte a baseada en políticas: en que difiren
O IPsec baseado en políticas elixe o tráfico cun selector; o baseado en rutas envíao por unha interface de túnel. Ambos seguen necesitando regras de devasado e unha ruta de resposta.
Ambos deseños protexen o mesmo tráfico coa mesma maquinaria IPsec, e difiren en que decide que paquete entra no túnel. Nunha conexión baseada en políticas fan ese traballo os selectores de tráfico negociados; nunha baseada en rutas faino unha ruta que apunta a unha interface de túnel. Confundir as dúas produce o habitual fío de soporte no que o túnel se declara establecido mentres a aplicación non chega a nada. A distinción importa sobre todo cando engades unha rede, executas un protocolo de encamiñamento ou depuras un camiño que sae en silencio pola saída equivocada.
Dúas formas de decidir que entra no túnel
Unha VPN baseada en políticas constrúe unha política de seguridade que coincide cos prefixos de orixe e destino, e despois cifra o que encaixe. O par debe negociar selectores compatibles, así que o alcance efectivo acaba sendo a intersección do que propuxeron ambos os dous lados. Nada fóra desa intersección queda protexido, diga o que diga a táboa de encamiñamento.
Unha VPN baseada en rutas crea unha interface que representa o túnel e deixa que a táboa de encamiñamento lle envíe tráfico. O daemon IKE segue instalando o estado e a política por interface, que é o detalle que se omite cando se decide que as rutas substituíron o cifrado. Ambos deseños cifran con IPsec; só cambia o mecanismo de selección.
Le a comparación de abaixo como un conxunto de sinaturas de fallo e non como un marcador, porque ningunha columna gaña en abstracto.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
Baseada en políticas: o selector é o contrato
Os selectores négocianse, non só se configuran. Proponse 10.10.0.0/16 dun lado e 10.10.1.0/24 do outro, e a asociación cubrirá o que acordou a negociación mentres todos os demais hosts quedan fóra.
Le o estado instalado en lugar do ficheiro de configuración. Nun par Linux as propias táboas do kernel son a verdade básica, e amosan que sobreviviu á negociación. Unha política que nomea os prefixos correctos sen estado coincidente significa que a asociación nunca se levantou. O estado xunto cunha política para o prefixo equivocado é o problema oposto, e produce o túnel que parece san mentres unha subrede non chega a nada.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasCompara ambas as saídas cos prefixos que cres que protexes. Esa única comparación resolve a maioría dos informes dun túnel que funciona cun servidor inalcanzable. Tamén sinala que par hai que cambiar, xa que o desaxuste adoita verse só nunha dirección.
Baseada en rutas: a interface é o contrato
Unha interface XFRM dálle ao túnel un nome e unha identidade, e o tráfico chega a ela porque a táboa de encamiñamento o di. Varios prefixos remotos pasan entón a ser un problema de encamiñamento en vez dun problema de selector, e un protocolo de encamiñamento pode anunciarlos. Esa é a ganancia real, non o cifrado.
A interface non elimina a necesidade de política. O daemon instala regras por interface ligadas á identidade da interface, así que un paquete que chega á interface equivocada segue fallando. Un enderezo de orixe que o par non aceptará tamén falla, mesmo cunha ruta perfecta. Baseada en rutas significa que a ruta decide a entrada, non que a política desaparecese.
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.10Vixía os contadores da interface unha vez que a ruta estea posta. Unha ruta que existe mentres os contadores seguen a cero significa que nada se está encaixando no túnel, o que adoita apuntar a un estado ausente máis que a unha ruta ausente.
Onde diverxen realmente os dous deseños
Engadir unha rede é a proba máis limpa de que modelo che convén. Un deseño baseado en rutas engade unha ruta e como moito amplía o selector unha vez, mentres que un baseado en políticas edita pares de prefixos nos dous pares e renegocia. Dúas subredes estables fan trivial esa edición, e vinte convértena nun proxecto.
Ningún dos modelos substitúe un devasado, e as comparacións adoitan deterse antes deste punto. Un selector amplo ou unha ruta ampla deciden que se cifra, non que se permite.
O comportamento do MTU tamén difire na práctica. A encapsulación reduce a carga útil e unha interface baseada en rutas leva o seu propio MTU, así que fixar o MSS en ambas as pasarelas evita o síntoma de burato negro no que chegan as respostas pequenas e desaparecen as grandes. Os túneles baseados en políticas atopan o mesmo muro desde o outro lado, porque un selector non di nada sobre o tamaño do paquete. Fixa o valor a propósito en vez de culpar o par.
Migrar sen perder a ruta de volta
Rexistra os pares de prefixos existentes antes de cambiar nada, despois move unha ruta de aplicación e obsérvaa de extremo a extremo. Un túnel que se establece non é un túnel que reenvía, e a diferenza aparece na dirección de resposta.
Cando os pares conectan pero os hosts da LAN non, inspecciona a ruta de resposta e o enderezo de orixe que usará o host remoto. Un host con dúas interfaces pode responder pola equivocada, e ningún cambio de selector repara iso. Captura tráfico nos dous extremos 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-connsMantén unha ruta de xestión que non dependa do túnel mentres traballas. Reverter é máis fácil cando o propio acceso da pasarela non viaxa sobre a conexión que estás depurando.