Què canvia el routing per política al trànsit VPN, i què no

El routing per política respon una pregunta diferent de la que fan la majoria de notes de resolució de problemes. La taula principal diu on va una destinació; les regles de política diuen quina taula es consulta en absolut, i poden decidir-ho a partir de l'adreça d'origen, d'una marca de paquet, o de la interfície per la qual ha arribat un paquet. Quan un túnel es comporta de manera inconsistent, el conjunt de regles sovint n'és la causa i la taula d'encaminament sovint no.

Les regles trien la taula, després la taula tria la ruta

Cada regla porta una prioritat, una condició de coincidència i una taula de destinació. El nucli recorre les regles per ordre de prioritat i s'atura a la primera coincidència, després fa una cerca ordinària del prefix més llarg en aquella taula. Una regla que apunta a una taula buida cau al que triï la regla següent, i així és com una regla escrita amb cura pot semblar que no fa res.

Per això bolcar la taula principal poques vegades explica un client VPN que funciona. Els clients solen inserir regles amb números de prioritat baixos, molt abans de la regla per defecte de la taula principal, de manera que el paquet no arriba mai a la ruta que estàveu mirant. Baixar una mètrica a la taula principal no canvia res per al trànsit que ja s'havia desviat.

Una regla també pot convertir un prefix en un forat negre o fer-lo inabastable a propòsit. Alguns clients afegeixen aquesta regla com a interruptor de seguretat, i llavors la caiguda sembla un túnel trencat en lloc d'un de configurat.

Llegiu el conjunt de regles com una seqüència, no com una llista

Imprimiu les regles amb les seves prioritats i les taules a què fan referència, i després imprimiu cada taula que porti una ruta per defecte o una ruta de túnel. L'ordre és la part que importa, i és la part que una captura de pantalla sol ometre:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Les dues últimes ordres són les que converteixen una teoria en una observació, perquè pregunten què faria el nucli per a aquell origen i aquella marca. Si la resposta canvia quan canvia la marca, hi ha una regla basada en la marca en joc i qualsevol prova que ometi la marca està provant un paquet diferent. La connexió exterior mereix una regla pròpia. Un túnel que encamina tot el trànsit a través seu ha d'excloure l'adreça de punt final a què es connecta, o els paquets xifrats es tornen a enviar al túnel que acaben de deixar. La majoria de clients insereixen aquesta exclusió automàticament, i un conjunt de regles editat a mà és on desapareix.

Marques i sockets: dues maneres com els clients divideixen el trànsit

Alguns clients marquen paquets al tallafoc i afegeixen una regla que coincideix amb la marca. D'altres fan servir encaminament a nivell de socket, posant una ruta al socket abans que es connecti. El primer és visible a ip rule; el segon no, i no apareixerà en una cerca genèrica.

Si un programa de prova es comporta de manera diferent de l'aplicació que ha de representar, comproveu si l'aplicació posa una marca o s'enllaça a un dispositiu. Aquesta diferència no és cap misteri un cop s'anomena el mecanisme, i explica per què un curl des d'un shell i una pestanya del navegador poden prendre camins diferents a la mateixa màquina. Totes dues tècniques són encaminament per política en sentit ampli: trien un camí amb una cosa que no és la destinació. Cap de les dues autoritza el trànsit, i cap substitueix les regles del tallafoc ni les credencials que el peer espera.

Resseguiu la propietat abans d'afegir una altra regla

Les regles les instal·la alguna cosa. Un client VPN, un gestor de xarxa i un script escrit a mà poden afegir regles en arrencar, i la lògica de reconnexió pot deixar enrere el conjunt anterior. Dues regles obsoletes d'un perfil anterior seguiran dirigint el trànsit molt després que el perfil s'hagi suprimit.

Trobeu quin procés posseeix la regla per la seva prioritat i la seva forma, i comproveu si aquest propietari reescriu el conjunt a cada connexió. Si ho fa, una regla manual afegida avui desapareix demà, i la correcció pertany a la configuració del client i no a un fitxer d'historial del shell. Netejar tot el conjunt de regles per provar és una drecera temptadora amb un cost previsible: també elimina les regles que el client necessita per mantenir el seu propi túnel. Esborreu una regla alhora, o proveu en una màquina que pugueu reiniciar.

Demostreu l'abast amb dos fluxos, no amb un

Una correcció només es verifica amb un flux que hauria de resultar afectat i un flux que no. Trieu una destinació que la política encamini al túnel, i una que hagi de quedar fora, i després compareu les cerques i les captures de tots dos:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Quan les dues cerques retornen interfícies diferents, la regla fa alguna cosa. Quan retornen la mateixa interfície, la regla coincideix més àmpliament del que es volia, i aquesta és la fallada que envia en silenci una subxarxa sencera per un túnel pensat per a una sola aplicació.

Anoteu les prioritats de les regles i el servei propietari al tiquet, juntament amb les dues adreces de prova. La persona següent tindrà llavors un parell reproduïble en lloc d'una descripció d'un símptoma, i podrà dir en un minut si l'encaminament per política encara hi és.