Undersøk et Linux-VPN-grensesnitt med ip link, lag for lag
Flagg og tellere beskriver bare ett lag. Les lenken, deretter tellerne, så adresser og ruter, før du konkluderer med at tunnelen er ødelagt.
Klientikonet sier tilkoblet, grensesnittet finnes, og programmet når fortsatt ingenting. Den kombinasjonen er vanlig, fordi et virtuelt grensesnitt kan bestå mens den eksterne parten, adressene eller rutene mangler. ip link er riktig første verktøy, og også det enkleste å overtolke. Flagg og tellere beskriver ett lag, og lagene over dem feiler uavhengig. Det er også verktøyet folk siterer når de vil bevise at tunnelen er oppe, som er nettopp den påstanden det ikke kan støtte alene.
Les grensesnittet før du leser ikonet
Start med ip -details link show dev tun0 som dokumentert i ip-link-manualen, og bytt ut grensesnittet klienten din faktisk eier i stedet for det konvensjonelle navnet. Flagg, type, MTU og grensesnittidentitet er nyttige observasjoner. Tilstandsteksten til et virtuelt grensesnitt trenger ikke oppføre seg som en fysisk kabels bærerindikasjon, så behandle UP som en uttalelse om grensesnittet og ikke om tunnelen.
Den forskjellen forklarer det mest forvirrende tilfellet: et grensesnitt som består mens den eksterne siden kobler til på nytt eller er utilgjengelig.
Innstillinger for vedvarende tilkobling kan holde lenken oppe nettopp for at gjenoppkoblingen ikke skal bygge den på nytt, noe som betyr at tilstedeværelse ikke er det samme som helse.
Legg til tellere og en forespørsel som skal bruke dem
Bruk den støttede statistikkvisningen, ip -s link show dev tun0, og noter pakke- og byttetellingene i begge retninger. Generer deretter en ufarlig forespørsel som skal gå gjennom grensesnittet, og sammenlign den relevante retningen. En forespørsel som tok en annen applikasjons direkte rute vil ikke flytte tellerne, og det er poenget.
Hvis sendetelleren beveger seg og mottakstelleren ikke, forlot pakken og ingenting kom tilbake. Det er et annet problem enn et grensesnitt som aldri har fraktet noe i det hele tatt. Hvis begge tellerne beveger seg og programmet fortsatt feiler, ligger feilen over grensesnittet, noe som er fremgang og ikke en blindvei.
Ta avlesningen to ganger, én før og én etter, i stedet for å stole på et enkelt øyeblikksbilde.
Adresser og ruter er separate trinn
En lenke kan finnes uten prefikset, resolverkonfigurasjonen eller ruten programmet trenger. Sjekk adressen med ip address show dev tun0, og sjekk deretter hvilken rute målet ville velge med ip route get for det faktiske målet. De tre observasjonene svarer på tre forskjellige spørsmål, og bare det siste handler om videresending.
For IPsec kan sikkerhetspolicy og assosiasjonstilstand også ha betydning, og ikke alle IPsec-design vises som et enkelt tun-grensesnitt. Å lete etter en tun-enhet som aldri kom til å finnes er en rask måte å konkludere feil.
Noter det nøyaktige navnet, navnerommet og tidspunktet sammen med alle utdata du beholder, fordi det samme utseende navnet i en annen container eller en gjenopprettet økt representerer en helt annen kontekst.
Ikke slett det du ikke har identifisert
Et ukjent grensesnitt er ikke automatisk utdatert. Identifiser eieren før du fjerner noe, og bruk klientens dokumenterte nedriving eller den administrerte konfigurasjonen når fjerning virkelig er ment. Å slette en aktiv tunnel for å se hva som skjer er en test som svarer på et spørsmål ingen stilte.
Hvis grensesnittet tilhører en container-runtime eller et navnerom du ikke opprettet, er eieren én kommando unna og verdt å finne først.
Den forsiktigheten gjelder også ip link set down, som ser reversibelt ut og ofte ikke er det.
Hva undersøkelsen skal gi deg
En god undersøkelse ender med fire fakta: grensesnittnavnet og navnerommet, flaggene og MTU-en, tellerdeltaet fra en ekte forespørsel, og ruten og adressen programmet faktisk trenger. Med dem skrevet ned er neste steg åpenbart og hører til et bestemt lag. Uten dem er hver påfølgende endring et gjett med en tilbakerullingsplan.
Sammenlign de fire faktaene med de samme fire fra en fungerende økt. Hvis grensesnittnavnet og navnerommet stemmer men tellerdeltaet er null, nådde forespørselen aldri tunnelen. Hvis tellerdeltaet er friskt og ruten peker et annet sted, er tunnelen i orden og rutingen ikke. Den sammenligningen er det som gjør en haug med utdata om til en beslutning.
Ta vare på utdataene sammen med saken, siden en senere sammenligning bare er nyttig hvis du kan se hva som endret seg.
Lukk så sløyfen ved å teste programmet igjen, fordi grensesnittet aldri var det brukeren brydde seg om.