Övergivet TUN-gränssnitt: hitta ägaren innan du tar bort det

Ditt TUN-gränssnitt finns fortfarande i listan, tunneln skickar ingen trafik, och den uppenbara lösningen ser ut att vara att radera länken. Det är här små städningar blir avbrott. Gränssnittet kan vara beständigt enligt design, ägas av en tjänst som återskapar det, eller gömma sig i ett namnutrymme där samma namn betyder något annat. Att det finns är inget bevis för att det är övergivet.

Att radera ett namngivet gränssnitt är enkelt. Att veta vad som beror på det är den egentliga uppgiften.

Myten: gränssnittet är kvar eftersom tunneln är nere

En beständig TUN-enhet finns oberoende av en ansluten session. Det är poängen med den beständiga flaggan: enheten blir kvar så att nästa anslutning kan återanvända den. Ingen trafik flödar, och inget är fel.

Gränssnittet kan också tillhöra en tjänst som är mellan omstarter, eller en klient vars profil är inaktiv. Kontrollera ägarprocessen och konfigurationen innan du drar slutsatsen att det är övergivet. En processlista och konfigurationen som startar det är starkare bevis än en saknad tunnel.

Anteckna namnutrymmet tillsammans med namnet. Ett annat namnutrymme kan ha ett gränssnitt med samma namn, och de två är orelaterade. Använd namnutrymmesflaggan när du behöver inspektera ett annat.

Myten: att radera länken städar allt

Att radera länken tar bort adresserna och rutterna som hör till den. Det tar inte bort policyregler, brandväggsregler, resolverinställningar eller hjälpskript som refererade till den. De kan överleva och peka på en enhet som inte längre finns.

Om tjänsten fortfarande är konfigurerad kan den återskapa gränssnittet vid nästa start eller återanslutning. Då har du raderat en fungerande resurs och lämnat det ursprungliga livscykelproblemet på plats. Ändra konfigurationen, inte bara körtidstillståndet.

En städning som slutar med att gränssnittet är tillbaka och reglerna dubblerade är värre än ingen städning.

Hitta ägaren innan du rör det

Börja med ip link show och TUN/TAP-inspektionsverktygen för att få gränssnittet, dess adresser och rutter. Kontrollera klienten, tjänsten eller nätverkshanteraren som kan äga det. Bekräfta om enheten är beständig och vilket läge den använder. Bestäm sedan om någon fortfarande är beroende av det.

För ett bekräftat oanvänt beständigt gränssnitt, ip tuntap dokumenterar borttagning som beror på läget. Matcha det faktiska enhetsnamnet och läget, och kör inte en bred städning mot varje tunnel på värden.

Håll återställningsåtkomst och andra klienters rutter intakta medan du arbetar. Anteckna kommandot du använde så att nästa kontroll kan upprepas exakt.

Ta bort det via ägaren och kontrollera sedan vad som återstår

Stoppa eller ta först bort den stödda anslutningskonfigurationen, så att tjänsten inte återskapar det du tar bort. Ta sedan bort enheten. Inspektera därefter inaktuella adresser, rutter och resolverstatus under deras egna ägare.

Om problemet återkommer vid återanslutning, reparera livscykelkonfigurationen i stället för att upprepa den manuella borttagningen. En städningspost som namnger det övergivna, varför det var oanvänt och vilken komponent som bör hantera ersättningen sparar nästa person från att förväxla ett legitimt beständigt gränssnitt med ett fel.