VPN-ping fungerer, men nettstaden heng: sjekk storleiken

Ekko-svar kjem inn, eksternt skrivebord fungerer, og nettlesaren blir ståande på ei tom side til han gir opp. To forklaringar passar på det mønsteret, og dei er ikkje variantar av eitt problem: ein politikk som aldri tillét tenesta, eller pakkar som sluttar å passe når overføringa veks. Ekko-svaret utelukkar ingen av dei.

Gå frå det minste spørsmålet til det største, og skriv ned kva kvart steg faktisk prova.

Eit ekko-svar svarer på eit mykje mindre spørsmål

Eit ekko-svar seier at IP-stakken på destinasjonen svara på ein ICMP-førespurnad frå kjelda di. Det seier ingenting om det finst ein TCP-lyttar på porten du treng, om ein politikk tillèt den porten, eller om destinasjonsverten filtrerer trafikk uavhengig av gatewayen. Ein gateway som tillèt éi teneste, kan sleppe ei anna medan begge måla svarar på ping. Les svaret som eitt faktum om éin pakke og éi retning.

Stadfest destinasjonen og tenesteporten før du tolkar noko anna. Adressa du testa, og adressa applikasjonen brukar, er stundom ulike oppføringar, og eit namn som blir løyst til to adresser gjer det sannsynleg.

Finn ut om tilkoplinga starta

Ei tilkopling som blir avvist med ein gong, er eit svar frå lyttaren eller politikken: noko svara og sa nei. Ei tilkopling som opnar og deretter stoggar når data byrjar å røre seg, peikar på storleik. Ei tilkopling som aldri fullfører handtrykket, kjem vanlegvis av politikk eller ruting, og ser ut som eit tidsavbrot snarare enn ei avvising.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Noter kva av dei tre du observerte før du rører MTU-innstillingar. Å endre ein tunnelstorleik for å reparere ei avvist tilkopling kastar bort endringa og skjuler den faktiske årsaka ei stund.

Mål storleik med eit oppgitt tal

Når stansen dukkar opp under last, test éin pakkestorleik med don't-fragment-biten sett og oppgi aritmetikken slik at resultatet betyr noko. På Linux med iputils gir ei nyttelast på 1392 byte pluss ICMP-hovudet på 8 byte og IPv4-hovudet på 20 byte ein indre pakke på nøyaktig 1420 byte. Oppgi den aritmetikken i saka, fordi ein bar ping som når gatewayen ikkje provar noko om ein applikasjon.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Båe probane er målepunkter, ikkje tilrådingar av ein tunnelstorleik. Viss ICMP blir filtrert ein eller annan stad på vegen, fortel eit tidsavbrot ingenting om storleik, fordi filtrering og ein for stor pakke ser like ut frå klienten. Ein suksess seier heller ingenting om motsett retning eller om ein annan destinasjon.

Ta omsyn til den ytre vegen

Innkapsling legg til sine eigne hovud, så pakken på leidningen er større enn pakken du målte inne i tunnelen. Skilnaden mellom dei to er det som gjer ein fungerande liten førespurnad og ein feilande stor mogleg samstundes.

IPv4-oppdaging av vegens MTU er avhengig av tilbakemelding om pakkar som ikkje kan videresendast utan fragmentering, og IPv6 brukar Packet Too Big-meldingar. IPv4-spesifikasjonen skildrar den mekanismen. Å filtrere tilbakemeldinga øydelegg evna til avsendaren til å lære og lèt han sende på nytt pakkar som aldri vil passe. Difor kan ein fungerande liten førespurnad og ein feilande stor leve så komfortabelt side om side.

Endre eitt tal og test applikasjonen på nytt

Senk MTU-en på tunnelen, eller avgrens maksimal segmentstorleik for TCP, og gjer deretter den opphavlege applikasjonstesten om att i staden for proben. Ein probe som lykkast etter endringa, og ein applikasjon som framleis heng, er eit anna problem med ein liknande form, og berre applikasjonstesten skil dei.

Hald aritmetikken i endringsoppføringa: den målte storleiken, overheaden du antok, og verdien du sette. Alle som gjennomgår det seinare, kan kontrollere føresetnaden i staden for å leie han ut på nytt frå eit skjermbilete av ein ping.

Viss applikasjonen fungerer ved kvar storleik du prøvde, slutt å justere tal og sjå på politikken som skil den fungerande tenesta frå den feilande.