Undersøk et Linux-VPN-grensesnitt med ip link, lag for lag

Klientikonet sier tilkoblet, grensesnittet finnes, og applikasjonen når fortsatt ingenting. Den kombinasjonen er vanlig, fordi et virtuelt grensesnitt kan bli stående mens den eksterne parten, adressene eller rutene mangler. ip link er det riktige første verktøyet, og det er også det letteste å 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 nettopp er den påstanden det ikke kan underbygge alene.

Les grensesnittet før du leser ikonet

Start med ip -details link show dev tun0 som dokumentert i ip-link-håndboken, og bytt til grensesnittet klienten din faktisk eier i stedet for det konvensjonelle navnet. Flagg, type, MTU og grensesnittidentitet er nyttige observasjoner. Et virtuelt grensesnitts tilstandsordlyd 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 vedvaring kan holde lenken oppe nettopp for at gjenoppkoblingen ikke skal bygge den på nytt, 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 de tellerne, og det er poenget med øvelsen.

Hvis sendetelleren beveger seg og mottakstellere ikke, forlot pakken og ingenting kom tilbake. Det er et annet problem enn et grensesnitt som aldri bar noe i det hele tatt. Hvis begge tellerne beveger seg og applikasjonen fortsatt feiler, ligger feilen over grensesnittet, 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, resolver-konfigurasjonen eller ruten applikasjonen trenger. Sjekk adressen med ip address show dev tun0, og sjekk deretter hvilken rute destinasjonen ville velge med ip route get for det faktiske målet. Disse 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 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 levende 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 nettverksnavnerom 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 bør etterlate deg med

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 applikasjonen faktisk trenger. Når de er skrevet ned, er neste steg åpenbart og hører til et bestemt lag. Uten dem er hver påfølgende endring et gjetning med en tilbakekjøringsplan.

Sammenlign disse fire fakta med de samme fire fra en økt som virker. 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 fin 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 deretter sløyfen ved å teste applikasjonen igjen, fordi grensesnittet aldri var det brukeren brydde seg om.