Ekkosvar ankommer, fjernskrivebordet virker, og browseren bliver på en tom side, indtil den giver op. To forklaringer passer på det mønster, og de er ikke varianter af samme problem: en politik, der aldrig tillod tjenesten, eller pakker, der holder op med at passe, når overførslen vokser. Ekkosvaret udelukker ingen af dem.

Gå fra det mindste spørgsmål til det største, og skriv ned, hvad hvert trin faktisk beviste.

Et ekkosvar besvarer et meget mindre spørgsmål

Et ekkosvar siger, at destinationens IP-stak besvarede en ICMP-anmodning fra din kilde. Det siger intet om, hvorvidt der findes en TCP-lytter på den port, du har brug for, om en politik tillader den port, eller om destinationsværten filtrerer trafik uafhængigt af gatewayen. En gateway, der tillader én tjeneste, kan droppe en anden, mens begge mål svarer på ping. Læs svaret som én kendsgerning om én pakke og én retning.

Bekræft destinationen og tjenesteporten, før du fortolker noget andet. Den adresse, du testede, og den adresse, applikationen bruger, er nogle gange forskellige poster, og et navn, der opløses til to adresser, gør det sandsynligt.

Find ud af, om forbindelsen startede

En forbindelse, der afvises med det samme, er et svar fra lytteren eller politikken: noget svarede og sagde nej. En forbindelse, der åbner og derefter går i stå, når data begynder at flytte sig, peger på størrelse. En forbindelse, der slet ikke fuldfører håndtrykket, skyldes normalt politik eller routing og ligner en timeout snarere end en afvisning.

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

Noter, hvilken af de tre du observerede, før du rører MTU-indstillinger. At ændre en tunnelstørrelse for at rette en afvist forbindelse spilder ændringen og skjuler den faktiske årsag et stykke tid.

Mål størrelse med et oplyst tal

Når stilstanden viser sig under belastning, test én pakkestørrelse med don't-fragment-bitten sat og angiv aritmetikken, så resultatet betyder noget. På Linux med iputils giver en nyttelast på 1392 byte plus ICMP-headeren på 8 byte og IPv4-headeren på 20 byte en indre pakke på præcis 1420 byte. Angiv den aritmetik i sagen, fordi en bar ping, der når gatewayen, ikke beviser noget om en applikation.

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

Begge prober er målepunkter, ikke anbefalinger af en tunnelstørrelse. Hvis ICMP filtreres et eller andet sted på vejen, fortæller en timeout intet om størrelse, fordi filtrering og en for stor pakke ser ens ud fra klienten. En succes siger heller intet om den modsatte retning eller om en anden destination.

Tag højde for den ydre vej

Indkapsling tilføjer sine egne headere, så pakken på ledningen er større end den pakke, du målte inde i tunnelen. Forskellen mellem de to er det, der gør en fungerende lille anmodning og en fejlende stor mulig på samme tid.

IPv4-opdagelse af stiens MTU afhænger af feedback om pakker, der ikke kan videresendes uden fragmentering, og IPv6 bruger Packet Too Big-beskeder. IPv4-specifikationen beskriver den mekanisme. Filtrering af feedbacken ødelægger afsenderens evne til at lære og efterlader den med at gensende pakker, der aldrig vil passe. Derfor kan en fungerende lille anmodning og en fejlende stor sameksistere så bekvemt.

Ændr ét tal og test applikationen igen

Sænk tunnelens MTU, eller begræns den maksimale segmentstørrelse for TCP, og gentag derefter den oprindelige applikationstest i stedet for proben. En probe, der lykkes efter ændringen, og en applikation, der stadig hænger, er et andet problem med en lignende form, og kun applikationstesten kan skelne dem.

Behold aritmetikken i ændringsposten: den målte størrelse, det overhead, du antog, og den værdi, du satte. Enhver, der gennemgår det senere, kan kontrollere antagelsen i stedet for at udlede den igen fra et skærmbillede af en ping.

Hvis applikationen virker ved hver størrelse, du prøvede, skal du stoppe med at justere tal og se på den politik, der adskiller den fungerende tjeneste fra den fejlende.

Relaterede artikler