Epäillyn VPN MTU -ongelman testaaminen arvaamatta arvoja

Internetin MTU-arvojen luettelon kokeileminen, kunnes yksi tuntuu nopeammalta, ei ole testi vaan etsintä ilman pysäytyssääntöä. Toimiva menetelmä muuttaa yhtä hallittua kokoehtoa ja vertaa tulosta samaan polkuun. Aloita toistettavasta ja vaarattomasta virheestä ja pidä toimiva kokoonpano, jonka avulla voit perua kokeen. Kaikki alla olettaa tämän kurinalaisuuden, sillä ilman sitä jää luku, jota et voi puolustaa.

Kiinnitä polku ennen kuin muutat lukua

Kirjaa laite, käyttöliittymä, tunneliprotokolla, päätepiste, kohde ja osoiteperhe ennen kuin kosket asetusta. Nämä kuusi tosiasiaa ovat polku, ja toiseen polkuun kohdistuva kokeilu mittaa toista ongelmaa. Ne tekevät tuloksesta myös toistettavan, ja juuri se erottaa testin päivästä näpräämistä. Pidä muistiinpano päätteen vieressä äläkä päässäsi.

Aloita kapeimmasta testistä, jonka saat suorittaa. Palvelinpuolen muutos tavoittaa jokaisen kyseisen päätepisteen käyttäjän, joten se kuuluu tutkinnan loppuun, ei alkuun.

Kokeile koolla, jota hallitset

Linuxissa kokeilu näyttää tältä: ping -M do -s 1400 host, ja Windowsissa tältä: ping -f -l 1400 host. Molemmissa tapauksissa asetat hyötykuorman etkä paketin kokoa, koska IP- ja ICMP-otsakkeet lisätään päälle.

Lue edessäsi olevan järjestelmän dokumentaatiota sen sijaan että kopioit valitsimen foorumiviestistä. Valitse kohde, jota hallitset, jotta puuttuva vastaus on signaali eikä arvoitus. Kirjaa tarkka komento ja tarkka koko samaan muistiinpanoon kuin polku. Tulos ilman kokoa on anekdootti. Jos muutat yhdellä ajokerralla kahta asiaa, et tiedä kumpi tuotti tuloksen.

Epäonnistunut kokeilu ei todista MTU-rajaa

Hylätty kokeilu voi tarkoittaa ICMP-suodatusta eikä kokorajaa, ja tämä virhe saa ihmiset säätämään arvoa, joka ei koskaan ollut ongelma. Vertaa kokeilua todelliseen sovellukseen ja kokoon liittyvään virheilmoitukseen tai rajattuun kaappaukseen ennen kuin muutat mitään. Onnistuneet pienet pingit eivät todista mitään, koska ne voivat olla mukavasti rajan alapuolella. Kaksi riippumatonta havaintoa on vähimmäisvaatimus ennen kuin kokoonpano liikkuu.

Jos sovellus epäonnistuu kokeilun onnistuessa, sinulla on todiste siitä, että kyse ei ole yksinkertaisesta kokorajasta tällä polulla. Kirjaa se, sillä se poistaa kokonaisen haarukan mahdollisia muutoksia.

Säädä yhtä parametria, jota asiakas jo tukee

Muuta asetusta, jonka asiakas dokumentoi tälle protokollalle, ja jätä päätepiste ja kohde koskemattomiksi, muuten muutit kahta asiaa kerralla. TCP MSS -puristin ei kata kaikkea UDP-kuormaa, minkä vuoksi selain, joka alkaa toimia, voi jättää tunneliprotokollan täsmälleen yhtä rikki. IPv4 ja IPv6 ovat tässä erillisiä polkuja, koska otsakkeet eroavat ennen kuin mikään reititys tekee mitään.

Testaa molempia perheitä, jos julkaiset molemmat, sillä tulos toisesta ei kerro toisesta mitään. Arvo, joka toimi tällä polulla tänä iltana, on datapiste eikä koko VPN:n MTU. Älä ylennä sitä yleiseksi asetukseksi yhden onnistuneen siirron perusteella. Kirjaa arvo sen polun viereen, josta se tuli.

Peru, vahvista ja kirjaa

Palauta alkuperäinen arvo, jos vertailu ei tue hypoteesia. Tarkista, ettei verkkohallinta ole tallentanut pysyvää ohitusta muualle, sillä niin kokeesta tulee käytäntö. Yhdistä uudelleen ja kokeile tavallisia sovelluksia, älä vain sitä, jota testasit. Kirjaa sitten oire, tehollinen polku, vanha ja uusi arvo sekä se, kuinka toistettava tulos oli.

Säilytä tämä kirjaus muutospyynnön yhteydessä ennen kuin kukaan laajentaa muutosta. Mekanismi polun MTU:n havaitsemiseen RFC 1191:ssä selittää, miksi pienempi arvo voi pelastaa yhden polun ja olla tekemättä toiselle mitään, eikä lukuluettelo korvaa tätä mallia. Testi on valmis, kun osaat nimetä polun, koon, havainnon ja palauttamasi arvon.