NFS sa TCP sa loob ng UDP tunnel ng OpenVPN: dalawang transport

Ang pagdadala ng usapan ng NFS na gumagamit ng TCP sa loob ng tunnel na nagdadala ng UDP ay ganap na pare-pareho, at nakakalito ito dahil dalawang transport ang tinutukoy nito nang sabay. Ang TCP ang usapan ng serbisyo ng file sa pagitan ng client at ng NFS server. Ang UDP ang naka-encrypt na carrier sa pagitan ng mga dulo ng VPN. Wala sa dalawa ang nagpapahiwatig ng anuman tungkol sa isa.

Itala ang dalawa nang hiwalay bago mag-debug ng anuman; karamihan sa mga insidenteng ito ay nagsisimula kapag may nagbago ng maling layer.

Dalawang layer, dalawang setting

Ang opsyon sa mount na proto=tcp ay naglalarawan kung paano nakikipag-usap ang NFS client sa NFS server. Ang setting na proto udp sa profile ng VPN ay naglalarawan kung paano nagpapalitan ng encapsulated na packet ang mga dulo ng tunnel. Ang pagbabago ng opsyon sa mount ay hindi nagbabago ng tunnel, at ang pagbabago ng transport ng tunnel ay hindi nagbabago ng napagkasunduan ng NFS client. Tiyakin ang aktwal na mga opsyon sa mount gamit ang nfsstat -m sa halip na ang linya sa fstab, at tiyakin ang transport ng VPN mula sa profile na aktwal na ginagamit.

Pagkatapos, itala ang dalawa sa mga tala ng insidente bilang dalawang hiwalay na field. Ang tila pagbuti ay masusubaybayan lamang kung sinasabi ng tala kung aling layer ang nagbago.

Ang pag-browse ay hindi bulk read

Pinatutunayan ng listahan ng direktoryo na may mga operasyong natapos. Hindi nito pinatutunayan na ang tuloy-tuloy na pagbasa, pagsulat, lock, o backend ng storage ay matatapos sa parehong mga kondisyon. Ang paghinto sa kalagitnaan ng malaking file ay ibang obserbasyon kaysa sa mount na hindi kailanman nagtagumpay, at tumuturo sila sa magkaibang layer.

Ilarawan nang tumpak ang operasyong nabibigo: landas, direksyon, tinatayang punto ng paghinto, at ang huling kaugnay na pangyayari sa mga log ng client, server, at VPN. Pagkatapos ay ihambing kung saan nagpapatuloy ang trapiko at kung saan ito humihinto.

Ang MTU ay isang hinuha, hindi diagnosis

Ang pagkawalang nakasalalay sa laki ng packet ay totoong posibilidad kapag ang tunnel ay nagdadala ng malalaking segment, at ginagawa nito nang eksakto ang pattern na gumagana ang pag-browse pero humihinto ang pagbasa. Gayunpaman, hindi pinatutunayan ng pattern na iyon ang problema sa MTU, dahil lumilitaw ang parehong hugis kapag mabagal ang server, kapag nagtatapos ang firewall ng mahabang koneksyon dahil sa timeout, o kapag abala ang disk. Subukan ang hinuha sa isang kontroladong pagsusuri sa halip na babaan ang MTU sa lahat ng dako at ideklara ang tagumpay.

Ang timeout nang mag-isa ay walang sinasabi tungkol sa kung dapat bang palitan ang UDP. Ito ay sintomas na may ilang posibleng may-ari.

Baguhin ang isang variable sa isang pagkakataon

Kapag naghahambing ng mga transport, panatilihing stable ang workload ng NFS at lahat ng iba pang setting. Ang pagbabago ng transport ng mount, protocol ng tunnel, at MTU sa parehong maintenance window ay gumagawa ng resultang walang makapag-uugnay. Patakbuhin ang parehong operasyon sa file bago at pagkatapos, at itala ang resulta sa bawat hakbang.

Itabi rin ang mga dating halaga sa ticket. Kung may pagbabagong nagpapalala ng sitwasyon, ang pagbabalik ay dapat na dokumentadong numero at hindi alaala ng kahit sino kung ano ito dati.

Basahin ang layer na nabigo

Kung buhay ang tunnel at naghihintay ang kahilingan ng NFS, hindi ang VPN ang nabigo; ang serbisyo ng file ang nabigo. Kung bumagsak ang tunnel, ang pagpalya ng kahilingan ng NFS ay bunga at hindi sanhi. Ang pagtutugma ng mga linya ng log mula sa dalawang layer ang pinakamabilis na paraan upang makilala ang dalawang kasong ito, at mas mabuti ito kaysa manghula mula sa file manager.

Isulat ang konklusyon sa dalawang pangungusap, isa sa bawat layer. Sapat na iyon para sa susunod na tao na ulitin ang pagsubok nang hindi muling hinihinuha kung aling transport ang alin.