Per què una ruta VPN suprimida torna després de reconnectar

Una ruta que has suprimit a mà torna després de la propera reconnexió, i la taula queda exactament com abans. No és un error d’encaminament: alguna cosa recrea l’entrada a partir de la configuració o d’una acció del cicle de vida de la connexió. La majoria de runbooks s’aturen a la taula activa, i per això la supressió sembla funcionar durant un minut i després falla. Identifica el propietari, canvia’l i demostra-ho en una reconnexió.

Qui va instal·lar la ruta

Comença per una llista de candidats en lloc d’una correcció. Un perfil VPN pot portar les seves pròpies rutes, un servidor pot enviar-les en connectar-se, un perfil del gestor de xarxa pot declarar-les, una unitat o un script d’arrencada pot afegir-les, i les implementacions d’IPsec instal·len rutes per als selectors de trànsit que negocien. Les regles d’encaminament per política també poden redirigir el trànsit completament a una altra taula.

El moment en què apareixen les separa més de pressa que l’arqueologia de configuració. Una entrada que apareix en el moment que la interfície puja pertany al client; una que arriba un segon més tard sol venir d’un push del servidor; una que hi és en arrencar pertany a la configuració desada. Registra la taula abans i després d’una connexió, una desconnexió i un reinici, i el patró nomena el propietari. Una ruta que només torna quan el servei es reinicia assenyala una unitat, no la VPN.

Llegeix la taula abans d’editar-la

Mira la visió del propi nucli en lloc d’un fitxer desat. La columna de protocol mostra què va instal·lar cada entrada:

ip route show
ip route show table all
ip rule show

El camp de protocol, la mètrica i el número de taula et diuen si estàs mirant una entrada estàtica, una creada pel nucli o una cosa que hi ha afegit un dimoni. La llista de regles importa perquè una consulta pot sortir completament de la taula principal, cosa que fa que una edició allà sigui invisible per a l’aplicació que estàs depurant. Llegeix la línia d’esquerra a dreta: destinació, porta d’enllaç, dispositiu, protocol i mètrica.

Després pregunta al nucli quina ruta faria servir realment. Una adreça protegida és una sonda millor que una de pública:

ip route get 10.20.5.7

Canvia el propietari, no el símptoma

Un cop es coneix el propietari, el canvi pertany a aquest propietari. Elimina la ruta del perfil del client, corregeix la ruta enviada al servidor o edita la connexió del gestor de xarxa en lloc d’afegir una ruta persistent que competeixi i guanyi per mètrica. Dues regles que lluiten entre elles produeixen una taula que ningú no podrà explicar després.

Mantén l’exclusió de l’extrem. Una ruta d’amfitrió que envia l’adreça pública pròpia del servidor VPN a través de la porta d’enllaç física és el que manté fluint els paquets exteriors del túnel; si l’elimines, el túnel intenta portar-se a si mateix. En un perfil de túnel dividit, la mateixa cura s’aplica a les subxarxes locals que han d’evitar el túnel.

Reconnecta i verifica tots dos camins

Reconnecta i després comprova les dues destinacions en una sola passada. L’adreça protegida i l’extrem exclòs responen a preguntes diferents:

ip route get 10.20.5.7
ip route get 198.51.100.20

La primera s’hauria de resoldre per la interfície del túnel i la segona per la porta d’enllaç física. Si totes dues es resolen pel túnel, falta l’exclusió; si no ho fa cap, el canvi de perfil no ha pres efecte i estàs mirant un propietari diferent del que pensaves.

Anota el propòsit de la ruta, el seu propietari i quant de temps ha de viure. Aquesta nota és el que evita que la propera persona repeteixi el mateix cicle de suprimir i reconnectar.