Штогадзінны абрыў OpenVPN: перамовы аб ключах ці сапраўднае перападключэнне?
Абрыў на падазрона круглым інтэрвале — звычайна абнаўленне ключоў, а не мёртвы канал. Прачытайце дзейны таймер і радок журнала, перш чым нешта адключаць.
Шэсцьдзясят хвілін, ці трыццаць, ці сто дваццаць: абрыў, які прыпадае на круглы інтэрвал, амаль ніколі не звязаны з сеткай. OpenVPN абнаўляе па таймеры ключавы матэрыял, які абараняе канал даных, і таймер, карацейшы за той, які вы меркавалі, выглядае дакладна як канал, што пастаянна падае. Карыстальнікі паведамляюць пра разарванае злучэнне, а журнал паведамляе пра паспяховы абмен ключамі. Інструкцыя ніжэй аддзяляе гэтае абнаўленне ад сапраўднага перазапуску, чытае фактычна дзейнае значэнне і змяняе яго толькі пасля таго, як цана названая.
Выконвайце крокі па парадку, бо першы з іх вырашае, ці тычыцца вас наогул усё астатняе на гэтай старонцы. Пераскочыце наперад — і вы страціце вечар на наладку таймера праз няспраўнасць, якая да яго не мае дачынення.
Адрозніце мяккі скід ад перазапуску
Радок журнала — гэта ўвесь дыягназ. Перамовы аб ключах запісваюць мяккі скід, а затым новы абмен ключамі ўнутры таго ж тунеля: інтэрфейс захоўвае свой адрас, маршруты паўторна не дадаюцца, а ўсталяваныя сесіі TCP звычайна перажываюць гэта з паўзай. Сапраўдны перазапуск разрывае сесію, перабудоўвае інтэрфейс, можа выдаць іншы адрас кліента і забівае ўсе доўгажывучыя злучэнні. Абедзве падзеі звычайныя; толькі адна з іх тлумачыць абарваны званок.
journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1
Радок версіі важны, бо фармулёўкі ў журнале змяняюцца ад выпуску да выпуску, і паведамленне, якое вы памятаеце з 2.3, у 2.6 можа гучаць інакш. Чытайце ўласны журнал, а не вытрымку з форуму, узятаую ў кагосьці іншага. Цытуйце дакладны радок, калі просіце дапамогі, бо пераказ губляе дэталь, па якой пазнаецца падзея. Калі адрас інтэрфейса за час падзеі не змяніўся і спіс сесій захаваўся, перад вамі абнаўленне, і астатнія раздзелы дастасавальныя.
Чытайце дзейны таймер, а не свой файл
reneg-sec — гэта колькасць секунд паміж перамовамі аб ключах канала даных, па змаўчанні 3600. Кожны бок нясе сваё значэнне, і менавіта меншае з двух запускае абнаўленне. Гэтае адзінае правіла тлумачыць большасць паведамленняў: профіль кліента, які задае вялікі лік, усё роўна скідаецца штогадзіны, пакуль сервер захоўвае значэнне па змаўчанні.
grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/
Чытайце таксама дзейную канфігурацыю сервера, уключаючы ўсё, што ён перадае, перш чым рабіць выснову па файле кліента. Затым павялічце падрабязнасць і прасачыце адзін інтэрвал ад пачатку да канца: узровень 3 ужо паказвае радкі перамоў, а адзнакі часу падкажуць, ці паўтараецца падзея кожныя 3600 секунд ці ідзе за актыўнасцю.
Змяняйце там, дзе значэнне сапраўды перадаецца
Хаджачы лек — адзін радок у профілі кліента, і прыкладна ў палове выпадкаў гэта няправільнае месца. Паколькі перамагае меншае значэнне боку, кліент, які паставіў таймер у нуль, усё роўна можа быць перамоўлены серверам, які не змяніўся.
# on both ends, or on the side that owns the pushed configuration
reneg-sec 0
Калі профілі ствараюцца цэнтралізавана, праўце шаблон, а не разгорнутую копію, інакш наступны запуск забеспячэння аднавіць значэнне, якое вы толькі што прыбралі. Правярайце, назіраючы два інтэрвалы, а не адзін: адна спакойная гадзіна ўзгадняецца і з таймерам, пастаўленым на 7200.
Вырашыце таксама, што адбудзецца пры змяшаным разгортванні. Калі выкаціць змену спачатку на кліентаў, застанецца акно, у якім сервер усё яшчэ запускае абнаўленне; гэта бясшкодна, але збівае з панталыку, калі вы сочыце за журналамі ў пошуках пацверджання. Змяняйце першым той бок, дзе значэнне меншае, і сімптом знікне там, дзе вы чакаеце.
Ад чаго вы адмаўляецеся, адключаючы перамовы
Рэгулярныя перамовы абмяжоўваюць, як доўга адзін набор ключоў канала даных абараняе трафік. Адключэнне таймера не ламае тунель, і на хатнім маршрутызатары або шлюзе невялікага офіса практычная экспазіцыя сціплая. Гэта ўсё яшчэ абмен, і абмен варта назваць да таго, як вы яго зробіце. Змяняецца тое, як доўга адзін набор ключоў абараняе сесію, а не тое, ці працуе тунель наогул.
Разумны выпадак для адключэння — скід, які ламае нешта, што немагчыма аднавіць: званок, які абрываецца, сеанс аддаленага працоўнага стала, які даводзіцца ўсталёўваць нанова, рэзервовая копія, якая пачынаецца спачатку. Калі паўза незаўважная для карыстальнікаў, захаванне значэння па змаўчанні нічога не каштуе і захоўвае вам ратацыю ключоў.
Аддавайце перавагу выпраўленню прычыны, калі гэта дазваляе карціна. Абнаўленне, якое зрываецца на паўдарозе, тады як першае рукапоцісканне прайшло паспяхова, паказвае на шлях, а не на таймер: шукайце праблему памеру пакета ў большым абмене канала кіравання, міжсеткавы экран з адсочваннем стану, які скідвае паток, або прапанову, якая праходзіць толькі з першай спробы. Кожная з іх пакідае след у тым жа журнале, які вы толькі што чыталі. Адключэнне таймера хавае гэтыя доказы.
Калі інтэрвал паказвае ў іншы бок
Два суседзі ў канфігурацыі даюць падобныя сімптомы і розныя выпраўленні. ping-restart перазапускае тунель, калі нічога не прыходзіць на працягу зададзенага перыяду, а ping-exit цалкам выключае кліента. Абрыў пры прастоі, без якіх-небудзь перамоў у журнале, адносіцца да іх або да прылады NAT, у якой скончыўся тэрмін адлюстравання UDP па яго ўласным раскладзе.
Спажывецкія маршрутызатары, мабільныя кропкі доступу і NAT аператарскага класа сканчаюць тэрмін прастойных сесій UDP, нікому не паведамляючы. Гэтая няспраўнасць ідзе за прастоем, а не за гадзіннікам, і гэта і ёсць прыкмета: сесія, якая абрываецца пасля дзесяці ціхіх хвілін і перажывае гадзіну роўнага трафіку, не вядзе перамоў.
Запішыце тры рэчы, перш чым змяніць чацвёртую: вымераны інтэрвал, знойдзенае дзейнае значэнне і каманду, якая яго паказала. Калі інтэрвал рухаецца разам з таймерам, механізм вызначаны, і выпраўленне — гэта рашэнне пра абмен, пра які вышэй. Калі ён не рухаецца, вярніце наладу і працягвайце глядзець на keepalive, стан NAT і страты пакетаў.