Klienten din rapporterer tilkoblet mens grensesnittet er oppe og nettleseren timer ut, og ingen av de tre påstandene er falske. Tilkoblet beskriver et lag som ikke har noe med siden du ba om å gjøre. Å avgjøre hvilket lag som rapporterer krever én ny forespørsel og ett blikk på telleren som ville bevise at trafikken flyttet seg. En omstart kaster det beviset og bygger opp igjen forholdene du prøvde å observere.

Tre forskjellige ting som kalles tilkoblet

Nederst kan tilkoblet bety at en klientprosess kjører og holder en socket mot en peer. Over det kan det bety at det finnes et grensesnitt med en adresse, som en permanent enhet eller en gjenopprettingsrutine kan lage uten en levende sesjon bak. På kontrollnivå kan det bety at en assosiasjon ble forhandlet, noe som ikke sier noe om hvorvidt en enkelt pakke har krysset under den. Hver av dem overlever feil som de andre ikke overlever, og en klient viser vanligvis den sterkeste den kan påberope seg.

Et grønt ikon og en død tunnel er derfor forenlige og ikke motstridende; de rapporterer om forskjellige objekter. Det er hele grunnen til at denne feilen stadig feildiagnostiseres som en klientfeil.

Send én ufarlig forespørsel til en destinasjon du faktisk trenger før du rører daemonen, og hold den påkrevde blokken for direkte trafikk på plass mens du arbeider. En omstart sletter rekkefølgen av hendelser og gjenoppretter dem deretter nær nok til å skjule årsaken, og derfor kommer samme sak tilbake en uke senere uten noe nytt i seg. Én forespørsel, én telleravlesning og utløseren som fremkalte feilen er minimumsbeviset.

Hvilken teller beviser at pakkene flyttet seg

I IPsec er IKE-assosiasjonen og CHILD-assosiasjonen separate objekter, og bare child bærer tellerne som svarer på dette spørsmålet. List child, se om pakkene øker i begge retninger, og sammenlign det med det applikasjonen prøver å gjøre. En installert assosiasjon på null er et annet funn enn en som øker mens applikasjonen fortsatt feiler; det første betyr at trafikken ikke velges, det andre at den beveger seg og at feilen er lenger frem. Les tellerne to ganger, noen sekunder fra hverandre, fordi én prøve ikke kan vise en trend.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Nulltellere peker på valget: ruting, policy, et navnerom pakken forlot, eller et grensesnitt klienten aldri bandt seg til. Økende tellere peker bort fra tunnelen, så fortsett med videresending i den fjerne enden, navneoppslag, returveien og destinasjonstjenesten, i den rekkefølgen. En protokoll uten et eget child-objekt legger frem det samme beviset på sine egne premisser, så bruk det den rapporterer om peer-tilstand og pakketall i stedet for å låne IPsec-ordforrådet. Formen på avlesningen betyr mer enn verktøyet som lagde den.

Hvor feilen sitter etter at tellerne flytter seg

En gateway som svarer på sin egen administrasjonsadresse beviser at gatewayen kjører, ikke at noe bak den betjener forespørselen din, så test den fjerne siden og ikke boksen i midten. Navneoppslag skjuler feil best, fordi en resolver som ikke kan nås gjennom tunnelen, timer ut akkurat som en død forbindelse. To oppslag skiller de tilfellene, og begge er billige. Spør først resolveren tunnelen presser på, og spør deretter en offentlig resolver om samme navn.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Et navn som løses gjennom den offentlige resolveren men ikke gjennom tunnelens resolver, betyr at DNS-veien er brutt, mens et navn som løses gjennom begge og fortsatt timer ut i nettleseren, peker på returveien eller på tjenesten. Hvis ping på adresse lykkes og applikasjonen fortsatt nekter, leverte nettet forespørselen og tjenesten avviste den, noe som er et helt senere stadium.

Noter utløseren, og endre så én ting

Noter hva som gikk foran feilen: en periode med inaktivitet, en nettverksendring, en nøkkelfornyelse, en gjenopptatt bærbar eller et gjenopprettet system. De gir forskjellige mekanismer, og bare det gjenopprettede systemet reparerer vanligvis seg selv, noe som nettopp er tilfellet som ikke lærer deg noe. En omstart fjerner rekkefølgen av hendelser og gjenoppretter deretter forhold som er nær nok til å skjule årsaken. Skriv ned utløseren mens den fortsatt kan gjenskapes.

Gjør så én understøttet rettelse og gjenta den opprinnelige forespørselen sammen med utløseren som fremkalte feilen. Inaktivitet er den enkleste utløseren å gjenskape, så det er den raskeste bekreftelsen på at rettelsen tok mekanismen og ikke symptomet.

Det du vil rapportere, er bevis for at trafikken du mente å sende, nådde tjenesten du mente å nå. Et ikon som blir grønt, en bufret side som lastes og en teller som beveger seg beviser alle mindre enn én fullført forespørsel mot den tiltenkte destinasjonen. Hold forespørselen, telleravlesningen og utløseren sammen, så neste person kan skille en rettelse fra en tilfeldighet.

Relaterte artikler