Одржувајте неколку vpnc тунели со проверки за секој профил

Еден vpnc профил се поврзува повторно чисто по роаминг; три од нив наизменично си ги кршат сокетите, рутите и состојбата на резолверот. Стандардната скрипта за повторно поврзување е напишана за еден тунел, па таа рестартира секој профил штом било кој од нив е паднат. За да се поправи тоа, потребни се три работи: одделни локални порти, проверка што тестира вистинска услуга за секој профил и еден уреден синџир што никогаш не пушта две врски истовремено.

Дајте му на секој профил своја локална порта

vpnc профил оставен на стандардната локална порта се натпреварува со профилот што веќе работи. Втората врска не успева додека првата ја држи портата, а линијата во дневникот изгледа како проблем со порталот, а не како локален конфликт. Наместо тоа, ставете по една линија за секоја датотека на профил:

Local Port 0

Нулата му дозволува на јадрото да избере привремена порта, па два профила можат да се воспостават истовремено. Именувајте ја секоја датотека по порталот и групата што ја опслужува, држете ја читлива само за root и секогаш поврзувајте се со соодветниот профил наместо со заедничка стандардна. Заедничката стандардна датотека е начинот на кој скриптата повторно поврзува погрешен тунел откако некој ќе преименува профил.

Датотеките на профилот носат податоци за најава, па дозволите се дел од дизајнот, а не од домаќинството. Датотека читлива за сите под /etc/vpnc го предава групниот тајна на секој локален корисник. Држете го режимот на 0600 со root како сопственик и оставете скриптите да ја читаат датотеката како root наместо да копираат тајни во аргументи. Затоа и скриптата за проверка никогаш не треба да ја печати содржината на датотеката во дневник.

Проверете една услуга за секој профил, не адресата на тунелот

Барањето за ехо до сопствената адреса на тунелот главно докажува дека интерфејсот постои. Тоа не кажува ништо за тоа дали домаќинот зад него сѐ уште ја достигнува апликацијата што го оправдува тунелот. Интерфејсот може да е активен додека рутата зад него веќе исчезнала.

Проверете една услуга за секој профил со краток TCP рок и повторно поврзете го само профилот чијашто проверка не успеа. Две секунди делат мртва патека од бавна, а TCP проверката не зависи од тоа дали ICMP е дозволен некаде по патеката. Менувајте ја само целта и името на конфигурацијата помеѓу профилите:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

Зачувајте го тоа како /usr/local/bin/ensure-vpn-ops.sh, направете го извршно и повторете го за секој профил менувајќи ја само целта на проверката и името на конфигурацијата. Проверка што одговара на протоколно прашање преживува портали што го фрлаат ехото, но продолжуваат да ги пренесуваат услугите што им се важни на корисниците.

Поврзете ги проверките во синџир за никогаш да не се натпреваруваат

Стандардната скрипта за повторно поврзување може да ги повикува вашите проверки по ред, а редоследот е целата поента. Две повикувања на vpnc-connect што работат заедно ја препишуваат табелата за рутирање по ред што никој не го контролира, и токму така здрав профил ја губи својата рута.

Држете ги повикувањата во преден план, додајте кратко смирување за основната интерфејс и закажете го синџирот од cron табелата на root, бидејќи само root може да ги препишува рутите на тунелот:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

Држете го редоследот ист помеѓу скриптата за подигање и cron записот, бидејќи синџир што при подигање работи по друг редослед е суштински друга програма. Кога еден профил зависи од рутите на друг, ставете ја зависноста прва и дозволете подоцнежната проверка безопасно да не успее додека претходниот тунел сѐ уште се подига.

Гледајте го дневникот, па намерно скршете еден

Забележете по една линија за секое извршување со профилот, целта на проверката, резултатот и преземената акција. Без тоа тунел што трепери секоја минута изгледа исто како оној што никогаш не паднал, а грешката во проверката не се разликува од прекин на порталот. Дневникот исто така докажува дека синџирот допрел само до профилот што не успеал. Запишете го некаде каде што преживува рестарт, инаку доказите си одат со процесот.

Потоа намерно скршете тунел и гледајте што се случува. Запрете еден профил и потврдете кои процеси и рути сѐ уште се присутни:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

Само запрениот профил треба да се поврзе повторно, а другите сесии треба да ги задржат и процесите и рутите. Ако два профила се рестартираат, вашиот синџир работи паралелно некаде каде што не сте очекувале.

Што не смее да прави чуварот

Чувар што рестартира сѐ штом нешто не успее изгледа здраво при тестирање и предизвикува прекин во прозорец за одржување. Рестартирајте по профил, никогаш глобално.

Претпочитајте одржуван клиент кога порталот нуди таков за истиот протокол и никогаш не вградувајте лозинка во скриптата ниту предавајте ја на командна линија, бидејќи датотеката на профилот веќе ја чува тајната. Ако задачата мора да работи како обичен корисник откако тунелот е подигнат, намалете ги привилегиите од внатрешноста на скриптата наместо целиот синџир да работи под тој профил. На крајот, прочитајте ги рутите повторно по повторното поврзување, бидејќи профилот може да се врати со друга доделена адреса и да остави застарела рута што ниту една проверка насочена кон адресата на тунелот никогаш нема да ја забележи.