Backtrack ng replay ng OpenVPN sa log: ano ang hindi pinapatunayan ng linya

Sinasabi ng linya na PID_ERR replay-window backtrack occurred, at ipinapaliwanag ito ng lahat ng resulta ng paghahanap bilang mga paketeng nahulog at sirang tunnel. Sa landas ng UDP ng Community OpenVPN 2.6, isinusulat ang mensaheng iyon habang nagpapasya pa ang function ng pagtanggap kung ano ang gagawin sa pakete. Itinatala nito ang bagong pinakamataas na backtrack, pagkatapos ay inihahambing ng parehong function ang distansya sa window at sa naitalang estado bago ito tumanggap o tumanggi. Ang pagbasa sa label ng log bilang hatol ang pagkakamaling gustong pigilan ng checklist na ito.

Unang hintuan: tukuyin kung ano ang linya

Ito ay diagnostic tungkol sa distansya ng sequence, hindi desisyon tungkol sa isang koneksyon. Lumilitaw ito sa implementasyon ng packet ID sa puntong itinatala ang bagong naobserbahang pinakamataas na backtrack. Ang puntong iyon ay bago ang sangay ng pagtanggap o pagtanggi, kaya ang paketeng nagdudulot nito ay maaari pa ring maihatid.

Tiyakin kung aling host ang sumulat nito at sa anong antas ng detalye. Ang server at kliyente ay parehong makakapaglabas ng mga mensahe ng packet ID, at ang mensahe mula sa isang panig ay walang sinasabi tungkol sa kalagayan ng pagtanggap sa kabilang panig.

Ikalawang hintuan: hanapin ang resulta para sa paketeng iyon

Basahin ang mga linya pagkatapos ng diagnostic, hindi lamang ang diagnostic. Nagpapatuloy ang parehong function sa mga pagsusuri ng window at duplicate, kaya ang resulta para sa partikular na paketeng iyon ay napagpapasyahan pagkalipas ng ilang instruction at maaaring pagtanggap nga. Ang bahagi ng log na nagtatapos sa nakakatakot na linya ay walang sinasabi tungkol sa resulta. Maghanap ng window sa paligid nito, hindi ang linya mismo:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Kung hindi nagpapakita ang log ng anumang pagtanggi para sa peer na iyon sa oras na iyon, itigil ang pagtrato sa linyang ito bilang sanhi ng pagkaputol. Pumunta sa landas ng app, dahil doon talaga nagtatapos ang karamihan ng ulat na konektado ngunit walang trapiko.

Ikatlong hintuan: magpasya kung totoo ang muling pag-aayos

Ang muling pag-aayos ay katangian ng landas, at ang isang diagnostic ay isang sample lamang nito. Maghanap ng paulit-ulit na mensahe para sa parehong peer sa maikling window, at ihambing sa isang capture sa dalawang dulo bago magpasyang agresibong nag-aayos muli ang network.

Ang ilang mensahe habang muling kumokonekta ay hindi kataka-taka. Ang tuloy-tuloy na daloy kasama ng tunay na timeout ng app ay dapat imbestigahan, at ang kombinasyong iyon ay ebidensya, hindi label.

Ikaapat na hintuan: ang mga parameter ng window, at kung ano ang hindi nila

replay-window ay tumatanggap ng laki ng sequence at opsyonal na halaga ng oras, kaya ang pagpapalawak nito ay nagbabago ng dalawang magkaibang toleransya nang sabay. Ang pagtaas ng bilang ay tumatanggap ng mga paketeng mas malayo sa pagkakasunod-sunod; nililimitahan ng halaga ng oras kung gaano katagal maaari pang isaalang-alang ang isang pakete. Ang pagpapalawak ay pagbabago ng patakaran na may gastos sa seguridad, at hindi nito pinapalakas ang cipher o pinapatay ang pagtukoy ng duplicate. Magkasamang gumagalaw ang dalawang toleransya, gusto mo man o hindi.

Ang lumang authenticated na pakete ay maaari pa ring hindi gustong pag-uulit, kaya pinapanatili ng tatanggap ang mga pagsusuring ito. Ang pagtanggap ng mas maraming muling pag-aayos ay nangangahulugan ng pagtanggap ng mas marami sa panganib na iyon.

Ang pagpapatahimik sa babala gamit ang mute ay nagbabago ng nakikita mo, hindi ng ginagawa ng daemon. Kung ang layunin ay mas tahimik na log sa isang kilalang pangyayari, ito ay lehitimong pagpipilian sa operasyon; kung ang layunin ay ayusin ang isang tunnel, itinatago ng pagpapatahimik ang ebidensya.

mute 20
replay-window 64 15

Ang paglipat ng panlabas na transportasyon sa TCP ay nagbabago ng pag-uugali ng paghahatid at pagbawi at nagdaragdag ng sarili nitong gastos sa pagharang ng ulo ng pila. Ito ay desisyon sa disenyo, hindi unang tugon sa isang label ng log. Ang muling pag-install ng server ay mas masama, dahil binubura nito ang pagkakaiba ng istatistika at ng hangganang talagang nabigo.

Ikalimang hintuan: subukan ang landas na mahalaga sa gumagamit

Habang konektado ang tunnel, patakbuhin ang sariling pagsubok ng app at basahin ang napiling ruta, kalagayan ng pagpapasa at landas ng pagbabalik. Ang tunnel na nagdadala ng mga pakete sa isang direksyon lamang ay hindi gumagawa ng anumang mensahe ng backtrack, at iyon ay mas karaniwan kaysa sa matinding muling pag-aayos.

Isulat kung ano ang sinukat mo sa bawat hintuan. Ang talaan ang pumipigil sa susunod na ulat na magsimula muli sa nakakatakot na linya at magtrabaho papalabas mula roon.

Ang implementasyon ng packet ID ay nagpapakita ng pagkakasunod-sunod ng istatistika at desisyon, at inilalarawan ng manwal ang saklaw ng sequence at oras ng window. Ang pagbasa sa dalawa nang magkasama ang nagbabago ng nakakatakot na linya ng log tungo sa kilalang dami. Wala sa dalawa ang nagsasabi ng anuman tungkol sa iyong partikular na landas, kaya mahalaga pa rin ang mga sukat sa itaas.