NFS per TCP ene de UDP-tunelo de OpenVPN: du transportoj

Porti NFS-konversacion, kiu uzas TCP, ene de tunelo, kiu portas UDP, estas tute konsekvenca, kaj ĝi konfuzas homojn, ĉar ĝi samtempe nomas du transportojn. TCP estas la dosier-serva konversacio inter la kliento kaj la NFS-servilo. UDP estas la ĉifrita portanto inter la VPN-finpunktoj. Neniu el ili implicas ion pri la alia.

Notu ambaŭ aparte antaŭ ol vi komencos sencimigi ion ajn; la plej multaj el ĉi tiuj incidentoj komenciĝas per tio, ke iu ŝanĝas la malĝustan tavolon.

Du tavoloj, du agordoj

La muntada opcio proto=tcp priskribas, kiel la NFS-kliento parolas kun la NFS-servilo. La agordo proto udp de la VPN-profilo priskribas, kiel la tunelaj finpunktoj interŝanĝas enkapsuligitajn pakaĵojn. Ŝanĝi muntadan opcion ne ŝanĝas la tunelon, kaj ŝanĝi la transporton de la tunelo ne ŝanĝas tion, pri kio la NFS-kliento interkonsentis. Konfirmu la efektivajn muntadajn opciojn per nfsstat -m anstataŭ la fstab-linio, kaj konfirmu la VPN-transporton el la profilo, kiu efektive estas uzata.

Poste notu ilin en la incidentaj notoj kiel du apartajn kampojn. Ŝajna plibonigo estas spurebla nur se la noto diras, kiu tavolo ŝanĝiĝis.

Retumi ne estas amasa legado

Dosieruja listo pruvas, ke iuj operacioj finiĝis. Ĝi ne pruvas, ke longdaŭra legado, skribo, ŝloso aŭ la stokada postaĵo finiĝos sub la samaj kondiĉoj. Halto meze de granda dosiero estas alia observo ol muntado, kiu neniam sukcesas, kaj ili montras al malsamaj tavoloj.

Priskribu la malsukcesan operacion precize: vojo, direkto, proksimuma punkto de la halto, kaj la lasta grava evento en la protokoloj de la kliento, la servilo kaj la VPN. Poste komparu, kie la trafiko daŭras kaj kie ĝi haltas.

MTU estas hipotezo, ne diagnozo

Perdo dependa de pakaĵgrandeco estas reala ebleco, kiam tunelo portas grandajn segmentojn, kaj ĝi produktas ĝuste la ŝablonon, ke retumado funkcias kaj legado haltas. Tamen tiu ŝablono ne pruvas MTU-problemon, ĉar la sama formo aperas, kiam servilo estas malrapida, kiam fajroŝirmilo finas longdaŭran konekton pro tempolimo, aŭ kiam disko estas okupata. Testu la hipotezon per kontrolita provo anstataŭ malaltigi la MTU ĉie kaj deklari venkon.

Tempolimo sola diras nenion pri tio, ĉu UDP devus esti anstataŭigita. Ĝi estas simptomo kun pluraj eblaj posedantoj.

Ŝanĝu unu variablon samtempe

Kiam vi komparas transportojn, tenu la NFS-laborŝarĝon kaj ĉiujn aliajn agordojn stabilaj. Ŝanĝi la muntadan transporton, la tunelan protokolon kaj la MTU en la sama bontenada fenestro produktas rezulton, kiun neniu povas atribui. Rulu la saman dosieran operacion antaŭe kaj poste, kaj notu la rezulton ĉe ĉiu paŝo.

Konservu ankaŭ la antaŭajn valorojn en la bileto. Se ŝanĝo plimalbonigas la aferojn, la retroiro devus esti dokumentita nombro, ne ies memoro pri tio, kiel ĝi estis antaŭe.

Legu la tavolon, kiu malsukcesis

Se la tunelo estas supren kaj la NFS-peto atendas, la VPN ne malsukcesis; la dosier-servo malsukcesis. Se la tunelo falis, la malsukceso de la NFS-peto estas sekvo, ne kaŭzo. Kunmeti protokolajn liniojn el ambaŭ tavoloj estas la plej rapida maniero distingi tiujn du kazojn, kaj ĝi superas divenadon el la dosieradministrilo.

Skribu la konkludon kiel du frazojn, unu por ĉiu tavolo. Tio sufiĉas, por ke la sekva persono ripetu la teston sen ree dedukti, kiu transporto estas kiu.