Ein ping-vakt skil ikkje ein broten tunnel frå ein sunn

Ein ping mot internett provar mindre enn det ser ut som. Sjekk tunnelen innanfrå, tel feil før du handlar, og handsam bytte av tenar som eit eige vedtak.

Tre vilkår avgjer om ei vakt hjelper eller skadar: kva sonden kan skilje, kor mange påfølgjande feil som rettferdiggjer handling, og om handlinga er ei nykopling eller eit bytte. Ei cron-linje som pingar ei open adresse svarar ikkje godt på nokon av dei. Ho koplar til tunnelar som er i orden på nytt og lèt tunnelar som er brotne vere, og ho gjer båe delane utan ei registrering. Designet som er verdt å behalde gjer dei tre vala tydelege.

Sonden er den delen som avgjer alt anna.

Kva ein ping mot internett faktisk provar

Å pinge ein open resolver viser at den lokale internettvegen er levande. Det provar ikkje at tunnelen ber trafikk, og på ein profil med full tunnel går sjølve pinget gjennom tunnelen, så eit sunt svar og ein broten tunnel kan finnast samstundes medan klienten framleis sender pakkar vidare. Om profilen sender namneoppslag gjennom tunnelen, blir ein DNS-feil lesen som ei daud samband og startar ei nykopling som ikkje kan rette noko.

Ingen av dei to retningane av feilen viser seg i utgangskoden. Ei vakt bygd på det signalet er eit myntkast med ein cron-plan.

Sjekk noko som lever bak tunnelen

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

Sjekk innanfrå, den billegaste kontrollen først. Om grensesnittet finst, seier at tunnelen er oppe; eit ruteoppslag mot ei kjend intern adresse seier at trafikk ville gå inn i ho; ein TCP-sonde mot ein vert på den andre sida seier at noko faktisk svarar. Berre echo-førespurnader villeder: mange interne vertar svarar gjerne på TCP men slepp ICMP, så ei vakt bygd på ping koplar støtt på nytt ein tunnel som aldri slutta å verke.

Hald sonden tidsavgrensa og gje han ein eigen utgangsstatus. Ein sonde som heng i tretti sekund gjer ei vakt til ein utfallsdetektor med innebygd forseinking.

Vel mellom éi linje og ei løkke

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

Ei cron-oppføring er éi linje utan minne, noko som passar ein berbar PC der ei ekstra nykopling ikkje kostar noko. Ei overvaka løkke held ein teljar og handlar først etter fleire feil, noko som hindrar ei ustabil linje i å utløyse ein storm av nykoplingar. Uansett bør du køyre ho under ein supervisor så ho overlever ein krasj og skriv til journalen. Vel ut frå om ei falsk nykopling betyr noko, ikkje ut frå kva versjon som er kortast.

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

Den løkka tel påfølgjande feil i staden for ein brøkdel over eit vindauge. Eit vindauge krev ei klokke og eit minne av prøver, og dei fleste feila i handskrivne vakter bur i den aritmetikken.

Bytte av tenar er eit anna vedtak

Å bytte tenar er noko anna enn å kople på nytt. Riv ned den gamle sambandet først, fordi ein annan klient som startar medan den første framleis held adressa, vil kollidere. Tel påfølgjande feil før byttet, avgrens forsøka, og sjekk på nytt når den nye sambandet er oppe i staden for å stole på utgangsstatusen til connect-kommandoen. Ein feil konfigurasjon bør ikkje rotere gjennom kvar tenar i ei løkke.

Ikkje sjekk den eigne opne adressa til VPN-tenaren innanfrå ein full tunnel. Den kontrollen er avhengig av det han testar, og han rapporterer suksess medan vegen han skulle stadfeste er borte.

Registrer kva sonde som køyrde, kva han returnerte og kva handling som følgde. Den registreringa gjer ei mystisk nykopling til ei hending som kan diagnostiserast.

Relaterte artiklar