Panatilihing buhay ang maraming vpnc tunnel gamit ang probe kada profile

Isang vpnc profile ang malinis na muling kumokonekta pagkatapos ng roaming; tatlo sa kanila ang humalili sa pagsira sa socket, ruta at estado ng resolver ng isa't isa. Ang reconnect script na kasama ng package ay isinulat para sa isang tunnel lang, kaya nire-restart nito ang bawat profile sa tuwing may isa sa kanilang down. Para ayusin iyon, kailangan ng tatlong bagay: hiwalay na local port, isang probe na sumusubok ng tunay na serbisyo kada profile, at isang ordered na chain na hindi kailanman nagpapatakbo ng dalawang connect nang sabay.

Bigyan ang bawat profile ng sariling local port

Ang vpnc profile na naiwan sa default na local port ay nakikipag-agawan sa profile na tumatakbo na. Nabibigo ang pangalawang koneksyon habang hawak ng una ang port, at ang linya sa log ay mukhang problema sa gateway kaysa lokal na alitan. Sa halip, maglagay ng isang linya kada profile file:

Local Port 0

Ang zero ay nagpapahintulot sa kernel na pumili ng ephemeral na port, kaya dalawang profile ang maaaring maitatag nang sabay. Pangalanan ang bawat file ayon sa gateway at grupo na pinaglilingkuran nito, panatilihin itong nababasa lang ng root, at kumonekta palagi gamit ang tugmang profile kaysa sa isang shared default. Ang shared default file ang dahilan kung bakit nagre-reconnect ang script sa maling tunnel pagkatapos palitan ng pangalan ng isang tao ang isang profile.

Ang mga profile file ay may dalang kredensyal, kaya bahagi ng disenyo ang mga permiso at hindi ng pagliligpit. Ang file sa ilalim ng /etc/vpnc na nababasa ng lahat ay nag-aabot ng group secret sa bawat local user. Panatilihin ang mode sa 0600 na root ang may-ari, at hayaang basahin ng mga script ang file bilang root kaysa kopyahin ang mga sikreto sa argumento. Ito rin ang dahilan kung bakit hindi dapat isulat ng probe script ang nilalaman ng file sa log.

Subukan ang isang serbisyo kada profile, hindi ang address ng tunnel

Ang echo request sa sariling address ng tunnel ay pangunahing nagpapatunay na umiiral ang interface. Hindi nito sinasabi kung naaabot pa ng host sa likod nito ang aplikasyong nagbibigay-katwiran sa tunnel. Maaaring up ang interface habang wala na ang rutang lampas dito.

Subukan ang isang serbisyo kada profile gamit ang maikling TCP timeout at i-reconnect lang ang profile na nabigo ang probe. Dalawang segundo ang naghihiwalay ng patay na landas sa mabagal, at ang TCP probe ay hindi umaasa sa kung pinapayagan ang ICMP saanman sa landas. Baguhin lang ang target at pangalan ng config sa pagitan ng mga profile:

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

I-save iyon bilang /usr/local/bin/ensure-vpn-ops.sh, gawing executable, at ulitin para sa bawat profile na binabago lang ang target ng probe at pangalan ng config. Ang probe na sumasagot sa tanong ng protocol ay nakakalampas sa mga gateway na nagtatapon ng echo habang ipinapasa pa rin ang mga serbisyong mahalaga sa mga user.

Ikadena ang mga probe para hindi sila magkarera kailanman

Maaaring tawagin ng stock na reconnect script ang iyong mga probe nang sunud-sunod, at ang pagkakasunod-sunod ang buong punto. Dalawang tawag sa vpnc-connect na tumatakbo nang sabay ay nagsusulat muli ng routing table sa order na walang kumokontrol, at ganoon nawawala ng malusog na profile ang ruta nito.

Panatilihing nasa harapan ang mga tawag, magdagdag ng maikling settle delay para sa underlying interface, at iiskedyul ang chain mula sa cron table ng root, dahil root lang ang makakasulat muli ng mga ruta ng tunnel:

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

Panatilihing pareho ang order sa pagitan ng boot script at ng cron entry, dahil ang chain na tumatakbo sa ibang order sa boot ay epektibong ibang programa. Kapag ang isang profile ay umaasa sa mga ruta ng iba, ilagay muna ang dependency at hayaang mabigo nang walang pinsala ang susunod na probe habang umaakyat pa ang naunang tunnel.

Bantayan ang log, pagkatapos ay sadyang sirain ang isa

I-log ang isang linya kada run kasama ang profile, target ng probe, resulta at ginawang aksyon. Kung wala iyon, ang tunnel na kumikislap kada minuto ay mukhang eksaktong katulad ng hindi kailanman bumagsak, at ang bug sa probe ay hindi makikilala mula sa pagkawala ng gateway. Pinatutunayan din ng log na hinawakan lang ng chain ang profile na nabigo. Isulat ito sa lugar na tumatagal pagkatapos ng reboot, kung hindi, umaalis ang ebidensya kasama ng proseso.

Pagkatapos ay sadyang sirain ang isang tunnel at tingnan ang mangyayari. Itigil ang isang profile at kumpirmahin kung aling mga proseso at ruta ang naroon pa:

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

Tanging ang itinigil na profile ang dapat ma-reconnect, at ang ibang session ay dapat panatilihin ang kanilang mga proseso at ruta. Kung dalawang profile ang nag-restart, tumatakbo ang chain mo nang parallel sa isang lugar na hindi mo inaasahan.

Ano ang hindi dapat gawin ng watchdog

Ang watchdog na nagre-restart ng lahat sa tuwing may nabigo ay mukhang malusog sa pagsubok at nagdudulot ng outage sa isang maintenance window. I-restart kada profile, hindi kailanman pangkalahatan.

Piliin ang maintained na client kapag may inaalok ang gateway para sa parehong protocol, at huwag kailanman i-hardcode ang password sa script o ipasa ito sa command line, dahil hawak na ng profile file ang sikreto. Kung kailangang tumakbo ang isang gawain bilang ordinaryong user kapag up na ang tunnel, bawasan ang mga pribilehiyo mula sa loob ng script kaysa patakbuhin ang buong chain sa ilalim ng account na iyon. Sa huli, basahin muli ang mga ruta pagkatapos ng reconnect, dahil maaaring bumalik ang isang profile na may ibang nakatalagang address at mag-iwan ng lumang rutang hindi mapapansin ng anumang probe na nakaturo sa address ng tunnel.