VPN de lloc a lloc basada en rutes o en polítiques: què hi ha de diferent

Els dos dissenys protegeixen el mateix trànsit amb la mateixa maquinària IPsec, i difereixen en què decideix quin paquet entra al túnel. En una connexió basada en polítiques ho fan els selectors de trànsit negociats; en una de basada en rutes ho fa una ruta que apunta a una interfície de túnel. Confondre les dues coses produeix el fil de suport habitual en què el túnel es declara establert mentre l’aplicació no arriba enlloc. La distinció importa sobretot quan afegiu una xarxa, executeu un protocol d’encaminament o depureu un camí que surt en silenci per la sortida equivocada.

Dues maneres de decidir què entra al túnel

Una VPN basada en polítiques construeix una política de seguretat que coincideix amb els prefixos d’origen i destinació, i després xifra tot el que hi encaixa. El par ha de negociar selectors compatibles, així que l’abast efectiu acaba sent la intersecció del que van proposar les dues bandes. Res fora d’aquesta intersecció no queda protegit, digui el que digui la taula d’encaminament.

Una VPN basada en rutes crea una interfície que representa el túnel i deixa que la taula d’encaminament hi enviï trànsit. El dimoni IKE encara instal·la l’estat i la política per interfície, i aquest és el detall que hom omet quan decideix que les rutes han substituït el xifratge. Els dos dissenys xifren amb IPsec; només canvia el mecanisme de selecció.

Llegiu la comparació de sota com un conjunt de signatures de fallada i no com un marcador, perquè cap columna guanya per si sola.

Basada en polítiques: el selector és el contracte

Els selectors es negocien, no només es configuren. Proposeu 10.10.0.0/16 d’una banda i 10.10.1.0/24 de l’altra, i l’associació cobrirà allò on va quedar la negociació mentre tota la resta d’amfitrions queda fora.

Llegiu l’estat instal·lat en lloc del fitxer de configuració. En un par Linux, les taules del nucli són la veritat bàsica, i mostren què va sobreviure a la negociació. Una política que anomena els prefixos correctes sense estat coincident significa que l’associació no es va aixecar mai. L’estat aparellat amb una política per al prefix equivocat és el problema oposat, i produeix el túnel que sembla sa mentre una subxarxa no arriba enlloc.

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

Compareu les dues sortides amb els prefixos que creieu que protegiu. Aquesta única comparació resol la majoria d’informes d’un túnel que funciona amb un servidor inabastable. També assenyala quin par cal canviar, perquè el desajustament normalment només es veu en una direcció.

Basada en rutes: la interfície és el contracte

Una interfície XFRM dona al túnel un nom i una identitat, i el trànsit hi arriba perquè la taula d’encaminament ho diu. Llavors diversos prefixos remots esdevenen un problema d’encaminament i no un problema de selector, i un protocol d’encaminament els pot anunciar. Aquest és el guany real, no el xifratge.

La interfície no elimina la necessitat de política. El dimoni instal·la regles per interfície lligades a la identitat de la interfície, de manera que un paquet que arriba a la interfície equivocada falla igualment. Una adreça d’origen que el par no acceptarà també falla, fins i tot amb una ruta perfecta. Basada en rutes vol dir que la ruta decideix l’entrada, no que la política hagi desaparegut.

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

Vigileu els comptadors de la interfície quan la ruta ja és al lloc. Una ruta que existeix mentre els comptadors es queden a zero vol dir que no s’hi encaixa res al túnel, cosa que normalment apunta a un estat absent més que a una ruta absent.

On divergeixen realment els dos dissenys

Afegir una xarxa és la prova més neta de quin model us convé. Un disseny basat en rutes afegeix una ruta i com a màxim eixampla el selector una vegada, mentre que un disseny basat en polítiques edita parells de prefixos als dos pars i renegocia. Dues subxarxes estables fan trivial aquesta edició, i vint la converteixen en un projecte.

Cap dels models no substitueix un tallafocs, i les comparacions solen aturar-se abans d’aquest punt. Un selector ample o una ruta àmplia decideixen què es xifra, no què es permet.

El comportament de l’MTU també difereix a la pràctica. L’encapsulament redueix la càrrega útil i una interfície basada en rutes porta la seva pròpia MTU, així que fixar l’MSS a les dues passarel·les evita el símptoma del forat negre en què arriben les respostes petites i desapareixen les grans. Els túnels basats en polítiques troben la mateixa paret des de l’altre costat, perquè un selector no diu res sobre la mida del paquet. Fixeu el valor a propòsit en lloc de culpar el par.

Migrar sense perdre la ruta de tornada

Enregistreu els parells de prefixos existents abans de canviar res, després moveu un camí d’aplicació i observeu-lo de punta a punta. Un túnel que s’estableix no és un túnel que reenvia, i la diferència apareix en la direcció de la resposta.

Quan els pars es connecten però els amfitrions de la LAN no, inspecteu la ruta de retorn i l’adreça d’origen que farà servir l’amfitrió remot. Un amfitrió amb dues interfícies pot respondre per la incorrecta, i cap canvi de selector no ho repara. Captureu trànsit als dos extrems abans d’editar algorismes.

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

Manteniu un camí de gestió que no depengui del túnel mentre treballeu. Torna enrere és més fàcil quan l’accés propi de la passarel·la no viatja sobre la connexió que esteu depurant.