VPN-ping fungerer, men nettstedet henger: sjekk størrelsen

Ekko-svar kommer inn, eksternt skrivebord fungerer, og nettleseren blir stående på en tom side til den gir opp. To forklaringer passer på det mønsteret, og de er ikke varianter av ett problem: en policy som aldri tillot tjenesten, eller pakker som slutter å passe når overføringen vokser. Ekko-svaret utelukker ingen av dem.

Gå fra det minste spørsmålet til det største, og skriv ned hva hvert trinn faktisk beviste.

Et ekko-svar besvarer et mye mindre spørsmål

Et ekko-svar sier at IP-stakken på destinasjonen besvarte en ICMP-forespørsel fra kilden din. Det sier ingenting om hvorvidt det finnes en TCP-lytter på porten du trenger, om en policy tillater den porten, eller om destinasjonsverten filtrerer trafikk uavhengig av gatewayen. En gateway som tillater én tjeneste, kan droppe en annen mens begge målene svarer på ping. Les svaret som ett faktum om én pakke og én retning.

Bekreft destinasjonen og tjenesteporten før du tolker noe annet. Adressen du testet, og adressen applikasjonen bruker, er noen ganger forskjellige oppføringer, og et navn som løses til to adresser gjør det sannsynlig.

Finn ut om tilkoblingen startet

En tilkobling som avvises umiddelbart, er et svar fra lytteren eller policyen: noe svarte og sa nei. En tilkobling som åpnes og deretter stopper når data begynner å bevege seg, peker på størrelse. En tilkobling som aldri fullfører håndtrykket, skyldes vanligvis policy eller ruting, og ser ut som en tidsavbrudd snarere enn en avvisning.

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

Noter hvilken av de tre du observerte før du rører MTU-innstillinger. Å endre en tunnelstørrelse for å reparere en avvist tilkobling kaster bort endringen og skjuler den faktiske årsaken en stund.

Mål størrelse med et oppgitt tall

Når stansen dukker opp under last, test én pakkestørrelse med don't-fragment-biten satt og oppgi aritmetikken slik at resultatet betyr noe. På Linux med iputils gir en nyttelast på 1392 byte pluss ICMP-hodet på 8 byte og IPv4-hodet på 20 byte en indre pakke på nøyaktig 1420 byte. Oppgi den aritmetikken i saken, fordi en bar ping som når gatewayen ikke beviser noe om en applikasjon.

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

Begge probene er målepunkter, ikke anbefalinger av en tunnelstørrelse. Hvis ICMP filtreres et eller annet sted på veien, forteller en tidsavbrudd ingenting om størrelse, fordi filtrering og en for stor pakke ser like ut fra klienten. En suksess sier heller ingenting om motsatt retning eller om en annen destinasjon.

Ta hensyn til den ytre veien

Innkapsling legger til sine egne hoder, så pakken på ledningen er større enn pakken du målte inne i tunnelen. Forskjellen mellom de to er det som gjør en fungerende liten forespørsel og en feilende stor mulig samtidig.

IPv4-oppdagelse av veilens MTU avhenger av tilbakemelding om pakker som ikke kan videresendes uten fragmentering, og IPv6 bruker Packet Too Big-meldinger. IPv4-spesifikasjonen beskriver den mekanismen. Å filtrere tilbakemeldingen ødelegger avsenderens evne til å lære og lar den sende på nytt pakker som aldri vil passe. Derfor kan en fungerende liten forespørsel og en feilende stor leve så komfortabelt side om side.

Endre ett tall og test applikasjonen på nytt

Senk MTU-en på tunnelen, eller begrens maksimal segmentstørrelse for TCP, og gjenta deretter den opprinnelige applikasjonstesten i stedet for proben. En probe som lykkes etter endringen, og en applikasjon som fortsatt henger, er et annet problem med en lignende form, og bare applikasjonstesten skiller dem.

Behold aritmetikken i endringsoppføringen: den målte størrelsen, overheaden du antok, og verdien du satte. Alle som gjennomgår det senere, kan kontrollere antakelsen i stedet for å utlede den på nytt fra et skjermbilde av en ping.

Hvis applikasjonen fungerer ved hver størrelse du prøvde, slutt å justere tall og se på policyen som skiller den fungerende tjenesten fra den feilende.