Ping-чувар не разликува расипан тунел од здрав
Ping кон интернет докажува помалку отколку што изгледа. Проверете го тунелот одвнатре, броете неуспеси пред да дејствувате и третирајте го префрлањето како одделна одлука.
Три услови одлучуваат дали чуварот помага или штети: што може да разликува проверката, колку последователни неуспеси оправдуваат дејство и дали дејството е повторно поврзување или префрлање. Ред од cron што пингува јавна адреса не одговара добро ни на едно од нив. Тој повторно ги поврзува тунелите што се во ред и ги остава расипаните, и двете ги прави без запис. Дизајнот што вреди да се задржи ги прави тие три избори експлицитни.
Проверката е делот што одлучува за остатокот.
Што всушност докажува ping кон интернет
Пингувањето јавен resolver покажува дека локалната интернет патека е жива. Тоа не докажува дека тунелот пренесува сообраќај, а на профил со целосен тунел самиот ping патува низ тунелот, така што здрав одговор и расипан тунел можат да постојат истовремено додека клиентот сѐ уште препраќа пакети. Ако профилот ги праќа пребарувањата на имиња низ тунелот, DNS неуспехот се чита како мртва врска и започнува повторно поврзување што не може ништо да поправи.
Ниту една од двете насоки на грешката не се појавува во излезниот код. Чувар изграден на тој сигнал е фрлање паричка со cron распоред.
Проверете нешто што живее зад тунелот
ip -brief addr show tun0 ip route get 10.100.20.10 nc -z -w3 10.100.20.10 443
Проверувајте одвнатре, најевтината проверка прва. Дали интерфејсот постои кажува дека тунелот е кренат; барањето рута до позната внатрешна адреса кажува дека сообраќајот би влегол во неа; TCP проверка до домаќин од другата страна кажува дека нешто навистина одговара. Самите echo барања заведуваат: многу внатрешни домаќини со задоволство одговараат на TCP, но го отфрлаат ICMP, па чувар изграден на ping постојано го поврзува повторно тунелот што никогаш не престанал да работи.
Држете ја проверката временски ограничена и дајте ѝ посебен излезен статус. Проверка што виси триесет секунди го претвора чуварот во детектор на прекин со вградено доцнење.
Изберете помеѓу еден ред и циклус
* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect
Записот во cron е еден ред без меморија, што одговара на преносен сметач каде дополнителното поврзување не чини ништо. Надгледуван циклус држи бројач и дејствува само по неколку промашувања, што спречува нестабилна врска да предизвика бура од повторни поврзувања. Во секој случај, стартувајте го под супервизор за да преживее пад и да пишува во дневникот. Изберете според тоа дали е важно непотребното поврзување, а не според тоа која верзија е пократка.
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
Тој циклус брои последователни неуспеси, а не дел во прозорец. Прозорецот бара часовник и меморија на примероци, и повеќето грешки во рачно напишаните чувари живеат токму во таа аритметика.
Префрлањето е друга одлука
Менувањето сервери се разликува од повторното поврзување. Прво раскинете ја старата врска, бидејќи вториот клиент што ќе почне додека првиот сѐ уште ја држи адресата ќе се судри. Броете последователни неуспеси пред менувањето, ограничете ги обидите и проверете повторно кога новата врска е крената, наместо да ѝ верувате на излезната состојба на командата connect. Погрешна конфигурација не треба да ротира низ секој сервер во циклус.
Не ја проверувајте сопствената јавна адреса на VPN серверот од внатрешноста на целосен тунел. Таа проверка зависи од работата што ја тестира и пријавува успех додека патеката што требало да ја потврди веќе ја нема.
Запишете која проверка работеше, што врати и кое дејство следеше. Тој запис го претвора мистериозното поврзување во настан што може да се дијагностицира.