Часовен прекин на 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 и загуба на пакети.