Com distingir les rutes empenyudes pel VPN de les estàtiques a Linux

Un prefix apareix a l'ordinador portàtil quan el túnel s'aixeca, així que sembla que l'hagi instal·lat el VPN. Potser sí, però el mateix resultat pot venir d'un script de client que s'executa en connectar, d'un perfil de connexió que llista la subxarxa o d'una ruta estàtica que hi era des del principi i que només va començar a funcionar quan l'interfície va existir. Triar el propietari equivocat fa que la ruta torni després de cada neteja, i la persona següent repeteix la mateixa solució. La seqüència següent separa els tres casos abans de canviar res.

Pas 1: anomeneu el mecanisme que instal·la prefixos

Protocols diferents forneixen abastabilitat de maneres diferents, i anomenar-ho tot anunci amaga la distinció. Un servidor OpenVPN empeny una directiva de ruta pel canal de control i el client la instal·la tret que un filtre pull la bloquegi. Una configuració de WireGuard llista els prefixos permesos localment, que el client fa servir tant per a l'encaminament de claus criptogràfiques com per a les rutes que afegeix. Un túnel IPsec acorda selectors de trànsit amb el parell, i el nucli instal·la rutes a partir d'aquests selectors.

Identifiqueu quin d'aquests fa servir el vostre túnel abans de llegir cap taula. Una ruta empenyuda en connectar no és un anunci d'un protocol d'encaminament i no promet que el prefix sigui abastable darrere l'extrem llunyà. Anoteu el mecanisme al costat del prefix, perquè decideix on va la solució.

Pas 2: compareu la taula durant una connexió

Desa la taula principal amb el túnel baixat, aixeca'l, torna-la a desar i compara les dues captures. Tot el que ha aparegut pertany al cicle de vida de la connexió, i tot el que s'ha quedat pertany a la configuració local.

Captura-la amb ip route show table main > /tmp/route-down.txt, connecta i torna a capturar. Fes el mateix per a ip -6 route si el lloc fa servir IPv6, perquè un prefix que hi falta produeix fallades que semblen no tenir relació amb l'encaminament.

Pas 3: llegiu la mètrica, no només la presència

Dues entrades per al mateix prefix poden coexistir, i el nucli tria la mètrica més baixa. Una ruta estàtica amb mètrica 50 continuarà guanyant una ruta empenyuda a 100 encara que totes dues siguin visibles, i per això «la ruta hi és» i «el trànsit la fa servir» són afirmacions diferents.

Pregunteu directament al nucli amb ip route get 10.20.5.7 i llegiu la interfície que indica. Si el trànsit surt per l'adaptador físic mentre una ruta del túnel seu a la taula, ho explica la mètrica o la longitud del prefix, no el client VPN. Repetiu la consulta per a un amfitrió que sabeu que viu darrere el túnel i per a un que sabeu que no, i la diferència mostra si la divisió es comporta com cal.

Pas 4: trobeu les entrades que sobreviuen al túnel

Les rutes estàtiques sobreviuen a una desconnexió per disseny, i d'aquí vénen les entrades obsoletes. Una ruta persistent que apunta a una interfície que ja no existeix pot engolir una subxarxa en silenci, i una que apunta a un nom d'interfície reutilitzat pot enviar trànsit privat per la porta equivocada després d'un reinici.

Comproveu el costat persistent al lloc que fa servir la vostra distribució, sigui una unitat de systemd-networkd, un perfil de NetworkManager o un script al directori up del client. Arreglar la taula viva amb ip route del només aguanta fins a la propera connexió. Tracteu aquesta supressió com una prova de la hipòtesi i no com la reparació.

Quan l'extrem llunyà forneix una cobertura equivocada, plantegeu-ho a l'operador en lloc de filtrar-ho tot. Descartar tots els paràmetres empenyuts també descarta el DNS i la política de túnel dividit de què depèn el perfil.

Pas 5: confirmeu el camí de tornada abans de culpar el client

Per a un lloc a lloc o una subxarxa darrere el túnel, l'extrem llunyà necessita una ruta de tornada a l'adreça del vostre client i el reenviament activat a la passarel·la. Un camí d'anada només sembla exactament un error d'encaminament del client, tret que l'apretada de mans i el paquet de sortida tots dos tenen èxit.

El filtratge de camí invers afegeix una segona trampa a les passarel·les Linux. Una resposta que arriba per una interfície diferent de la que la ruta prediu és descartada pel mode estricte, i els camins asimètrics per dos proveïdors ho desencadenen de manera fiable. Els comptadors de descart de la passarel·la, no del client, us diuen si el filtratge n'és la causa.

Pas 6: proveu el recurs, no el ping

Un cop la ruta triada és correcta, obriu el recurs real i confirmeu el trànsit de tornada. Una resposta de ping demostra el camí en una direcció i res sobre el servei, i un servei que respon en una connexió en memòria cau demostra encara menys.

Després repetiu tota la comprovació després de reconnectar. El valor de la seqüència és que prediu què farà la propera connexió, i per això tant la comparació com la mètrica pertanyen al tiquet.