Un gos guardià de ping no distingeix un túnel trencat d’un de sa

Tres condicions decideixen si un gos guardià ajuda o perjudica: què pot distingir la sonda, quants errors consecutius justifiquen una acció i si l’acció és una reconnexió o un canvi de servidor. Una línia de cron que fa ping a una adreça pública no respon bé a cap de les tres. Reconecta túnels que estan bé i deixa túnels que estan trencats, i ho fa totes dues coses sense cap registre. El disseny que val la pena conservar fa explícites aquestes tres tries.

La sonda és la part que decideix tota la resta.

Què demostra realment un ping a internet

Fer ping a un servidor de noms públic mostra que el camí local d’internet és viu. No demostra que el túnel transporti trànsit, i en un perfil de túnel complet el ping mateix viatja pel túnel, així que una resposta sana i un túnel trencat poden conviure mentre el client encara reenvia paquets. Si el perfil envia les consultes de noms pel túnel, una fallada de DNS es llegeix com un enllaç mort i inicia una reconnexió que no pot arreglar res.

Cap de les dues direccions de l’error no apareix al codi de sortida. Un gos guardià construït sobre aquest senyal és un llançament de moneda amb una programació de cron.

Sondigueu alguna cosa que visqui darrere del túnel

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

Sondigueu des de dins, la comprovació més barata primer. Si la interfície existeix, el túnel està aixecat; una consulta de ruta cap a una adreça interna coneguda diu que el trànsit hi entraria; una sonda TCP cap a un amfitrió de l’altre costat diu que alguna cosa respon de veritat. Només les peticions d’eco enganyen: molts amfitrions interns responen de bon grat a TCP però descarten ICMP, així que un gos guardià basat en ping reconecta un túnel que mai no va deixar de funcionar.

Manteniu la sonda limitada en el temps i doneu-li un estat de sortida propi. Una sonda que es penja trenta segons converteix el gos guardià en un detector de caigudes amb un retard incorporat.

Trieu entre una línia i un bucle

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

Una entrada de cron és una sola línia sense memòria, cosa que va bé en un portàtil on una reconnexió extra no costa res. Un bucle supervisat manté un comptador i només actua després de diverses errades, cosa que evita que un enllaç inestable provoqui una tempesta de reconnexions. En qualsevol cas, executeu-lo sota un supervisor perquè sobrevisqui a una caiguda i escrigui al registre. Trieu segons si una reconnexió espúria importa, no segons quina versió és més curta.

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

Aquest bucle compta errors consecutius en lloc d’una fracció en una finestra. Una finestra necessita un rellotge i una memòria de mostres, i la majoria d’errors dels gossos guardians fets a mà viuen en aquesta aritmètica.

El canvi de servidor és una decisió diferent

Canviar de servidor és diferent de reconnectar. Trenqueu primer l’enllaç vell, perquè un segon client que arrenqui mentre el primer encara té l’adreça xocarà. Compteu errors consecutius abans de canviar, limiteu els intents i torneu a sondar quan el nou enllaç estigui aixecat, en lloc de confiar en el codi de sortida de l’ordre connect. Una configuració equivocada no hauria de recórrer tots els servidors en bucle.

No sondigueu l’adreça pública del mateix servidor VPN des de dins d’un túnel complet. Aquesta comprovació depèn de la cosa que està provant, i informa d’èxit mentre el camí que havia de validar ja no hi és.

Registreu quina sonda va córrer, què va tornar i quina acció va seguir. Aquest registre converteix una reconnexió misteriosa en un esdeveniment diagnosticable.