És més simple el túnel complet que una llista llarga de túnel dividit?

Una llista de túnel dividit comença amb tres aplicacions i acaba cobrint la major part de la màquina, i cada línia nova és l’excepció d’algú. En aquest punt, la llista s’ha convertit silenciosament en un valor per defecte amb passos extra. El túnel complet inverteix la disposició: tot entra al túnel tret que una exclusió documentada digui el contrari. Si això és més simple depèn de la passarel·la i dels serveis locals que trencaríeu.

Comenceu comptant les regles que manteniu

Compteu les entrades i després compteu quantes tenen un propietari amb nom i una data de l’última verificació. El segon número és el que importa, perquè una excepció que no té amo no es pot avaluar quan el programari a què fa referència es reanomena o es substitueix. Les regles lligades a un camí executable fallen en silenci després d’una actualització, i la fallada sembla una VPN inestable en lloc d’una regla obsoleta. Escriviu la llista abans de tenir-ne una opinió.

Cada entrada hauria de respondre tres preguntes: què es trenca sense ella, qui ho va decidir i com us n’adonaríeu si el motiu ha caducat. Les entrades que no poden respondre les tres són candidates a ser esborrades més que migrades, i esborrar-les primer fa honesta la comparació posterior.

Si la majoria d’entrades encaminen una part gran del trànsit, ja executeu un túnel complet amb una càrrega de manteniment afegida. Llavors la decisió és on viu el valor per defecte, no si n’hi ha d’haver un.

Comproveu si la passarel·la pot portar el valor per defecte

El túnel complet mou cada paquet a un sol dispositiu, cosa que canvia alhora la càrrega de CPU d’aquest dispositiu, la taula conntrack, la traducció d’adreces i el requisit d’amplada de banda de pujada. Una passarel·la que servia còmodament unes quantes subxarxes internes potser no estava dimensionada per a tota la navegació d’un usuari. Mireu el nombre més gran de sessions simultànies que espereu, no la mitjana, perquè el pic és el que es trenca primer.

ip -s link show dev tun0
conntrack -C
ss -s

Mesureu la mateixa càrrega abans i després del canvi en lloc de raonar a partir d’especificacions. Una sola tarda d’ús ordinari en una màquina mostrarà si la passarel·la és a prop d’un límit, i no costa res comparat amb descobrir-ho un dilluns al matí.

Comproveu també l’MTU del camí d’extrem a extrem, perquè un valor per defecte complet exposa cada aplicació a la mida màxima de paquet del túnel. Aplicacions que funcionaven fora del túnel poden dependre ara d’un comportament de fragmentació que mai no havíeu de considerar.

Confirmeu que els serveis locals i el DNS privat encara funcionen

Enumerou què ha de quedar-se local pel protocol i no pel nom de l’aplicació: protocols de descobriment per a impressores i pantalles, un pont de casa intel·ligent, la pàgina de gestió d’un encaminador, un servidor de desenvolupament local abastat per un nom que només es resol a la LAN. Aquestes coses es trenquen quan la ruta per defecte comença a apuntar dins d’un túnel, i es trenquen en silenci perquè res no registra cap error al client.

El DNS privat és l’altra dependència. Si els noms interns es resolen abans pel resolutor del túnel, no canvia res; si es resolen localment, un valor per defecte complet els ha de portar a un resolutor que conegui les zones. Proveu un nom intern i un de públic després del canvi en lloc de suposar que la llista de resolutors ha sobreviscut.

Escriviu les excepcions locals al perfil que les posseeix. Una excepció guardada només a la memòria d’algú és la primera cosa que perd la migració següent.

Migreu un perfil i verifiqueu les fronteres

Canvieu el perfil a través de la seva configuració pròpia en lloc de superposar un valor per defecte nou sobre rutes manuals deixades per experiments anteriors. Aquestes rutes sobrants són la causa habitual d’una migració que sembla funcionar i es comporta de manera inconsistent un dia després. Manteniu el perfil antic disponible perquè la reversió sigui una selecció i no una reconstrucció.

Després verifiqueu dues fronteres per separat: que les destinacions públiques i privades funcionin totes dues, i que el trànsit no desitjat no surti fora del túnel. Una càrrega de pàgina correcta demostra la primera i no diu res de la segona.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Repetiu la comprovació després d’una reconnexió i després d’una caiguda, perquè un tall que bloqueja el trànsit durant una caiguda és una propietat diferent d’una ruta que es restaura correctament després. El disseny més simple és aquell la cobertura real del qual encara podeu explicar després que canviï una aplicació o una xarxa.