Testo de baskiĝo: ĉu establita TCP-fluo postvivas?

Du rezultoj kaŝiĝas en la frazo, ke la rezervo funkcias. Nova peto sukcesas, tio estas restarigo. Translokigo jam en progreso daŭras, tio estas kontinueco. Tiuj estas malsamaj promesoj, kaj la plej multaj baskiĝaj projektoj liveras la unuan dum la dua silente finiĝas pro tempolimo. Decidu, kiun vi bezonas antaŭ ol elekti mekanismon, kaj skribu la teston tiel, ke ĝi povu distingi ilin.

Du rezultoj, kiuj aspektas kiel unu sukceso

Imagu klienton ĉe 10.90.0.42 kun konekto al 198.51.100.20:443. La ĉefa eliro tradukas tion al unu publika adreso kaj pordo, kaj la rezerva eliro tradukas ĝin al alia. La interna adreso de la kliento neniam ŝanĝiĝas, kaj tial homoj atendas, ke la konekto postvivos.

La servilo ne vidas internan adreson. Ĝi vidas la tradukitan finpunkton, kaj tiu finpunkto estas malsama post la ŝaltado.

Do la malnova fluo finiĝas pro tempolimo dum freŝa konekto al la sama servo funkcias tuj. Ambaŭ observoj veras samtempe.

Kion la servilo vidas, kiam la eliro ŝanĝiĝas

TCP-konekto estas identigita per sia kvarlisto, kaj ŝanĝo de la fonta adreso aŭ pordo kreas alian konekton laŭ la ricevanta gastiganto. Pakoj, kiuj alvenas de nova fonto sur konekto, kiun la servilo ne konas, estas forĵetitaj aŭ responditaj per restarigo. Nenio en la adreso de la VPN-kliento konservas la ligon tra tiu ŝanĝo.

Stata baskiĝo ekzistas ĝuste por eviti tion, kaj ĝi funkcias per interŝanĝo de traduka stato kaj konekta stato inter la plusendaj aparatoj. Tio estas eco de la paro, ne de la tunelo, kaj ĝi devas esti projektita kaj testita anstataŭ supozita.

Kontrolu, ĉu la paro vere konservas staton, antaŭ ol promesi kontinuecon al iu ajn. La subaj komandoj montras la nunan staton ambaŭflanke.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Kial la sama publika adreso ne sufiĉas

Konservi unu publikan adreson laŭ ambaŭ vojoj estas bona komenco, ĉar tiam la servilo vidas la saman fontan finpunkton. Ĝi tamen ne sufiĉas sola. La plusenda aparato ankoraŭ bezonas la tradukan staton, la fajromuran staton kaj uzeblan returnan vojon, kaj tiuj devas ekzisti sur tiu aparato, kiu portas la trafikon post la ŝaltado.

RFC 3022 priskribas adresan tradukon kaj traktas la interŝanĝon de stato inter tradukantaj aparatoj kiel parton de rezerva projekto. Flosanta adreso aŭ kopiita profilo movas la agordon sen movi la staton.

Tial testo, kiu nur pingas tra la rezervo, pruvas tre malmulte. Ping havas neniun konektan staton por perdi.

Decidu, kiom forta la postulo estas

Se uzantoj povas rekonekti post paneo, la projekto estas restariga projekto kaj la akcepta testo estas freŝa peto. Se dosiera translokigo devas postvivi, la projekto bezonas statan sinkronigon kaj multe pli zorgeman teston. Se fora seanco devas postvivi, la postulo estas denove pli forta kaj eble bezonas mekanismon je aplika nivelo anstataŭ je reta nivelo.

Skribu la postulon kiel frazon kun mezurebla rezulto, ekzemple la alŝuto finiĝas sen restarto aŭ la operatoro rekonektas ene de minuto. Poste elektu la plej malmultekostan mekanismon, kiu kontentigas ĝin, kaj tio ofte estas la restariga projekto.

Diru eksplicite, kio okazas, kiam la ĉefa vojo revenas, ĉar aŭtomata reeniro povas interrompi konekton, kiu ĵus resaniĝis sur la rezervo. Tiu kazo apartenas al la testa plano, ne al piednoto.

Kontrolu la malnovan fluon kaj la novan peton

Startigu sendanĝeran longdaŭran translokigon tra la ĉefa vojo, poste apartan freŝan peton al la sama servo. Notu la aplikaĵan kuntekston, la observitan eliran adreson kaj la tempon. Rompu la ĉefan vojon laŭ aprobita maniero kaj daŭre observu la originalan translokigon dum vi sendas la novan peton tra la rezervo.

Raportu tri valorojn: ĉu la malnova fluo daŭris, restarigis aŭ finiĝis pro tempolimo; kiam la nova operacio unue funkciis; kaj ĉu la reeniro interrompis ion. Tiuj tri linioj estas la akcepta registro.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Se la laborŝarĝo skribas datumojn, ne ripetu necertan operacion blinde post tempolimo. La skribo eble alvenis antaŭ ol la respondo perdiĝis. Demandu la aplikaĵon pri la rezulto, aŭ ripetu nur kie la operacio estas idempotenta. Poste skribu la akceptan deklaron en tri partoj: novaj operacioj resaniĝas laŭ la elira politiko, ekzistantaj fluoj havas la dokumentitan interrompan konduton, kaj la aplikaĵo daŭrigas sekure. Tiu deklaro estas testebla, kaj ĝi estas honesta pri tio, kion la projekto ne promesas.