Testi suspektatan VPN-MTU-problemon sen diveni valorojn
Fiksu la vojon, registru la originajn valorojn, poste ŝanĝu unu grandeckondiĉon kaj komparu. Malsukcesa sondado povas esti ICMP-filtrado kaj ne MTU-limo.
Provi liston da interretaj MTU-valoroj ĝis unu ŝajnas pli rapida ne estas testo, ĝi estas serĉado sen haltregulo. La metodo, kiu funkcias, ŝanĝas unu kontrolatan grandeckondiĉon kaj komparas la rezulton kun la sama vojo. Komencu per ripetebla, senmalutila malsukceso kaj konservu la funkciantan agordon, kiu ebligas al vi malfari la eksperimenton. Ĉio sube supozas tiun disciplinon, ĉar sen ĝi vi restas kun nombro, kiun vi ne povas defendi.
Fiksu la vojon antaŭ ol ŝanĝi nombron
Notu la aparaton, la alirilon, la tunelan protokolon, la finpunkton, la celon kaj la adresan familion antaŭ ol tuŝi agordon. Tiuj ses faktoj estas la vojo, kaj sondado direktita al alia vojo mezuras alian problemon. Ili ankaŭ faras la rezulton ripetebla, kaj tio apartigas teston de posttagmezo da palpadado. Tenu la noton apud la terminalo anstataŭ en via kapo.
Komencu per la plej mallarĝa testo, kiun vi rajtas plenumi. Ŝanĝo ĉe la servila flanko atingas ĉiun uzanton de tiu finpunkto, do ĝi apartenas al la fino de la esploro, ne al la komenco.
Sondi per grandeco, kiun vi kontrolas
En Linux la sondado aspektas kiel ping -M do -s 1400 host, kaj en Windows kiel ping -f -l 1400 host. En ambaŭ kazoj vi agordas la utilan ŝarĝon kaj ne la pakgrandon, ĉar la IP- kaj ICMP-kapoj aldoniĝas supre.
Legu la dokumentaron de la sistemo antaŭ vi anstataŭ kopii flagon el forumafiŝo. Elektu celon, kiun vi kontrolas, por ke mankanta respondo estu signalo kaj ne enigmo. Notu la precizan komandon kaj la precizan grandecon en la sama noto kiel la vojo. Rezulto sen grandeco estas anekdoto. Se vi ŝanĝas du aferojn en unu rulo, vi ne scios, kiu el ili produktis la rezulton.
Malsukcesa sondado ne pruvas MTU-limon
Forĵetita sondado povas signifi ICMP-filtradon kaj ne grandeclimon, kaj tiu eraro igas homojn agordi valoron, kiu neniam estis la problemo. Komparu la sondadon kun la reala aplikaĵo, kaj kun grandec-rilata erarmesaĝo aŭ limigita kaptado, antaŭ ol ŝanĝi ion ajn. Sukcesaj malgrandaj pingoj ankaŭ pruvas nenion, ĉar ili povas komforte sidi sub la limo. Du sendependaj observoj estas la minimumo antaŭ ol agordo moviĝas.
Se la aplikaĵo malsukcesas dum la sondado sukcesas, vi havas pruvon, ke tio ne estas simpla grandeclimo sur tiu vojo. Notu tion, ĉar ĝi forigas tutan branĉon da eblaj ŝanĝoj.
Agordi unu parametron, kiun la kliento jam subtenas
Ŝanĝu la agordon, kiun la kliento dokumentas por ĉi tiu protokolo, kaj lasu la finpunkton kaj la celon netuŝitaj, alie vi ŝanĝis du aferojn samtempe. TCP-MSS-limigo ne kovras ĉiun UDP-ŝarĝon, tial retumilo, kiu komencas funkcii, povas lasi la tunelan protokolon same rompita. IPv4 kaj IPv6 estas apartaj vojoj ĉi tie, ĉar la kapoj malsamas antaŭ ol iu ajn enkursigo faras tion.
Testu ambaŭ familiojn, se vi publikigas ambaŭ, ĉar rezulto el unu diras nenion pri la alia. Valoro, kiu funkciis sur ĉi tiu vojo ĉi-vespere, estas datumo kaj ne MTU por la tuta VPN. Ne promociu ĝin al tutmonda agordo pro unu sukcesa transdono. Notu la valoron apud la vojo, el kiu ĝi venis.
Malfari, kontroli kaj noti
Remetu la originan valoron, se la komparo ne subtenas la hipotezon. Kontrolu, ĉu retadministrilo ne konservis aliloke daŭran anstataŭigon, ĉar tiel eksperimento fariĝas politiko. Rekonektiĝu kaj provu ordinarajn aplikaĵojn, ne nur tiun, kiun vi testis. Poste registru la simptomon, la efikan vojon, la malnovan kaj novan valorojn kaj kiom ripetebla la rezulto estis.
Konservu tiun registron kun la ŝanĝpeto antaŭ ol iu ajn plilarĝigos la ŝanĝon. La voja MTU-malkovra mekanismo en RFC 1191 klarigas, kial pli malgranda valoro povas savi unu vojon kaj fari nenion por alia, kaj listo da nombroj ne anstataŭas tiun modelon. La testo finiĝas, kiam vi povas nomi la vojon, la grandecon, la observon kaj la valoron, kiun vi restarigis.