Store pakker forsvinner over IPsec mens små ping fortsatt virker

Fjerne skall forblir responsive, små prober svarer, og så kryper en filkopiering og stopper uten noen feil noen kan peke på. Ping med større nyttelast gjenskaper det umiddelbart, og den samme overføringen virker fra det lokale nettet. Ingenting ved krypteringen er tregt; visse pakker kommer aldri frem. To forskjellige delinger kan gi den signaturen, og de etterlater forskjellige spor.

To steder en pakke kan deles

Før kryptering kan ruteren dele en for stor indre pakke og beskytte hver del for seg. Etter kryptering er det den ferdige ytre pakken som deles, og den fjerne enden må sette den sammen igjen før den kan dekryptere noe. Samme symptom, annet arbeid for mottakeren og andre knapper for deg.

Forskjellen betyr noe fordi en rettelse rettet mot feil side endrer et tall uten å flytte feilen. En pakke som avvises i grensesnittet blir aldri en ytre pakke, så ingen innstilling på yttersiden kan redde den.

Hvor størrelsesbeslutningen egentlig tas

Et tunnelgrensesnitt bærer en IP MTU, og den verdien kan avvise en for stor indre pakke lenge før IPsec-trinnet ser den. Å sette en bit i det ytre hodet revurderer ikke den tidligere beslutningen, fordi pakken allerede er avvist. Derfor gjør en høyere indre MTU noen ganger ting verre i stedet for bedre. Les grensesnittverdien og den ytre oppførselen før du endrer noen av dem, fordi den billigere endringen vanligvis er den som forklarer symptomet.

Kontroller grensesnittverdien først, deretter den ytre oppførselen. To tall, to trinn, og vanligvis er bare ett av dem ansvarlig.

Det ytre budsjettet er ikke det indre budsjettet

Hver innkapsling bruker byte på hoder, og mengden avhenger av transporten, adressefamilien og om NAT-traversering er i spill. En indre pakke som passer på den lokale lenken kan fortsatt gi en ytre pakke som ikke passer på veien bak den. Mål overheaden i stedet for å anta den, fordi hvert valgfrie hode legges på regningen. En tunnel med NAT-traversering betaler mer enn en bar, og forskjellen er nok til å ødelegge en overføring som virket i går.

Når den ytre pakken bærer ikke-fragmenter-biten, slipper et hopp som ikke kan videresende den den, og bør returnere en ICMP-melding. Hvis den meldingen filtreres et sted, fortsetter avsenderen å prøve, og brukeren ser en stopp uten forklaring. Den stille droppen er den vanlige grunnen til at et størrelsesproblem rapporteres som et hastighetsproblem.

IPv6 fjerner ett av alternativene

IPv6-rutere fragmenterer ikke underveis, så den ytre pakken passer enten eller forsvinner med en Packet Too Big-melding. Den meldingen blir den eneste tilbakemeldingskanalen, og å blokkere den bryter stioppdagelsen for hver stor overføring som følger. IPv4-rutere kan fragmentere en stor pakke når biten er klar, noe som skjuler feilen til noe annet setter den biten.

På en blandet stakk kan den samme tunnelen oppføre seg forskjellig for de to familiene, og derfor avgjør ikke én test over IPv4 en IPv6-klage. En kontroll som øver én familie, lar halvparten av svaret være umålt.

TCP-segmentpolitikk er ikke et generelt svar

Å begrense maksimal segmentstørrelse hjelper TCP-strømmer, og det er en legitim kontroll når problemet er begrenset til dem. Det har ingen virkning på UDP, som bærer DNS, noen taleprotokoller og en voksende del av netttrafikken.

Bruk den, og test deretter arbeidsbelastningen som feilet. Hvis UDP-tilfellet fortsatt feiler, var segmentpolitikken aldri svaret, og grensesnittbudsjettet trenger fortsatt oppmerksomhet. Identifiser først protokollen til arbeidsbelastningen som feiler, og velg deretter kontrollen som hører til den.

Rekkefølgen å arbeide i

Noter den største nyttelasten som overlever, deretter grensesnittets MTU, deretter om den ytre pakken bærer ikke-fragmenter-biten, og til slutt om ICMP-tilbakemeldingen når avsenderen. Den sekvensen snevrer inn feilen uten å gjette. Ta vare på hver observasjon med tidsstempel og endepunkt, fordi alle fire tallene flytter seg når veien endres.

Endre én verdi, test den opprinnelige overføringen på nytt og ta vare på resultatet. En tunnel som består en stor probe men fortsatt stopper i applikasjonen, har flyttet seg til et annet problem, og det er fremgang som er verdt å skrive ned. Den neste personen vil heller ha tallene enn konklusjonen.