Qui posseeix l’adreça, la ruta, el DNS i el tallafoc en una VPN Linux?

Dos scripts que es barallen per la mateixa ruta és la forma habitual d’un problema de VPN Linux que es registra com un error d’encaminament. Un component crea el dispositiu de túnel, un altre afegeix una ruta per defecte, un tercer reescriu la configuració del resolutor, i un quart recarrega les regles del tallafoc. Qualsevol d’ells pot desfer la feina d’un altre, i el guanyador és simplement qui es va executar l’últim. La pregunta que val la pena respondre no és quin paquet instal·lar, sinó quin component té autoritat per a cada peça d’estat.

Escriviu aquest mapa una vegada, i la majoria de fallades de reconnexió deixen de ser misterioses. Quatre objectes importen: el dispositiu i les seves adreces, les rutes i les regles de política, la configuració DNS i el tallafoc.

El dispositiu i les seves adreces

Un dispositiu de túnel es crea o bé per un gestor que coneix el perfil, o bé per un dimoni que algú va engegar a mà. Tots dos arranjaments funcionen sols; barrejar-los no. Si NetworkManager posseeix el perfil, deixeu que també posseeixi el dispositiu, i no engegueu un OpenVPN sense gestionar contra el mateix nom de túnel.

Anoteu qui elimina el dispositiu quan acaba la sessió. Un dispositiu que sobreviu a la seva sessió és la font més comuna d’adreces obsoletes i de la confusió que les segueix.

Rutes i regles de política

És a les rutes on els conflictes de propietat fan danys visibles. Un gestor de connexions instal·la una ruta per defecte per al túnel més una ruta més específica per a la xarxa remota; després un script escrit a mà afegeix la seva pròpia ruta per defecte amb una mètrica diferent i guanya o perd en silenci segons el moment. Decidiu quines entrades depenen de la connexió, quines són política permanent i quin component les refresca després d’una reconnexió. Després manteniu els altres components fora d’aquesta taula.

Les regles de política mereixen la mateixa claredat, perquè una regla que apunta a una taula que ningú omple produeix un forat negre que sembla exactament un túnel mort. Si existeix una regla per forçar el trànsit en algun lloc, la taula que selecciona ha de ser mantinguda pel mateix propietari.

El DNS sempre és un propietari a part

Un dimoni resolutor s’executa com el seu propi procés sota la seva pròpia identitat, així que no hereta per accident les decisions d’encaminament del túnel. Quan la VPN empeny servidors DNS, alguna cosa ha de traduir-ho en una configuració per enllaç que el resolutor respecti, i alguna cosa ho ha de retirar després.

El mite aquí és que escriure un servidor de noms al perfil canvia on van les consultes. Canvia què se li diu al resolutor, no quin sòcol utilitza el resolutor aigües amunt. Proveu-ho amb una consulta més una cerca de ruta en lloc de confiar en el fitxer.

L’estat del tallafoc, i qui el restaura

Les regles del tallafoc són l’objecte més sovint sobreescrit en un host de VPN. Un gestor pot afegir regles NAT o de reenviament per connexió, mentre que un servei de tallafoc d’arrencada recarrega un conjunt de regles desat i les esborra. Trieu una sola autoritat per a la política i feu que l’altra en sigui consumidora, o accepteu que un reinici canvia el comportament en silenci. Les excepcions lligades a la connexió pertanyen a un fitxer que carrega el mateix propietari, no a una ordre iptables escrita durant la resolució de problemes.

Si les regles han de sobreviure a una reconnexió, digueu-ho explícitament. Si no ho han de fer, digueu-ho també, perquè el proper enginyer assumirà la resposta més convenient.

Cicle de vida: arrencada, reconnexió, desmuntatge

Doneu un propietari a cadascun d’aquests tres moments. A l’arrencada, decidiu què prepara els requisits previs i en quin ordre. En un reinici suau, recordeu que el dispositiu pot sobreviure mentre l’estat de la sessió no, així que ha de córrer un validador en lloc d’un creador. Al desmuntatge, traieu només el que aquesta connexió ha creat, perquè reinicialitzar cada ruta o buidar tot el tallafoc no és el mateix que retirar un sol túnel.

Per a l’observació, ip monitor link address route mostra els canvis del nucli mentre passen, però informa d’esdeveniments en lloc d’intenció: una ruta suprimida no diu res sobre quin procés l’ha suprimida. Combineu-lo amb el mapa de propietat, i un apagada confusa es converteix en una curta llista de candidats.

Les exclusions també tenen un cost. Marcar tota una classe de dispositius com a no gestionada per escapar d’un conflicte lliura aquest estat a ningú, cosa que és una decisió i no una correcció.