Stora paket försvinner över IPsec medan små ping fortfarande fungerar

Fjärrskal förblir svarsbenägna, små prober svarar, och sedan kryper en filkopia och stannar utan något fel som någon kan peka på. Ping med större nyttolast återskapar det direkt, och samma överföring fungerar från det lokala nätet. Inget i krypteringen är långsamt; vissa paket kommer aldrig fram. Två olika delningar kan ge den signaturen, och de lämnar olika spår.

Två ställen där ett paket kan delas

Före krypteringen kan routern dela ett för stort inre paket och skydda varje bit för sig. Efter krypteringen är det det färdiga yttre paketet som delas, och den bortre änden måste sätta ihop det igen innan den kan dekryptera något. Samma symptom, annat arbete för mottagaren och andra rattar för dig.

Skillnaden spelar roll eftersom en rättelse riktad mot fel sida ändrar en siffra utan att flytta felet. Ett paket som avvisas i gränssnittet blir aldrig ett yttre paket, så ingen inställning på yttersidan kan rädda det.

Var storleksbeslutet egentligen fattas

Ett tunnelgränssnitt bär en IP MTU, och det värdet kan avvisa ett för stort inre paket långt innan IPsec-steget ser det. Att sätta en bit i det yttre huvudet omprövar inte det tidigare beslutet, eftersom paketet redan har avvisats. Därför gör en högre inre MTU ibland saken värre i stället för bättre. Läs gränssnittsvärdet och det yttre beteendet innan du ändrar något av dem, eftersom den billigare ändringen oftast är den som förklarar symptomet.

Kontrollera gränssnittsvärdet först, sedan det yttre beteendet. Två siffror, två steg, och vanligtvis är bara en av dem ansvarig.

Den yttre budgeten är inte den inre budgeten

Varje inkapsling gör av med byte på huvuden, och mängden beror på transporten, adressfamiljen och om NAT-traversering är inblandad. Ett inre paket som får plats på den lokala länken kan ändå ge ett yttre paket som inte får plats på vägen bortom den. Mät överheaden i stället för att anta den, eftersom varje valfritt huvud läggs på räkningen. En tunnel med NAT-traversering betalar mer än en bar, och skillnaden räcker för att bryta en överföring som fungerade i går.

När det yttre paketet bär do-not-fragment-biten släpper ett hopp som inte kan vidarebefordra det det, och bör returnera ett ICMP-meddelande. Om det meddelandet filtreras någonstans fortsätter avsändaren att försöka, och användaren ser en stillastående överföring utan förklaring. Det tysta tappet är den vanliga orsaken till att ett storleksproblem rapporteras som ett hastighetsproblem.

IPv6 tar bort ett av alternativen

IPv6-routrar fragmenterar inte under vägen, så det yttre paketet passar antingen eller försvinner med ett Packet Too Big-meddelande. Det meddelandet blir den enda återkopplingskanalen, och att blockera det bryter vägupptäckten för varje stor överföring som följer. IPv4-routrar kan fragmentera ett stort paket när biten är tydlig, vilket döljer felet tills något annat sätter den biten.

På en blandad stack kan samma tunnel bete sig olika för de två familjerna, och därför avgör inte ett test över IPv4 ett klagomål om IPv6. En kontroll som övar en familj lämnar halva svaret omätt.

TCP-segmentpolicy är inte ett generellt svar

Att begränsa den maximala segmentstorleken hjälper TCP-flöden, och det är en legitim kontroll när problemet är begränsat till dem. Det har ingen effekt på UDP, som bär DNS, vissa röstprotokoll och en växande del av webbtrafiken.

Tillämpa den och testa sedan arbetsbelastningen som misslyckades. Om UDP-fallet fortfarande misslyckas var segmentpolicyn aldrig svaret, och gränssnittsbudgeten behöver fortfarande uppmärksamhet. Identifiera först protokollet för den misslyckade arbetsbelastningen och välj sedan den kontroll som hör till det.

Ordningen att arbeta i

Notera den största nyttolast som överlever, sedan gränssnittets MTU, sedan om det yttre paketet bär do-not-fragment-biten, och till sist om ICMP-återkopplingen når avsändaren. Den sekvensen snävar in felet utan att gissa. Spara varje observation med tidsstämpel och ändpunkt, eftersom alla fyra siffrorna flyttar sig när vägen ändras.

Ändra ett värde, testa den ursprungliga överföringen igen och spara resultatet. En tunnel som klarar en stor prob men fortfarande stannar i applikationen har flyttat till ett annat problem, och det är framsteg som är värt att skriva ner. Nästa person vill hellre ha siffrorna än slutsatsen.