NFS oer TCP yn in OpenVPN UDP-tunnel: twa transporten

In NFS-petear dat TCP brûkt binnen in tunnel dy’t UDP draacht, is hielendal konsekwint, en it bringt minsken yn ’e war om’t it twa transporten tagelyk neamt. TCP is it petear fan ’e tsjinst foar bestannen tusken de klant en de NFS-tsjinner. UDP is de fersifere drager tusken de VPN-einpunten. Gjin fan beide seit eat oer de oare.

Skriuw beide apart op foardat jo eat debugge; de measte fan dizze foarfallen begjinne as immen de ferkearde laach feroaret.

Twa lagen, twa ynstellingen

De mountopsje proto=tcp beskriuwt hoe’t de NFS-klant mei de NFS-tsjinner praat. De ynstelling proto udp fan it VPN-profil beskriuwt hoe’t de tuneleinpunten ynkapsele pakketten útwikselje. In mountopsje feroarje feroaret de tunnel net, en it transport fan ’e tunnel feroarje feroaret net wat de NFS-klant úthannele hat. Befêstigje de effektive mountopsjes mei nfsstat -m yn stee fan ’e fstab-rige, en befêstigje it VPN-transport út it profil dat echt brûkt wurdt.

Skriuw se dan yn ’e foarvalnotysjes as twa aparte fjilden. In skynbere ferbettering is allinnich te folgjen as de notysje seit hokker laach feroare is.

Blêdzje is gjin massaal lêzen

In mapylist bewiist dat guon bewurkingen klear binne. It bewiist net dat in oanhâldend lêzen, in skriuwen, in slot of de efterkant fan ’e opslach ûnder deselde omstannichheden klear komt. In stûring healwei in grut bestân is in oare waarnimming as in mount dy’t nea slagget, en se wize op ferskate lagen.

Beskriuw de mislearjende bewurking krekt: paad, rjochting, it likernôch punt fan ’e stûring en it lêste relevante barren yn ’e logs fan ’e klant, de tsjinner en it VPN. Ferlykje dan wêr’t ferkear trochgiet en wêr’t it stopet.

MTU is in hypoteze, gjin diagnoaze

Ferlies dat ôfhinget fan ’e pakketgrutte is in echte mooglikheid as in tunnel grutte segminten draacht, en it leveret krekt it patroan dat blêdzje wurket en lêzen fêstsit. Dat patroan bewiist lykwols gjin MTU-probleem, want deselde foarm ferskynt as in tsjinner stadich is, in brânmuorre in langduorjende ferbining troch in tiidlimit slút, of in skiif beset is. Test de hypoteze mei in kontrolearre probe yn stee fan oeral de MTU te ferleegjen en de oerwinning oan te kundigjen.

In tiidlimit op himsels seit neat oer oft UDP ferfongen wurde moat. It is in symptoom mei ferskate mooglike eigners.

Feroarje ien fariabele tagelyk

As jo transporten ferlykje, hâld dan de NFS-wurklast en elke oare ynstelling fêst. It mounttransport, it tunnelprotokol en de MTU yn itselde ûnderhâldsfinster feroarje jout in resultaat dat nimmen taskriuwe kin. Rinn deselde bestânbewurking foar en nei, en skriuw de útkomst by elke stap op.

Bewarje ek de eardere wearden yn it ticket. As in feroaring dingen minder makket, moat de weromgong in dokumintearre nûmer wêze yn stee fan immens ûnthâld fan hoe’t it earder wie.

Lês de laach dy’t mislearre

As de tunnel oan is en it NFS-fersyk wachtet, hat it VPN net mislearre; de tsjinst foar bestannen hat. As de tunnel del gie, is it mislearjen fan it NFS-fersyk in gefolch en gjin oarsaak. It ferlykjen fan logregels út beide lagen is de fluchste manier om dy twa gefallen te skieden, en it is better as rieden út ’e bestânbehearder.

Skriuw de konklúzje as twa sinnen, ien per laach. Dat is genôch foar de folgjende persoan om de test te werheljen sûnder opnij ôf te lieden hokker transport hokker is.