Taula d'encaminament enfront de la consulta real: on va el trànsit VPN

Un abocament de la taula d'encaminament és el diagnòstic menys útil en la resolució de problemes de VPN i el que més sovint s'enganxa. Quaranta línies de prefixos us diuen què podia fer la màquina, no què va fer per a la sol·licitud que va fallar. El mecanisme que realment voleu és la consulta: donats aquesta origen i aquesta destinació, quina regla va coincidir, quina taula es va consultar i quina interfície i salt següent van sortir. Partiu d'una destinació i d'una origen, llegiu després la taula amb aquesta pregunta a la mà, i la mateixa sortida es converteix en evidència en lloc de soroll.

Una taula és un conjunt de candidats, no una decisió

Cada entrada descriu un prefix i què fer amb el trànsit que hi coincideix: enviar-lo a una interfície, lliurar-lo a un salt següent o descartar-lo. Res en aquesta llista no està ordenat per intenció, i l'entrada que a una persona li sembla més específica no sempre és la que el nucli selecciona, perquè la selecció segueix la coincidència de prefix més llarga i, entre prefixos iguals, la mètrica.

Així que el primer pas és preguntar al nucli en lloc de llegir la llista. L'ordre de consulta respon per a una destinació, i amb un argument d'origen respon per al parell exacte que faria servir una connexió reenviada o vinculada:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Cada adreça anterior és un exemple de documentació. El punt és la forma de la resposta: interfície, adreça d'origen triada, porta d'enllaç i la taula d'on va venir l'entrada. Si aquesta sortida no coincideix amb la interfície que esperàveu, heu localitzat el problema amb una ordre, i cap quantitat de llegir la taula completa us hauria dit quin candidat va guanyar.

La consulta recorre primer regles, després taules

A Linux la decisió té dues etapes. Les regles de política s'avaluen per ordre de prioritat, i la primera regla que coincideix nomena una taula a consultar; aquesta taula fa llavors la coincidència de prefix més llarga. Una regla pot coincidir per origen, destinació, marca de tallafocs, interfície o una combinació, i per això un abocament de la taula principal pot ser perfectament exacte i completament irrellevant per al paquet que investigueu.

ip rule show
ip route show table all | head -40
ip route show table 100

Si una regla envia trànsit del vostre pool VPN a la taula 100, llavors la taula 100 és la que importa, i la taula principal és un esquer. Aquest és també el mecanisme rere l'encaminament basat en origen en un encaminador: la mateixa destinació pot tenir dues respostes diferents segons d'on vingui el paquet, i només la consulta amb un argument d'origen revela quina s'aplica.

IPv6 té les seves pròpies regles i taules. Un disseny que executa les dues famílies necessita les dues consultes, i una resposta IPv4 que funciona no diu res sobre el camí v6 que un client de doble pila pot preferir.

Què instal·la el client VPN

Els clients normalment no substitueixen la ruta per defecte, perquè fer-ho trencaria el propi camí exterior del túnel. Instal·len una cosa més específica que guanya per longitud de prefix: una parella de mig-defecte que cobreixen 0.0.0.0/1 i 128.0.0.0/1 és el truc clàssic, ja que tots dos són prefixos més llargs que 0.0.0.0/0 i junts cobreixen tot l'espai. Altres instal·len prefixos privats concrets més una regla de política, i alguns afegeixen una marca perquè només es capturi el trànsit seleccionat.

Per això "la VPN no em va canviar la ruta per defecte" no és prova de fallada. Comproveu què va afegir de fet i si la destinació en qüestió cau dins d'aquests prefixos:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dues mig-rutes són fàcils de passar per alt en un abocament perquè no semblen un defecte. Una configuració de túnel dividit que va oblidar incloure un prefix produeix exactament el símptoma que perseguiu: l'aplicació que hauria d'usar el túnel resol i es connecta localment en lloc d'això. Compareu els prefixos instal·lats amb les destinacions que l'usuari realment necessita, no amb les adreces que vau provar per casualitat. Una llista de túnel dividit que cobreix el servidor de fitxers però no el seu resolutor produeix una connexió que resol a una adreça pública i després falla l'autenticació, cosa que sembla un problema de contrasenya i és un problema de ruta.

La ruta exterior també ha de sobreviure

El túnel és ell mateix trànsit. Els paquets que porten la càrrega encapsulada van a l'adreça del parell per la interfície física, i aquest camí no s'ha d'encaminar de tornada dins del túnel. Quan ho fa, obteniu la fallada característica en què el túnel s'estableix i després deixa de passar trànsit, perquè el transport del túnel és ara dins del túnel.

Comproveu l'adreça del parell tal com vau comprovar la destinació interior, i confirmeu que resol a la interfície física i no al túnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Una ruta recursiva, una regla de política que atrapa el parell o una ruta per defecte substituïda per un client de túnel complet són les tres causes habituals. Totes tres són visibles en la consulta exterior, i cap d'elles no és visible en un abocament de la taula principal pres després del fet.

Què no us pot dir la sortida d'encaminament

Una consulta correcta significa que el nucli enviaria el paquet a un lloc raonable. No significa que el tallafocs ho permeti, la política IPsec ho cobreixi, la regla NAT ho tradueixi o el costat remot tingui una ruta de retorn. Cadascuna d'aquestes és una etapa posterior, i notes de reenviament de strongSwan descriuen la cadena que un paquet ha de passar als dos extrems.

Tampoc no té en compte la vinculació a nivell d'aplicació. Un procés es pot vincular a una interfície, establir una marca o usar el seu propi resolutor i connectar-se amb un nom que resol de manera diferent del que vau provar. Quan la consulta és correcta i la connexió encara falla, la pregunta següent és quin procés la fa i si aquest procés veu la mateixa taula que vós.

Així que manteniu el diagnòstic ordenat: nomeu la destinació i l'origen, executeu la consulta, llegiu només la taula i la regla que la consulta ha nomenat, i després proveu l'etapa següent. Aquesta seqüència manté una investigació d'encaminament en minuts i deixa un registre que algú altre pot seguir, cosa que una taula enganxada mai no fa.