Store pakkar forsvinn over IPsec medan små ping enno verkar
Små prøvar svarar og filkopieringar stoppar, og det er signaturen til eit storleiksval som blir teke før krypteringa. Finn ut kva side som deler pakken og kvifor.
Fjerne skal held fram med å svare, små prøvar svarar, og så kryp ein filkopiering og stoppar utan nokon feil nokon kan peike på. Ping med større nyttelast gjer det same med ein gong, og den same overføringa verkar frå det lokale nettet. Ingenting ved krypteringa er tregt; visse pakkar kjem aldri fram. To ulike delingar kan gje den signaturen, og dei lèt att ulike spor.
To stader ein pakke kan delast
Før krypteringa kan rutaren dele ein for stor indre pakke og verne kvar del for seg. Etter krypteringa er det den ferdige ytre pakken som blir delt, og den fjerne enden må setje han saman att før han kan dekryptere noko. Same symptomet, anna arbeid for mottakaren og andre knappar for deg.
Skilnaden har noko å seie fordi ei retting mot feil side endrar eit tal utan å flytte feilen. Ein pakke som blir avvist i grensesnittet blir aldri ein ytre pakke, så ingen innstilling på yttersida kan redde han.
Kvar storleiksvalet eigentleg blir teke
Eit tunellgrensesnitt ber ein IP MTU, og den verdien kan avvise ein for stor indre pakke lenge før IPsec-trinnet ser han. Å setje ein bit i det ytre hovudet tek ikkje opp att det tidlegare valet, fordi pakken alt er avvist. Derfor gjer ein høgare indre MTU det stundom verre i staden for betre. Les grensesnittverdien og den ytre åtferda før du endrar nokon av dei, fordi den billegare endringa oftast er den som forklarar symptomet.
Kontroller grensesnittverdien først, deretter den ytre åtferda. To tal, to trinn, og vanlegvis er berre eitt av dei ansvarleg.
Det ytre budsjettet er ikkje det indre budsjettet
Kvar innkapsling brukar byte på hovud, og mengda kjem an på transporten, adressefamilien og om NAT-traversering er i spel. Ein indre pakke som passar på den lokale lenkja kan framleis gje ein ytre pakke som ikkje passar på vegen bak han. Mål overheaden i staden for å rekne han med, fordi kvart valfrie hovud kjem på rekninga. Ein tunell med NAT-traversering betalar meir enn ein bar, og skilnaden er nok til å øydeleggje ei overføring som verka i går.
Når den ytre pakken ber ikkje-fragmenter-biten, slepp eit hopp som ikkje kan sende han vidare han, og bør returnere ei ICMP-melding. Om den meldinga blir filtrert ein stad, held sendaren fram med å prøve, og brukaren ser ein stopp utan forklaring. Den stille droppen er den vanlege grunnen til at eit storleiksproblem blir rapportert som eit hastigheitsproblem.
IPv6 fjernar eitt av alternativa
IPv6-rutarar fragmenterer ikkje undervegs, så den ytre pakken passar anten eller forsvinn med ei Packet Too Big-melding. Den meldinga blir den einaste tilbakemeldingskanalen, og å blokkere henne bryt stioppdaginga for kvar stor overføring som kjem etter. IPv4-rutarar kan fragmentere ein stor pakke når biten er klar, noko som skjuler feilen til noko anna set den biten.
På ein blanda stakk kan den same tunellen oppføre seg ulikt for dei to familiane, og difor avgjer ikkje éin test over IPv4 ei IPv6-klage. Ein kontroll som øver éin familie, lèt halve svaret vere umålt.
TCP-segmentpolitikk er ikkje eit generelt svar
Å avgrense maksimal segmentstorleik hjelper TCP-straumar, og det er ein legitim kontroll når problemet er avgrensa til dei. Det har inga verknad på UDP, som ber DNS, nokre taleprotokollar og ein veksande del av nettraffikken.
Bruk han, og test deretter arbeidsmengda som feila. Om UDP-tilfellet framleis feilar, var segmentpolitikken aldri svaret, og grensesnittbudsjettet treng framleis merksemd. Identifiser først protokollen til arbeidsmengda som feilar, og vel deretter kontrollen som høyrer til han.
Rekkjefylgja å arbeide i
Noter den største nyttelasta som overlever, deretter MTU-en til grensesnittet, deretter om den ytre pakken ber ikkje-fragmenter-biten, og til slutt om ICMP-tilbakemeldinga når sendaren. Den sekvensen snevrar inn feilen utan å gisse. Ta vare på kvar observasjon med tidsstempel og endepunkt, fordi alle fire tala flyttar seg når vegen blir endra.
Endre éin verdi, test den opphavlege overføringa på nytt og ta vare på resultatet. Ein tunell som klarer ein stor prøve men framleis stoppar i applikasjonen, har flytta seg til eit anna problem, og det er framgang som er verdt å skrive ned. Den neste personen vil heller ha tala enn konklusjonen.