TCP funkcias kaj UDP atingas alian servilon sur la sama pordo

Profilo funkcias per TCP kaj malsukcesas per UDP kun atentigo pri atestilo. La intuicia legado estas ke la UDP-vojo rompis la fidon, kaj la intuicia korekto estas akcepti la atestilon. Ambaŭ supozoj preterlasas eblecon kiu plene klarigas la simptomon: la du transportoj atingis malsamajn maŝinojn. Plusenda regulo estas kongruigita laŭ protokolo, kaj nenio devigas la TCP- kaj UDP-duonojn de unu pordnumero montri al la sama gastiganto.

Unu pordnumero, du sendependaj reguloj

Plusendo estas tabela serĉo laŭ protokolo, celadreso kaj pordo. Pordego kun regulo por TCP 1194 kaj regulo por UDP 1194 esprimas du sendependajn decidojn, kaj ili povas nomi malsamajn internajn gastigantojn. La komuna numero estas komforto por homoj, ne eco kiun la reto trudas. Traktu la pordnumeron kiel etikedon kaj ne kiel servodefinon.

Rigardu la validajn regulojn kaj ne la intencitajn. Celadreso, tradukita pordo kaj enira interfaco ĉiuj partoprenas, kaj regulo restinta de pli frua migrado estas la kutima kaŭzo ke la du duonoj ne kongruas.

Skribu ambaŭ mapojn antaŭ ol ŝanĝi ion alian. La linia paro estas la tuta hipotezo.

Kion la kliento vere kontrolis

Dum la manpremo la kliento kontrolas la atestilon kontraŭ la agordita fido kaj kontraŭ la nomo kiun ĝi atendas. Neatendita atestilo estas sukcesa kontrolo kiu malsukcesis la identeckontrolon, kaj tio estas la ĝusta rezulto kiam la alia flanko ne estas tiu kiun vi volis atingi. Rifuzi ĝin estas pruvo ke la kliento funkcias, ne ke la transporto estas rompita. Legu la raportitan nomon antaŭ la raportita ĉeno, ĉar la nomo estas tio kion la kliento komparis.

La distingo gravas ĉar la du fiaskoj kondukas al malsamaj korektoj. Fidproblemo bezonas fidkorekton, dum neatendita flanko bezonas korekton de enkursigo aŭ plusendo.

Notu kiun identecon la kliento raportis. Tiu nomo estas la plej forta indiko pri tio kiu maŝino respondis.

Kunligu la provon kun servilo

Registru la profilon, la publikan adreson, la transporton kaj la pordon kiujn la kliento uzis. Poste kongruigu la tempon de la provo kun la protokolo de la servilo kiun vi volis atingi. Ĝia manko tie estas indiko kaj ne pruvo de forĵeto fare de fajroŝirmilo, ĉar protokolaj niveloj varias inter instaladoj. Tempomarko kune kun fontadreso limigas pli ol ĉiu el ili sola.

Komparu la atestilan identecon kiun vi renkontis kun la atendita identeco per administra kanalo. Ĝuste tiu komparo ekster la kanalo konservas la kontrolon fidinda.

Kontrolu malnovajn plusendajn regulojn, alternativajn aŭskultantojn kaj ajnan ŝarĝekvilibran vojon antaŭ ol konkludi ke ambaŭ transportoj dividas malantaŭon. Ĉiu el ili povas plusendi fluon sen tuŝi la alian transporton.

Ne adaptu la fidon al malĝusta flanko

Importi la neatenditan CA forigas la simptomon kaj ŝanĝas al kiu la kliento fidas. Ĝi estas pli malbona stato ol malsukcesa konekto, ĉar ĝi kaŝas la malkongruecon anstataŭ solvi ĝin. La samo validas por malŝalti la kontrolon nur por vidi ĉu la tunelo leviĝas.

Se la flanko montriĝas laŭleĝa sed neintenca, la ĝusta ago estas maldaŭrigi ĝin aŭ direkti la regulon al la ĝusta gastiganto. La fidtenejo ne estas la loko por akordigi inventaran eraron.

Konservu la rifuzan tekston. Ĝi estas la sola registro pri tio kion la kliento vidis.

Post la korekto, testu novan fluon

Korektu la mapon kaj poste konektu per nova klienta seanco. Stattena tradukado povas teni ekzistantan fluon direktita al la malnova celo, do establita konekto povas postvivi la ŝanĝon kaj misgvidi vin. Komencu novan kaj konfirmu el la protokolo de la celita servilo ke ĝi traktis la provon.

Se ambaŭ transportoj pruveble atingas la saman servilon kaj tamen kondutas malsame, la restanta diferenco estas la propraj aŭskultantoj kaj agordo de tiu servilo. La komparo de transportoj havas sencon nur post kiam la identeco de la finpunkto estas fiksita.