Inspicér et Linux VPN-interface med ip link, lag for lag

Klientens ikon siger forbundet, interfacet findes, og applikationen når stadig ikke noget. Den kombination er almindelig, fordi et virtuelt interface kan blive ved med at være til stede, mens dets fjerne modpart, dets adresser eller dets ruter mangler. ip link er det rigtige første værktøj og samtidig det letteste at overfortolke. Flag og tællere beskriver ét lag, og lagene over dem fejler uafhængigt. Det er også det værktøj, folk citerer, når de vil bevise, at tunnelen er oppe, netop den påstand, det ikke kan understøtte alene.

Læs interfacet, før du læser ikonet

Start med ip -details link show dev tun0 som dokumenteret i ip-link-manualen, og indsæt det interface, din klient faktisk ejer, i stedet for det konventionelle navn. Flag, type, MTU og interfacets identitet er nyttige observationer. Formuleringen af et virtuelt interfaces tilstand behøver ikke opføre sig som et fysisk kabels bærerindikation, så behandl UP som en udtalelse om interfacet og ikke om tunnelen.

Den forskel forklarer det mest forvirrende tilfælde: et interface, der består, mens den fjerne side genopretter forbindelsen eller er utilgængelig.

Indstillinger for vedholdenhed kan holde linket netop for at genopkoblingen ikke skal genopbygge det, hvilket betyder, at tilstedeværelse ikke er sundhed.

Tilføj tællere og en anmodning, der burde bruge dem

Brug den understøttede statistikvisning ip -s link show dev tun0, og noter pakke- og byttetællingerne i begge retninger. Generér derefter en harmløs anmodning, der burde passere interfacet, og sammenlign den relevante retning. En anmodning, der tog en anden applikations direkte rute, flytter ikke de tællere, og det er pointen med øvelsen.

Hvis sendetælleren flytter sig, og modtagetælleren ikke gør, forlod pakken, og intet kom tilbage. Det er et andet problem end et interface, der aldrig har båret noget. Hvis begge tællere flytter sig, og applikationen stadig fejler, sidder fejlen over interfacet, hvilket er fremskridt og ikke en blindgyde.

Tag aflæsningen to gange, en gang før og en gang efter, i stedet for at stole på et enkelt øjebliksbillede.

Adresser og ruter er separate trin

Et link kan findes uden det præfiks, den resolverkonfiguration eller den rute, applikationen har brug for. Kontrollér adressen med ip address show dev tun0, kontrollér derefter hvilken rute destinationen ville vælge med ip route get for det faktiske mål. De tre observationer besvarer tre forskellige spørgsmål, og kun den sidste handler om videresendelse.

For IPsec kan sikkerhedspolitik og associationsstatus også have betydning, og ikke ethvert IPsec-design viser sig som et simpelt tun-interface. At lede efter en tun-enhed, der aldrig ville have eksisteret, er en hurtig vej til den forkerte konklusion.

Noter det præcise navn, navneområdet og tidspunktet sammen med enhver output, du gemmer, fordi et enslydende navn i en anden container eller en gendannet session repræsenterer en helt anden kontekst.

Slet ikke det, du ikke har identificeret

Et ukendt interface er ikke automatisk forældet. Fastslå ejeren, før du fjerner noget, og brug klientens dokumenterede nedrivning eller den administrerede konfiguration, når fjernelsen virkelig er hensigten. At slette en levende tunnel for at se, hvad der sker, er en test, der besvarer et spørgsmål, ingen stillede.

Hvis interfacet tilhører et container-miljø eller et netværksnavneområde, du ikke har oprettet, er ejeren én kommando væk og værd at finde først.

Den forsigtighed gælder også for ip link set down, som ser reversibelt ud og ofte ikke er det.

Hvad inspektionen bør efterlade dig med

En god inspektion ender med fire fakta: interfacets navn og navneområde, dets flag og MTU, tællerdeltaet fra en rigtig anmodning samt den rute og adresse, applikationen faktisk har brug for. Når de er skrevet ned, er næste skridt indlysende og hører til et bestemt lag. Uden dem er enhver efterfølgende ændring et gæt med en tilbagerulningsplan.

Sammenlign de fire fakta med de samme fire fra en fungerende session. Hvis navn og navneområde stemmer, men tællerdeltaet er nul, nåede anmodningen aldrig tunnelen. Hvis deltaet er sundt, og ruten peger et andet sted hen, er tunnelen fin, og routing er det ikke. Den sammenligning er det, der gør en bunke output til en beslutning.

Gem outputtet sammen med billetten, for en senere sammenligning er kun nyttig, hvis du kan se, hvad der ændrede sig.

Luk derefter løkken ved at teste applikationen igen, fordi interfacet aldrig var det, brugeren bekymrede sig om.