Store pakker forsvinder over IPsec, mens små ping stadig virker

Fjernskaller forbliver lydhøre, små prober svarer, og så kravler en filkopiering og går i stå uden nogen fejl, som nogen kan pege på. Ping med en større nyttelast gengiver det øjeblikkeligt, og den samme overførsel virker fra det lokale netværk. Intet ved krypteringen er langsomt; visse pakker ankommer aldrig. To forskellige opdelinger kan frembringe den signatur, og de efterlader forskellige spor.

To steder hvor en pakke kan deles

Før kryptering kan routeren dele en for stor indre pakke og beskytte hver del for sig. Efter kryptering er det den færdige ydre pakke, der deles, og den fjerne ende skal samle den igen, før den kan dekryptere noget som helst. Samme symptom, forskelligt arbejde for modtageren og forskellige knapper for dig.

Forskellen er vigtig, fordi en rettelse rettet mod den forkerte side ændrer et tal uden at flytte fejlen. En pakke, der afvises i interfacet, bliver aldrig en ydre pakke, så ingen indstilling på ydersiden kan redde den.

Hvor størrelsesbeslutningen egentlig træffes

Et tunnelinterface bærer en IP MTU, og den værdi kan afvise en for stor indre pakke længe før IPsec-trinnet ser den. At sætte en bit i det ydre headere genoptager ikke den tidligere beslutning, fordi pakken allerede er afvist. Derfor gør en højere indre MTU nogle gange tingene værre i stedet for bedre. Læs interfaceværdien og den ydre adfærd, før du ændrer nogen af dem, fordi den billigere ændring normalt er den, der forklarer symptomet.

Kontroller først interfaceværdien, derefter den ydre adfærd. To tal, to trin, og normalt er kun ét af dem ansvarligt.

Det ydre budget er ikke det indre budget

Hver indkapsling bruger bytes på headere, og mængden afhænger af transporten, adressefamilien og af, om NAT traversal er i spil. En indre pakke, der passer til det lokale link, kan stadig give en ydre pakke, der ikke passer til stien bag det. Mål overheadet i stedet for at antage det, fordi hver valgfri header lægges på regningen. En tunnel med NAT traversal betaler mere end en bar, og forskellen er nok til at ødelægge en overførsel, der virkede i går.

Når den ydre pakke bærer do-not-fragment-bitten, dropper et hop, der ikke kan videresende den, den og bør returnere en ICMP-meddelelse. Hvis den meddelelse filtreres et sted, bliver afsenderen ved med at prøve, og brugeren ser en stilstand uden forklaring. Det tavse drop er den sædvanlige grund til, at et størrelsesproblem rapporteres som et hastighedsproblem.

IPv6 fjerner en af mulighederne

IPv6-routere fragmenterer ikke undervejs, så den ydre pakke passer enten eller forsvinder med en Packet Too Big-meddelelse. Den meddelelse bliver den eneste feedbackkanal, og blokering af den ødelægger stifinding for enhver stor overførsel, der følger. IPv4-routere kan fragmentere en stor pakke, når bitten er klar, hvilket skjuler fejlen, indtil noget andet sætter den bit.

På en blandet stak kan den samme tunnel opføre sig forskelligt for de to familier, og derfor afgør én test over IPv4 ikke en IPv6-klage. En kontrol, der øver én familie, lader halvdelen af svaret være umålt.

TCP-segmentpolitik er ikke et generelt svar

At begrænse den maksimale segmentstørrelse hjælper TCP-strømme, og det er en legitim kontrol, når problemet er begrænset til dem. Det har ingen virkning på UDP, som bærer DNS, nogle taleprotokoller og en voksende del af webtrafikken.

Anvend den, og test derefter den arbejdsbyrde, der fejlede. Hvis UDP-tilfældet stadig fejler, var segmentpolitikken aldrig svaret, og interfacebudgettet trænger stadig til opmærksomhed. Identificer først protokollen for den fejlende arbejdsbyrde, og vælg derefter den kontrol, der hører til den.

Den rækkefølge, du skal arbejde i

Noter den største nyttelast, der overlever, derefter interface-MTU'en, derefter om den ydre pakke bærer do-not-fragment-bitten, og til sidst om ICMP-feedback når afsenderen. Den sekvens indsnævrer fejlen uden at gætte. Gem hver observation med et tidsstempel og et endepunkt, fordi alle fire tal flytter sig, når stien ændrer sig.

Ændr én værdi, test den oprindelige overførsel igen, og gem resultatet. En tunnel, der består en stor probe, men stadig går i stå på applikationen, er flyttet til et andet problem, og det er fremskridt, der er værd at skrive ned. Den næste person vil hellere have tallene end konklusionen.