Ĉiuhora OpenVPN-interrompo: rekontraktado aŭ vera rekonekto?

Sesdek minutoj, aŭ tridek, aŭ cent dudek: interrompo kiu falas je ronda intervalo preskaŭ neniam estas la reto. OpenVPN renovigas laŭtempigile la ŝlosilan materialon kiu protektas la datan kanalon, kaj tempigilo pli mallonga ol tiu kiun vi supozis aspektas ĝuste kiel ligo kiu konstante malsukcesas. Uzantoj raportas rompitan konekton dum la protokolo raportas sukcesan ŝlosilan interŝanĝon. La gvidilo sube apartigas tiun renovigon de vera restarto, legas la valoron efektive validan kaj ŝanĝas ĝin nur post kiam la kosto estas sur la tablo.

Plenumu la paŝojn laŭorde, ĉar la unua decidas ĉu la cetero de la paĝo entute koncernas vin. Saltu antaŭen kaj vi pasigos vesperon agordante tempigilon pro difekto kiu tute ne rilatas al ĝi.

Distingi molan restarigon de restarto

La protokola linio estas la tuta diagnozo. Rekontraktado skribas molan restarigon kaj poste freŝan ŝlosilan interŝanĝon ene de la sama tunelo: la interfaco konservas sian adreson, itineroj ne estas re-aldonataj, kaj establitaj TCP-sesioj kutime postvivas kun paŭzo. Vera restarto disŝiras la sesion, rekonstruas la interfacon, eble donas alian klientan adreson kaj mortigas ĉiun longdaŭran konekton. Ambaŭ eventoj estas ordinaraj; nur unu el ili klarigas interrompitan alvokon.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

La versa linio gravas ĉar la formuloj en la protokolo ŝoviĝas inter eldonoj, kaj mesaĝo kiun vi memoras el 2.3 povas esti formulita alie en 2.6. Legu vian propran protokolon anstataŭ forumon eltiraĵon de iu alia. Citu la ĝustan linion kiam vi petas helpon, ĉar resumo perdas la detalon kiu identigas la eventon. Se la interfaca adreso restas senŝanĝa tra la evento kaj la sesia listo postvivas, vi vidas renovigon kaj la restantaj sekcioj validas.

Legu la efektivan tempigilon, ne vian dosieron

reneg-sec estas la nombro da sekundoj inter rekontraktadoj de la data kanalo kaj ĝia defaŭlto estas 3600. Ĉiu flanko portas sian propran valoron, kaj la pli malgranda el la du estas tiu kiu efektive ekigas la renovigon. Tiu unu regulo klarigas la plej multajn raportojn: klienta profilo kiu starigas grandan nombron tamen restariĝas ĉiuhore dum la servilo konservas la defaŭlton.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Legu ankaŭ la efektivan agordon de la servilo, inkluzive de ĉio kion ĝi puŝas, antaŭ ol konkludi el la klienta dosiero. Poste altigu la detalecon kaj observu unu intervalon de komenco ĝis fino: nivelo 3 jam montras la rekontraktajn liniojn, kaj la tempindikoj diras ĉu la evento ripetiĝas ĉiujn 3600 sekundojn aŭ sekvas aktivecon.

Ŝanĝu ĝin tie, kie ĝi efektive estas puŝata

La cirkulanta kuracilo estas unu linio en la klienta profilo, kaj ĝi estas la malĝusta loko proksimume duonon da la tempo. Ĉar venkas la pli malalta valoro de la flanko, kliento kiu starigas la tempigilon al nulo tamen povas esti rekontraktata de servilo kiu ne ŝanĝiĝis.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Kie profiloj estas generataj centre, redaktu la ŝablonon kaj ne la deplojitan kopion, alie la sekva provizadkurso restarigos la valoron kiun vi ĵus forigis. Kontrolu observante du intervalojn, ne unu: unu kvieta horo kongruas ankaŭ kun tempigilo starigita al 7200.

Decidu ankaŭ kio okazas ĉe miksita deplojo. Se vi disvastigos la ŝanĝon unue al klientoj, restas fenestro en kiu la servilo ankoraŭ ekigas la renovigon; tio estas sendanĝera sed konfuza se vi observas la protokolojn por konfirmo. Ŝanĝu unue la flankon kun la pli malgranda valoro kaj la simptomo malaperas ĉe la punkto kiun vi atendas.

Kion vi cedas per malŝalto de rekontraktado

Regula rekontraktado limigas kiom longe unu aro da datkanalaj ŝlosiloj protektas trafikon. Malŝalti la tempigilon ne rompas la tunelon, kaj ĉe hejma enkursigilo aŭ malgranda oficeja pordego la praktika ekspono estas modesta. Ĝi tamen estas interŝanĝo, kaj la interŝanĝo indas esti nomata antaŭ ol vi faras ĝin. Kio ŝanĝiĝas estas kiom longe unu ŝlosilaro protektas sesion, ne ĉu la tunelo entute funkcias.

La racia kazo por malŝalti ĝin estas restarigo kiu rompas ion kio ne povas daŭrigi: alvoko kiu falas, fora labortabla sesio kiu devas esti restarigita, savkopio kiu rekomenciĝas de la komenco. Se la paŭzo estas nevidebla por uzantoj, lasi la defaŭlton kostas nenion kaj konservas al vi la ŝlosilan rotacion.

Preferu ripari la kaŭzon kiam la ŝablono permesas tion. Renovigo kiu malsukcesas duonvoje dum la unua manpremo sukcesis montras al la vojo kaj ne al la tempigilo: serĉu problemon pri paketa grando en la pli granda interŝanĝo de la regkanalo, stata fajroŝirmilo kiu faligas la fluon, aŭ propono kiu sukcesas nur je la unua provo. Ĉiu el tiuj lasas spuron en la sama protokolo kiun vi ĵus legis. Malŝalti la tempigilon kaŝas tiun pruvon.

Kiam la intervalo montras aliloken

Du najbaroj en la agordo produktas similajn simptomojn kaj malsamajn riparojn. ping-restart restartigas la tunelon kiam nenio alvenas dum agordita periodo, dum ping-exit tute mallevas la klienton. Senokupa interrompo sen iu ajn rekontraktado en la protokolo apartenas al ĉi tiuj, aŭ al NAT-aparato kiu lasis la UDP-mapadon eksvalidiĝi laŭ sia propra horaro.

Konsumantaj enkursigiloj, movaj hotspot-oj kaj telekomunikaj NAT ĉiuj lasas senokupajn UDP-sesiojn eksvalidiĝi sen diri al iu. Tiu fiasko sekvas senokupecon kaj ne la horloĝon, kaj tio estas la signo: sesio kiu falas post dek kvietaj minutoj kaj postvivas horon da stabila trafiko ne rekontraktas.

Notu tri aferojn antaŭ ol ŝanĝi kvaran: la intervalon kiun vi mezuris, la efektivan valoron kiun vi trovis kaj la komandon kiu montris ĝin. Se la intervalo moviĝas kiam la tempigilo moviĝas, la mekanismo estas identigita kaj la riparo estas decido pri la supra interŝanĝo. Se ĝi ne moviĝas, remetu la agordon kaj daŭre rigardu keepalive, NAT-staton kaj pakoperdon.