La VPN ne likis vian malnovan IP: tion faris memorita valoro

Vidi vian malnovan publikan adreson en raporto de servo post kiam la VPN aktiviĝis, per si mem ne estas pruvo de liko. La viva konekto povas uzi la eliron de la tunelo dum la aplikaĵo sendas valoron, kiun ĝi lernis antaŭ ol la tunelo ekzistis. Tiuj estas du malsamaj pruvoj, kaj nur unu priskribas la nunan pakon. La alia estas valoro, kiu postvivis la rekonektiĝon, ĉar nenio en la reta vojo posedas ĝin.

La du klarigoj malantaŭ unu adreso

La sinsekvo, kiun homoj imagas, estas pako forlasanta la fizikan interfacon dum la VPN laŭdire estas aktiva. La sinsekvo, kiu ofte klarigas la raporton, estas pli mallonga kaj pli enuiga: aplikaĵo lernis adreson pli frue kaj ankoraŭ tenas ĝin. Meti la eventojn en ordon apartigas la du.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Nenio en tiu ordo postulas vivan konekton de la unua adreso. La memorita valoro vojaĝas ene de la mesaĝo, dum la kaplinio portas kian ajn eliron la nuna vojo elektis. Servo, kiu registras ambaŭ kampojn, montros ilin unu apud la alia kaj aspektos kontraŭdira.

Tio estas ebla klarigo, ne akuzo kontraŭ iu ajn aparta kliento. Reputacio ne estas pruvo: kodaro, kiun vi povas legi, marko, kiun vi fidas, aŭ alia eliro diras nenion pri tio, kion unu programo retenis aŭ sendis.

La memoro de la aplikaĵo postvivas la rekonektiĝon

Konekti VPN ŝanĝas la vojon, kiun nova konekto prenas. Ĝi lasas la staton de la aplikaĵo trankvila kaj ne povas retiri informojn, kiujn fora servo jam konservis. Programo povas sendi kontan identigilon, konservitan lokon, aparatan nomon aŭ alian valoron akiritan pli frue, kaj ĉifrado protektas tiun ŝarĝon dumvoje sen forigi ion ajn el ĝi. La rekonektiĝo estas reta evento; la retenita valoro estas aplikaĵa evento.

La distingo gravas ĉar la du vivas en malsamaj lokoj. La stato de la aplikaĵo apartenas al la programo kaj postvivas restartigojn, dum la vojo apartenas al la operaciumo kaj estas rekonstruata ĉe ĉiu konekto. Purigi unu havas neniun efikon al la alia.

Servo ankaŭ povas teni valoron, kiun vi donis al ĝi antaŭ monatoj, kaj tiam neniu loka ŝanĝo forigos ĝin. Tio estas konservado, kaj ĝi staras tute ekster la tunelo.

Unue legu la fontan kaplinion, poste la ŝarĝon

Komencu per determini, kie la adreso aperis. La konekta protokolo de servilo priskribas la vivan fonton, dum mesaĝa kampo, konta profilo aŭ loka diagnoza ekrano povas priskribi valoron senditan aŭ konservitan multe pli frue. Tiuj observoj respondas al malsamaj demandoj.

Komparu ankaŭ la tempojn. Se la malnova adreso aperas en kampo, kiu antaŭas la VPN-konekton, la klarigo per ŝarĝo estas pli forta. Se la servilo registras rektan konekton de la malnova adreso dum la tunelo estas aktiva, tio estas enkursiga demando kaj bezonas alian esploron. Unue ordigi la observtipojn malhelpas, ke unu adreso etendiĝu en pruvon de tri eventoj.

Tenu ilin aparte en viaj notoj: konekta fonto, mesaĝa kampo, konta ekrano, loka diagnozo. Unu adreso skribita en kvar lokoj ankoraŭ estas unu adreso.

Konservado estas alia etapo ol transporto

La privatecaj gvidlinioj en RFC 6973 traktas kolektadon, uzon, malkaŝon kaj konservadon kiel apartajn etapojn, kaj ĝi avertas, ke reuzitaj identigiloj faciligas korelacion. Nova reta vojo ŝanĝas la transportan etapon kaj nenion alian. Riĉaĵoj, kiujn la ricevanto jam tenas, restas netuŝitaj, kaj same ajna profilo, kiu konservis la valoron survoje. Tial rekonektiĝo povas sentiĝi kiel malsukceso dum la transporto kondutas ĝuste.

Neniu paka filtrilo povas forigi valoron el la riĉaĵoj de ricevanto, kaj rekonekti denove ne purigos la konservitan historion de ĉiu programo. Tiuj estas problemoj de la posedanto de la datumoj, ne de la tunelo, kaj ili bezonas alian specon de solvo. Demandu la servon, kion ĝi konservas kaj kiom longe, antaŭ ol peti la reton kaŝi ĝin.

Kion kontroli antaŭ ol kulpi la tunelon

Revizu la dokumentitan kolektadon kaj kontajn kontrolojn de la aplikaĵo, kaj decidu, kiujn kampojn ĝi rajtas sendi, kiom longe la servo konservas ilin, kaj ĉu la konto povas forigi aŭ korekti ilin. Poste faru la teston, kiu apartigas la klarigojn: nova konto aŭ pura aplikaĵa profilo. Se la malnova valoro malaperas, konservado aŭ kaŝmemora stato estis implikitaj. Se ĝi postvivas puran profilon, ekzamenu la faktan petan kampon antaŭ ol konkludi, ke la VPN malsukcesis.

Se rekta konekto vere ekzistas, traktu ĝin kiel trovon de la reta vojo. Esploru enkursigon, dividitan tunelon kaj klientan politikon laŭ iliaj propraj kondiĉoj, kaj ne miksu tiun rezulton kun ŝarĝa valoro, kiu simple postvivis la rekonektiĝon. La du fiaskoj aspektas similaj en ekrankopio kaj kondutas tute malsame en kaptaĵo.