Трымайце некалькі тунеляў vpnc з праверкамі для кожнага профілю

Стандартны скрыпт перападлучэння разлічаны на адзін тунель. Дайце кожнаму профілю 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

Перападключыцца павінен толькі спынены профіль, а іншыя сеансы павінны захаваць і свае працэсы, і свае маршруты. Калі перазапускаюцца два профілі, ваш ланцуг дзесьці ідзе паралельна, дзе вы гэтага не чакалі.

Што вартаўнік рабіць не павінен

Вартаўнік, які перазапускае ўсё пры любой няўдачы, выглядае здаровым падчас тэсціравання і выклікае збой у акне абслугоўвання. Перазапускайце па профілю, ніколі глабальна.

Аддавайце перавагу кліенту, які падтрымліваецца, калі шлюз прапануе такі для таго ж пратакола, і ніколі не ўпісвайце пароль у скрыпт і не перадавайце яго ў камандным радку, бо файл профілю ўжо захоўвае сакрэт. Калі заданне павінна выконвацца пад звычайным карыстальнікам пасля ўздыму тунеля, паніжайце прывілеі знутры скрыпта, а не прымушайце ўвесь ланцуг працаваць пад гэтым уліковым запісам. Нарэшце, перачытайце маршруты пасля перападлучэння, бо профіль можа вярнуцца з іншым прызначаным адрасам і пакінуць састарэлы маршрут, якога ніякая праверка, накіраваная на адрас тунеля, не заўважыць.

Падобныя артыкулы