Granska ett Linux-VPN-gränssnitt med ip link, lager för lager

Klientikonen säger ansluten, gränssnittet finns och programmet når ändå ingenting. Den kombinationen är vanlig, eftersom ett virtuellt gränssnitt kan finnas kvar medan dess fjärrpartner, adresser eller rutter saknas. ip link är rätt första verktyg, och det är också det lättaste att läsa för optimistiskt. Flaggor och räknare beskriver ett lager, och lagren ovanför dem fallerar oberoende av varandra. Det är också verktyget folk citerar när de vill bevisa att tunneln är uppe, vilket är precis det påstående det inte klarar på egen hand.

Läs gränssnittet innan du läser ikonen

Börja med ip -details link show dev tun0 enligt dokumentationen i handboken för ip-link, och ersätt det konventionella namnet med det gränssnitt din klient faktiskt äger. Flaggor, typ, MTU och gränssnittets identitet är användbara observationer. Formuleringen av ett virtuellt gränssnitts tillstånd behöver inte bete sig som en fysisk kabels bärarindikering, så behandla UP som ett påstående om gränssnittet och inte om tunneln.

Den skillnaden förklarar det mest förvirrande fallet: ett gränssnitt som består medan fjärrsidan återansluter eller är oåtkomlig.

Inställningar för beständighet kan hålla länken kvar just för att återanslutningen inte ska bygga om den, vilket betyder att närvaro inte är hälsa.

Lägg till räknare och en begäran som borde använda dem

Använd den statistikvy som stöds, ip -s link show dev tun0, och notera antalet paket och byte i båda riktningarna. Generera sedan en ofarlig begäran som borde passera gränssnittet och jämför den relevanta riktningen. En begäran som tog ett annat programs direkta rutt flyttar inte de räknarna, och det är själva poängen med övningen.

Om sändräknaren rör sig och mottagningsräknaren inte gör det, lämnade paketet och ingenting kom tillbaka. Det är ett annat problem än ett gränssnitt som aldrig har burit någonting alls. Om båda räknarna rör sig och programmet ändå misslyckas ligger felet ovanför gränssnittet, vilket är framsteg och inte en återvändsgränd.

Läs av två gånger, en före och en efter, i stället för att lita på en enda ögonblicksbild.

Adresser och rutter är separata steg

En länk kan finnas utan prefixet, resolverkonfigurationen eller den rutt programmet behöver. Kontrollera adressen med ip address show dev tun0, kontrollera sedan vilken rutt destinationen skulle välja med ip route get för det faktiska målet. De tre observationerna besvarar tre olika frågor, och bara den sista handlar om vidarebefordran.

För IPsec kan även säkerhetspolicy och associationsstatus spela roll, och inte varje IPsec-design visas som ett enkelt tun-gränssnitt. Att leta efter en tun-enhet som aldrig skulle finnas är ett snabbt sätt att dra fel slutsats.

Anteckna det exakta namnet, namnrymden och tiden tillsammans med varje utdata du behåller, eftersom ett likadant namn i en annan container eller en återställd session representerar en helt annan kontext.

Radera inte det du inte har identifierat

Ett okänt gränssnitt är inte automatiskt föråldrat. Identifiera dess ägare innan du tar bort något, och använd klientens dokumenterade nedmontering eller den hanterade konfigurationen när borttagning verkligen är avsedd. Att radera en levande tunnel för att se vad som händer är ett test som besvarar en fråga ingen ställde.

Om gränssnittet tillhör en containerruntime eller en nätverksnamnrymd som du inte skapade, är ägaren ett kommando bort och värd att hitta först.

Den försiktigheten gäller även ip link set down, som ser återställbar ut och ofta inte är det.

Vad granskningen bör lämna dig med

En bra granskning slutar med fyra fakta: gränssnittets namn och namnrymd, dess flaggor och MTU, räknardifferensen från en verklig begäran, samt den rutt och adress programmet faktiskt behöver. När de är nedskrivna är nästa steg självklart och hör till ett specifikt lager. Utan dem är varje efterföljande ändring en gissning med en återställningsplan.

Jämför de fyra fakta med samma fyra från en fungerande session. Om gränssnittets namn och namnrymd stämmer men räknardifferensen är noll nådde begäran aldrig tunneln. Om räknardifferensen är frisk och rutten pekar någon annanstans är tunneln okej och routningen inte det. Den jämförelsen är det som förvandlar en hög utdata till ett beslut.

Behåll utdata tillsammans med ärendet, eftersom en senare jämförelse bara är användbar om du ser vad som ändrades.

Slut sedan kretsen genom att testa programmet igen, eftersom gränssnittet aldrig var det användaren brydde sig om.