Oras-oras na pagbagsak ng OpenVPN: muling negosasyon o tunay na muling pagkonekta?

Animnapung minuto, o tatlumpu, o isang daan at dalawampu: ang pagbagsak na tumapat sa isang bilog na pagitan ay halos hindi kailanman ang network. OpenVPN nagre-refresh ng materyal ng susi na nagpoprotekta sa channel ng data ayon sa timer, at ang timer na mas maikli kaysa sa inaasahan mo ay mukhang eksaktong isang link na paulit-ulit na nabibigo. Iniulat ng mga gumagamit ang sirang koneksyon habang iniuulat ng log ang matagumpay na pagpapalitan ng susi. Hinihiwalay ng gabay sa ibaba ang pag-refresh na iyon mula sa tunay na restart, binabasa ang halagang talagang may bisa, at binabago lamang ito pagkatapos mailagay ang gastos sa mesa.

Gawin ang mga hakbang nang sunod-sunod, dahil ang una ang nagpapasya kung ang natitirang bahagi ng pahina ay naaangkop sa iyo. Kung lalaktaw ka, gugugol ka ng isang gabi sa pag-tune ng timer para sa isang depektong walang kinalaman dito.

Iba ang malambot na reset sa restart

Ang linya ng log ang buong diagnosis. Ang muling negosasyon ay nagsusulat ng malambot na reset at pagkatapos ay isang bagong pagpapalitan ng susi sa loob ng parehong tunnel: pinapanatili ng interface ang address nito, hindi naidaragdag muli ang mga ruta, at ang mga naitatag na sesyon ng TCP ay karaniwang nakakaligtas nang may paghinto. Ang tunay na restart ay pumupunit sa sesyon, muling binubuo ang interface, maaaring magbigay ng ibang address ng kliyente, at pumapatay sa bawat pangmatagalang koneksyon. Parehong pangkaraniwan ang dalawang pangyayari; isa lamang sa kanila ang nagpapaliwanag ng putol na tawag.

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

Mahalaga ang linya ng bersyon dahil nagbabago ang pananalita ng log sa pagitan ng mga release, at ang mensaheng natatandaan mo mula sa 2.3 ay maaaring nakasulat nang iba sa 2.6. Basahin ang sarili mong log sa halip na sipi ng forum ng iba. Sipiin ang eksaktong linya kapag humihingi ka ng tulong, dahil ang paraphrasing ay nawawalan ng detalyeng tumutukoy sa pangyayari. Kung hindi nagbago ang address ng interface sa buong pangyayari at nakaligtas ang listahan ng sesyon, nakikita mo ang pag-refresh at naaangkop ang natitirang mga seksyon.

Basahin ang epektibong timer, hindi ang file mo

reneg-sec ay ang bilang ng mga segundo sa pagitan ng mga muling negosasyon ng channel ng data at ang default nito ay 3600. Ang bawat panig ay may sariling halaga, at ang mas maliit sa dalawa ang talagang nag-uudyok ng pag-refresh. Ang nag-iisang tuntuning iyon ang nagpapaliwanag sa karamihan ng mga ulat: ang profile ng kliyenteng nagtatakda ng malaking bilang ay nire-reset pa rin kada oras habang pinapanatili ng server ang default.

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

Basahin din ang epektibong configuration ng server, kabilang ang lahat ng itinutulak nito, bago ka gumawa ng konklusyon mula sa file ng kliyente. Pagkatapos ay taasan ang detalye at panoorin ang isang pagitan mula simula hanggang wakas: ang antas 3 ay nagpapakita na ng mga linya ng muling negosasyon, at sinasabi ng mga timestamp kung inuulit ang pangyayari tuwing 3600 segundo o sumusunod sa aktibidad.

Palitan ito kung saan talaga ito itinutulak

Ang umiikot na lunas ay isang linya sa profile ng kliyente, at ito ang maling lugar mga kalahati ng oras. Dahil ang mas mababang halaga ng panig ang nananaig, ang kliyenteng naglalagay ng timer sa zero ay maaari pa ring muling negosyohan ng server na hindi nagbago.

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

Kung ang mga profile ay ginagawa nang sentral, i-edit ang template at hindi ang naka-deploy na kopya, kung hindi ay ibabalik ng susunod na provisioning run ang halagang kaaalis mo lang. I-verify sa pamamagitan ng pagmamasid sa dalawang pagitan, hindi isa: ang isang tahimik na oras ay tugma rin sa timer na itinakda sa 7200.

Magpasya rin kung ano ang mangyayari sa pinaghalong deployment. Kung ilalabas mo muna ang pagbabago sa mga kliyente, may natitirang window kung saan pinapagana pa rin ng server ang pag-refresh; walang pinsala ito ngunit nakakalito kung pinapanood mo ang mga log para sa kumpirmasyon. Palitan muna ang panig na may mas maliit na halaga at mawawala ang sintomas sa puntong inaasahan mo.

Ano ang ibinibigay mo kapag i-disable ang muling negosasyon

Nililimitahan ng regular na muling negosasyon kung gaano katagal pinoprotektahan ng isang set ng mga susi ng channel ng data ang trapiko. Ang pagpatay sa timer ay hindi sumisira sa tunnel, at sa isang home router o maliit na gateway ng opisina ang praktikal na pagkakalantad ay katamtaman. Ito ay palitan pa rin, at ang palitan ay dapat banggitin bago mo ito gawin. Ang nagbabago ay kung gaano katagal pinoprotektahan ng isang set ng susi ang isang sesyon, hindi kung gumagana man lang ang tunnel.

Ang makatwirang kaso para sa pag-disable ay isang reset na sumisira sa isang bagay na hindi maipagpapatuloy: isang tawag na bumabagsak, isang remote desktop session na kailangang muling itayo, isang backup na nagsisimula mula sa simula. Kung hindi nakikita ng mga gumagamit ang paghinto, walang gastos ang pagpapanatili ng default at napapanatili ang rotation ng susi na ibinigay sa iyo.

Mas gustuhing ayusin ang sanhi kapag pinapayagan ng pattern. Ang pag-refresh na nabibigo sa kalagitnaan habang nagtagumpay ang unang handshake ay tumutukoy sa landas at hindi sa timer: maghanap ng problema sa laki ng packet sa mas malaking pagpapalitan ng control channel, isang stateful firewall na nagtatapon ng daloy, o isang panukalang nagtatagumpay lamang sa unang pagtatangka. Ang bawat isa ay nag-iiwan ng bakas sa parehong log na binasa mo lang. Itinatago ng pag-disable ng timer ang ebidensyang iyon.

Kapag ang pagitan ay tumuturo sa ibang lugar

Dalawang kapitbahay sa configuration ay gumagawa ng magkatulad na sintomas at magkaibang pagwawasto. Ang ping-restart ay nag-restart ng tunnel kapag walang dumarating sa loob ng itinakdang panahon, habang ang ping-exit ay nagbababa ng kliyente nang buo. Ang pagbagsak habang idle na walang anumang muling negosasyon sa log ay pag-aari ng mga ito, o ng isang NAT device na hinayaang mag-expire ang mapping ng UDP ayon sa sarili nitong iskedyul.

Ang mga consumer router, mobile hotspot at carrier-grade NAT ay hinahayaang mag-expire ang mga idle na sesyon ng UDP nang walang sinasabihan. Ang pagkabigong iyon ay sumusunod sa idle at hindi sa orasan, at iyon ang palatandaan: ang sesyong bumabagsak pagkatapos ng sampung tahimik na minuto at nakakaligtas ng isang oras na tuloy-tuloy na trapiko ay hindi nagre-negosasyon.

Isulat ang tatlong bagay bago baguhin ang ikaapat: ang pagitan na sinukat mo, ang epektibong halagang natagpuan mo at ang command na nagpakita nito. Kung gumagalaw ang pagitan kapag gumagalaw ang timer, natukoy ang mekanismo at ang pagwawasto ay desisyon tungkol sa palitan sa itaas. Kung hindi ito gumagalaw, ibalik ang setting at patuloy na panoorin ang keepalive, estado ng NAT at pagkawala ng packet.