Ulilang TUN interface: hanapin ang may-ari bago ito tanggalin

Nakalista pa rin ang iyong TUN interface, hindi nagpapadala ng trapiko ang tunnel, at ang halatang solusyon ay mukhang pagtanggal ng link. Dito nagiging outage ang maliliit na paglilinis. Maaaring permanente ang interface ayon sa disenyo, pagmamay-ari ng serbisyong gagawa muli nito, o nagtatago sa namespace kung saan ang parehong pangalan ay may ibang kahulugan. Ang pagkakaroon nito ay hindi patunay na ito ay ulila.

Madaling tanggalin ang pinangalanang interface. Ang malaman kung ano ang nakadepende rito ang tunay na gawain.

Mito: natira ang interface dahil bagsak ang tunnel

Ang permanenteng TUN device ay umiiral nang hiwalay sa konektadong session. Iyon ang punto ng permanenteng flag: nananatili ang device para magamit muli ito ng susunod na koneksyon. Walang trapikong dumadaloy, at walang mali.

Maaari ring pagmamay-ari ng interface ang isang serbisyong nasa pagitan ng mga restart, o ng client na idle ang profile. Suriin ang prosesong may-ari at ang configuration bago magpasya na ito ay inabandona. Ang listahan ng proseso at ang configuration na nagpapatakbo rito ay mas matibay na ebidensya kaysa nawawalang tunnel.

Itala ang namespace kasama ng pangalan. Maaaring may interface ang ibang namespace na may parehong pangalan, at walang kaugnayan ang dalawa. Gamitin ang namespace flag kapag kailangan mong siyasatin ang iba.

Mito: nililinis ng pagtanggal ng link ang lahat

Inaalis ng pagtanggal ng link ang mga address at ruta na nakakabit dito. Hindi nito inaalis ang policy rules, firewall rules, resolver settings o helper scripts na tumutukoy rito. Maaaring manatili ang mga iyon at tumuro sa device na wala na.

Kung naka-configure pa rin ang serbisyo, maaaring muling gawin nito ang interface sa susunod na startup o reconnect. Niloob mo noon ang pagtanggal ng gumaganang resource at iniwan ang orihinal na problema sa lifecycle. Baguhin ang configuration, hindi lamang ang runtime state.

Ang paglilinis na nagtatapos sa pagbabalik ng interface at pagdoble ng mga rule ay mas masama kaysa walang paglilinis.

Hanapin ang may-ari bago ito galawin

Magsimula sa ip link show at sa mga tool sa inspeksyon ng TUN/TAP para makuha ang interface, mga address at ruta nito. Suriin ang client, serbisyo o network manager na maaaring may-ari nito. Kumpirmahin kung permanente ang device at anong mode ang ginagamit. Pagkatapos ay magpasya kung may umaasa pa rito.

Para sa kumpirmadong hindi ginagamit na permanenteng interface, ip tuntap ay nagdodokumento ng pagtatanggal na partikular sa mode. Itugma ang aktwal na pangalan at mode ng device, at huwag magpatakbo ng malawak na paglilinis laban sa bawat tunnel sa host.

Panatilihing buo ang recovery access at ang mga ruta ng ibang client habang nagtatrabaho. Itala ang command na ginamit mo para tumpak na maulit ang susunod na pagsusuri.

Alisin ito sa pamamagitan ng may-ari, pagkatapos ay suriin kung ano ang natitira

Itigil o alisin muna ang sinusuportahang configuration ng koneksyon, para hindi muling gawin ng serbisyo ang tinatanggal mo. Pagkatapos ay alisin ang device. Pagkatapos, siyasatin ang mga lumang address, ruta at resolver state sa ilalim ng kani-kanilang may-ari.

Kung bumalik ang problema sa reconnect, ayusin ang lifecycle configuration sa halip na ulitin ang manu-manong pagtanggal. Ang talaan ng paglilinis na nagbabanggit sa ulila, bakit hindi ito ginamit at aling component ang dapat mamahala sa kapalit ay nagliligtas sa susunod na tao mula sa maling pagtingin sa isang lehitimong permanenteng interface bilang sira.