É máis simple o túnel completo ca unha longa lista de túnel dividido?

Unha lista de túnel dividido comeza con tres aplicacións e acaba cubrindo a maior parte do equipo, e cada liña nova é a excepción de alguén. Nese punto a lista converteuse en silencio nun valor predeterminado con pasos extra. O túnel completo inverte a disposición: todo entra no túnel salvo que unha exclusión documentada diga o contrario. Que iso sexa máis simple depende da pasarela e dos servizos locais que rompería.

Empece por contar as regras que mantén

Conte as entradas e despois conte cantas teñen un propietario con nome e unha data da última verificación. O segundo número é o que importa, porque unha excepción que ninguén posúe non se pode avaliar cando o software ao que fai referencia se renomea ou se substitúe. As regras ligadas a unha ruta de executable fallan en silencio tras unha actualización, e o fallo parece unha VPN inestable en lugar dunha regra obsoleta. Escriba a lista antes de ter unha opinión sobre ela.

Cada entrada debería responder tres preguntas: que se rompe sen ela, quen o decidiu e como notaría que o motivo caducou. As entradas que non poden responder ás tres son candidatas a borrarse en vez de migrarse, e borralas primeiro fai honesta a comparación posterior.

Se a maioría das entradas encamiñan unha parte grande do tráfico, xa está executando un túnel completo cunha carga de mantemento engadida. A decisión entón é onde vive o valor predeterminado, non se debe haber un.

Comprobe se a pasarela pode soportar o valor predeterminado

O túnel completo move cada paquete a un só dispositivo, o que cambia á vez a carga de CPU dese dispositivo, a táboa conntrack, a tradución de enderezos e o requisito de ancho de banda de subida. Unha pasarela que servía comodamente unhas cantas subredes internas pode que non se dimensionase para toda a navegación dun usuario. Mire o maior número de sesións simultáneas que espera en vez da media, porque o pico é o que se rompe primeiro.

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

Mida a mesma carga antes e despois do cambio en lugar de razoar a partir de especificacións. Unha soa tarde de uso normal nun equipo mostrará se a pasarela está preto dun límite, e non custa nada comparado con descubrilo un luns pola mañá.

Comprobe tamén a MTU da ruta de extremo a extremo, porque un valor predeterminado completo expón cada aplicación ao tamaño máximo de paquete do túnel. Aplicacións que funcionaban fóra do túnel agora poden depender dun comportamento de fragmentación que nunca tivo que considerar.

Confirme que os servizos locais e o DNS privado seguen funcionando

Enumere o que debe quedar local por protocolo e non por nome de aplicación: protocolos de descuberta para impresoras e pantallas, unha ponte de casa intelixente, a páxina de administración dun router, un servidor de desenvolvemento local alcanzado por un nome que só se resolve na LAN. Eses elementos rompen cando a ruta predeterminada comeza a apuntar a un túnel, e rompen en silencio porque nada rexistra un erro no cliente.

O DNS privado é a outra dependencia. Se os nomes internos se resolvían antes co resolutor do túnel, nada cambia; se se resolvían localmente, un valor predeterminado completo ten que levalos a un resolutor que coñeza as zonas. Probe un nome interno e un público despois do cambio en vez de supor que a lista de resolutores sobreviviu.

Escriba as excepcións locais no perfil que as posúe. Unha excepción gardada só na memoria de alguén é o primeiro que perde a seguinte migración.

Migre un perfil e verifique os límites

Cambie o perfil a través da súa propia configuración en lugar de superpoñer un novo valor predeterminado sobre rutas manuais que deixaron experimentos anteriores. Esas rutas sobrantes son a causa habitual dunha migración que parece funcionar e compórtase de forma inconsistente un día despois. Manteña dispoñible o perfil antigo para que reverter sexa unha selección e non unha reconstrución.

Despois verifique dous límites por separado: que os destinos públicos e privados funcionen ambos, e que o tráfico non desexado non saia fóra do túnel. Unha carga de páxina correcta demostra o primeiro e non di nada do segundo.

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

Repita a comprobación tras unha reconexión e tras unha caída, porque un interruptor que bloquea o tráfico durante unha caída é unha propiedade distinta dunha ruta que despois se restaura correctamente. O deseño máis simple é aquel cuxa cobertura real aínda pode explicar despois de que cambie unha aplicación ou unha rede.