Keepalive ne estas rekonekto: elektu laŭ la misfunkcio, kiun vi havas

Keepalive kaj rekonekto agordiĝas samspire kaj solvas malsamajn problemojn, tial ĝustigo de la unu malofte riparas la alian. Keepalive sendas malgrandan trafikon por teni statan eron viva aŭ por rimarki, ke kunulo ĉesis respondi. Rekonekto malkonstruas tion, kio rompiĝis, kaj rekonstruas la rilaton, inkluzive de ŝlosiloj, adresoj kaj vojoj. Elektu la mekanismon kongruan al la misfunkcio, ne tiun, kies butonon vi jam konas. Du demandoj decidas tion: ĉu la vojo estas morta, aŭ ĉu io inter la kunuloj forgesas ĝin?

Kiam la mapado estas la problemo

Tunelo, kiu mortas nur post minutoj da silento, kutime perdas tradukeron kaj ne kunulon. La PersistentKeepalive de WireGuard ekzistas por NAT- kaj fajroŝirma stato, kaj la propraj notoj de la projekto priskribas ĝin ĝuste tiel, ne kiel san-kontrolon. Intervalo de kelkaj dekoj da sekundoj tenas eron varma, dum paketo ĉiun sekundon estas bateria decido kaj ne fidindeca. OpenVPN atingas la saman lokon per ping kaj ping-restart , kiuj unue rimarkas la silenton kaj poste agas laŭ ĝi.

Ankaŭ tiuj agordoj ne interŝanĝeblas inter protokoloj. Politiko de IKEv2 pri mortinta kunulo, ping-tempigilo de OpenVPN kaj keepalive de WireGuard respondas la saman demandon per tri malsamaj sintaksoj kaj tri malsamaj implicitaj valoroj, do kopii nombron inter ili estas konjekto vestita kiel ĝustigo.

Kiam la rilato mankas

Se la kunulo ŝanĝas adreson, la legitimilo eksvalidiĝas aŭ la malproksima fino restartas, malgrandaj paketoj ne estas la riparo. La rekonekto devas rekonstrui staton : akiri adreson, reinstali vojojn, renegoci ŝlosilojn kaj en kelkaj deplojoj reaŭtentigi uzanton.

Klientoj, kiuj rekonektas sen prizorgo, tenas atestilon aŭ konservitan sekreton. Kliento, kiu demandus homon, malsukcesas ĝuste kiam neniu ĉeestas, kaj tio estas la scenaro, kie la rekonekto gravis. Tio estas dizajna decido farita monatojn antaŭe, ne agordo, kiun vi povas ŝanĝi dum paneo.

Kion nek unu nek la alia pruvas

Tunelo povas esti rekonektita, ŝlosilita kaj vojigita dum la servo malantaŭ ĝi estas malaktiva, kaj keepalive povas teni mapadon malferma por sesio, kies servilo mankas de horoj. Ambaŭ mekanismoj povas raporti sukceson dum la afero, pri kiu vi vere zorgas, ne disponeblas.

Tial la testo finiĝas per reala peto. Sendu ion tra la tunelo post la intervalo, pri kiu vi zorgas, poste aparte kaŭzu la misfunkcion, por kiu vi projektis: periodo de senaktiveco por la mapada kazo, restarto aŭ adresŝanĝo por la rekonekta kazo.

Blokado de rekta trafiko estas aparta decido

Rekonekta buklo povas esti tute sana dum aplikaĵo kviete uzas la ordinaran vojon, kaj tio estas liko kaj ne misfunkcio. Se la postulo estas, ke nenio eliru ekster la tunelon, diru tion eksplicite en la klienta agordo kaj pruvu ĝin per malleviĝo de la tunelo kaj observado de tio, kio ankoraŭ konektas. Neniu mekanismo implicas tiun konduton, kaj nenia ripetdisciplino establas ĝin.

Notu, kiu mekanismo ruliĝis kaj ĉu nova peto sukcesis poste. Tiuj du faktoj estas tio, kion bezonas la sekva inĝeniero, kaj neniu el ili videblas en statusa ikono. Protokola linio, kiu diras, ke la kliento rekonektis, ne samas kiel peto, kiu funkciis.

Skribu la politikon, ne nur la nombron

Metu la paron en unu frazon: la senaktiva intervalo, la vivkapabla sojlo, kio kaŭzas rekonstruon , kaj kion la kliento faras dum ĝi ripetas. Sen tiu frazo, ĉiu estonta okazaĵo remalfermas la saman disputon pri tio, ĉu la keepalive estas tro mallonga aŭ la rekonekto tro malrapida.

La notoj de WireGuard pri limigoj estas utila memorigo, ke la keepalive estas provizora solvo por mezaj kestoj kaj ne ĝenerala vivkapabla dizajno. Legu tiun limigon antaŭ ol altigi la frekvencon respondante al problemo, kiun ĝi ne povas solvi.