Vad TUN gör och vad VPN-protokollet fortfarande måste göra

Att behandla tun0 och ett VPN-protokoll som en enda sak skickar folk till fel logg. Gränssnittet är en lokal gräns där ett program i användarutrymmet utbyter IP-paket med kärnan. Protokollet är vad det programmet gör med paketen när det har dem: transport, autentisering, kryptering och en motpart. Att skapa enheten väljer inget av detta.

Två komponenter, en paketväg

Kärnan skriver ett IP-paket till enheten och programmet läser det från en fildeskriptor. I andra riktningen skriver programmet ett paket tillbaka och kärnan dirigerar det som om det kom in på ett riktigt gränssnitt. TUN bär IP, medan TAP bär Ethernet-ramar. Att läsa ett paket vid den gränsen visar inramningen, och det är precis vad enheten är till för.

Allt bortom den gränsen är programmets sak. Två program kan använda samma gränssnittsbegrepp och göra helt olika saker med paketen. Enheten själv har ingen åsikt om vad som händer sedan. Fildeskriptorn är det enda handtag programmet har på kärnsidan.

Skapa enheten och bevaka sedan gränsen

Skapa en enhet med avsikt när du testar gränsen. En beständig enhet överlever processen som skapade den, vilket är användbart för experiment och en vanlig källa till förvirring efteråt. Kontrollera flaggorna och ägaren innan du skyller på VPN:en.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

Länkdetaljerna visar enhetstypen och den kopplade ägaren. Om ingen process håller den öppen hamnar paket som skrivs till den ingenstans. En enhet utan kopplad process kan se frisk ut i en länklista medan den inte släpper igenom något.

Vad gränssnittsnamnet inte kan lova

Gränssnittsnamnet säger ingenting om kryptering eller autentisering. Ett program kan packa in paketen i TLS, i ett eget protokoll, i IPsec eller i ingenting. Att välja TUN i stället för TAP ändrar inramningen vid gränsen, inte säkerhetsdesignen. Valet av inramning är verkligt, och det är mycket mindre än säkerhetsfrågan.

Identifiering fungerar på samma sätt: en observatör ser det yttre protokollet på ledningen, inte en etikett som säger vilken lokal enhet som producerade det. En tunnel som ser ut som något annat gör det på grund av sitt yttre protokoll, inte på grund av sitt gränssnittsnamn. En observatör kan inte se vilken lokal enhet som producerade ett paket, bara hur paketet ser ut. Håll de två frågorna isär när du jämför produkter, för ett svar innebär aldrig det andra.

Anpassa åtgärden till steget som fallerar

Skilj på felfasen när något går sönder. En saknad enhet, ett behörighetsfel och en avvisad inloggning ger olika bevis och olika åtgärder. Läs först det lokala tillståndet, sedan programmets egen logg, sedan motpartens syn. Läs alla tre innan du ändrar något.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

Om enheten finns och en process håller den fungerar den lokala gränsen och problemet ligger längre ut. Om enheten saknas hjälper ingen kontroll av inloggningsuppgifter. Ett steg du kan namnge är ett steg du kan testa. Dokumentationen för TUN/TAP beskriver gränsen och enhetsmodellen.