Palaikykite kelis vpnc tunelius su kiekvieno profilio patikromis

Vienas vpnc profilis po roamingo persijungia švariai; trys jų pakaitomis laužo vienas kito lizdus, maršrutus ir sprendėjo būseną. Standartinis perjungimo scenarijus parašytas vienam tuneliui, todėl jis iš naujo paleidžia kiekvieną profilį, kai tik bet kuris jų neveikia. Tam sutvarkyti reikia trijų dalykų: atskirų vietinių portų, patikros, kuri kiekvienam profiliui tikrina tikrą paslaugą, ir vienos tvarkingos grandinės, kuri niekada neleidžia dviejų jungčių vienu metu.

Duokite kiekvienam profiliui savo vietinį portą

vpnc profilis, paliktas numatytajame vietiniame porte, konkuruoja su jau veikiančiu profiliu. Antroji jungtis nepavyksta, kol pirmoji laiko portą, ir žurnalo eilutė atrodo kaip šliuzo problema, o ne vietinis konfliktas. Vietoj to nustatykite po vieną eilutę kiekvienam profilio failui:

Local Port 0

Nulis leidžia branduoliui pasirinkti laikiną portą, todėl du profiliai gali būti nustatyti vienu metu. Pavadinkite kiekvieną failą pagal šliuzą ir grupę, kuriai jis tarnauja, laikykite jį skaitomą tik root, ir visada junkitės atitinkančiu profiliu, o ne bendru numatytuoju. Bendras numatytasis failas yra būdas, kuriuo scenarijus iš naujo prijungia ne tą tunelį po to, kai kas nors pervadina profilį.

Profilio failuose yra prisijungimo duomenų, todėl teisės priklauso projektui, o ne tvarkymuisi. Failas, skaitomas visų ir esantis /etc/vpnc, atiduoda grupės paslaptį kiekvienam vietiniam naudotojui. Laikykite režimą 0600 ir savininką root, o scenarijams leiskite skaityti failą kaip root, o ne kopijuoti paslaptis į argumentus. Štai kodėl patikros scenarijus niekada neturėtų rašyti failo turinio į žurnalą.

Tikrinkite vieną paslaugą kiekvienam profiliui, o ne tunelio adresą

Aido užklausa į paties tunelio adresą daugiausia įrodo, kad sąsaja egzistuoja. Ji nieko nesako apie tai, ar už jos esantis mazgas dar pasiekia programą, kuri pateisina tunelį. Sąsaja gali būti aktyvi, kai maršrutas už jos jau dingo.

Tikrinkite vieną paslaugą kiekvienam profiliui su trumpu TCP laiko limitu ir iš naujo junkite tik tą profilį, kurio patikra nepavyko. Dvi sekundės skiria negyvą kelią nuo lėto, ir TCP patikra nepriklauso nuo to, ar ICMP kažkur kelyje leidžiamas. Tarp profilių keiskite tik tikslą ir konfigūracijos pavadinimą:

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

Išsaugokite tai kaip /usr/local/bin/ensure-vpn-ops.sh, padarykite vykdomą ir pakartokite kiekvienam profiliui keisdami tik patikros tikslą ir konfigūracijos pavadinimą. Patikra, kuri atsako į protokolo klausimą, išgyvena šliuzus, kurie meta aidą, bet vis tiek perduoda paslaugas, kurios naudotojams svarbios.

Sujunkite patikras į grandinę, kad jos niekada nekonkuruotų

Standartinis perjungimo scenarijus gali kviesti jūsų patikras iš eilės, ir eiliškumas yra esmė. Du kartu veikiantys vpnc-connect kvietimai perrašo maršrutizavimo lentelę tvarka, kurios niekas nekontroliuoja, ir taip sveikas profilis praranda savo maršrutą.

Laikykite kvietimus pirmame plane, pridėkite trumpą stabilizavimo delsą apatinei sąsajai ir suplanuokite grandinę iš root cron lentelės, nes tik root gali perrašyti tunelio maršrutus:

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

Laikykite tvarką identišką tarp paleidimo scenarijaus ir cron įrašo, nes grandinė, kuri paleidimo metu veikia kita tvarka, iš esmės yra kita programa. Kai vienas profilis priklauso nuo kito maršrutų, priklausomybę dėkite pirmiau ir leiskite vėlesnei patikrai nekenksmingai nepavykti, kol ankstesnis tunelis dar keliasi.

Stebėkite žurnalą, tada tyčia sulaužykite vieną

Registruokite po vieną eilutę kiekvienam paleidimui su profiliu, patikros tikslu, rezultatu ir atliktu veiksmu. Be to tunelis, kuris kas minutę plazda, atrodo lygiai taip pat kaip tas, kuris niekada nenukrito, ir patikros klaidos neįmanoma atskirti nuo šliuzo sutrikimo. Žurnalas taip pat įrodo, kad grandinė palietė tik tą profilį, kuris nepavyko. Rašykite jį ten, kur jis išlieka po perkrovimo, kitaip įrodymai išeina kartu su procesu.

Tada tyčia sulaužykite tunelį ir pažiūrėkite, kas atsitinka. Sustabdykite vieną profilį ir patvirtinkite, kurie procesai ir maršrutai dar yra:

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

Iš naujo turėtų prisijungti tik sustabdytas profilis, o kitos sesijos turėtų išlaikyti ir procesus, ir maršrutus. Jei iš naujo paleidžiami du profiliai, jūsų grandinė veikia lygiagrečiai kažkur, kur to nesitikėjote.

Ko sargas neturi daryti

Sargas, kuris iš naujo paleidžia viską, kai tik kas nors nepavyksta, testavimo metu atrodo sveikas ir sukelia sutrikimą techninės priežiūros lange. Paleiskite iš naujo pagal profilį, niekada globaliai.

Teikite pirmenybę prižiūrimam klientui, kai šliuzas siūlo tokį pačiam protokolui, ir niekada nekoduokite slaptažodžio scenarijuje ar neperduokite jo komandų eilutėje, nes profilio faile jau yra paslaptis. Jei užduotis turi veikti kaip paprastas naudotojas po to, kai tunelis pakeltas, sumažinkite teises scenarijaus viduje, o ne leiskite visai grandinei veikti pagal tą paskyrą. Galiausiai, po prisijungimo iš naujo perskaitykite maršrutus, nes profilis gali grįžti su kitu priskirtu adresu ir palikti pasenusį maršrutą, kurio jokia į tunelio adresą nukreipta patikra niekada nepastebės.