Hvad TUN gør, og hvad VPN-protokollen stadig skal gøre

At behandle tun0 og en VPN-protokol som én ting sender folk til den forkerte log. Grænsefladen er en lokal grænse, hvor et program i brugerrummet udveksler IP-pakker med kernen. Protokollen er det, programmet gør med pakkerne, når det har dem: transport, godkendelse, kryptering og en modpart. Oprettelsen af enheden vælger ingen af delene.

To komponenter, én pakkevej

Kernen skriver en IP-pakke ind i enheden, og programmet læser den fra en filbeskrivelse. I den anden retning skriver programmet en pakke tilbage, og kernen ruter den, som om den var ankommet på en rigtig grænseflade. TUN bærer IP, mens TAP bærer Ethernet-rammer. At læse en pakke på den grænse viser indramningen, og det er netop, hvad enheden er til.

Alt ud over den grænse er programmets sag. To programmer kan bruge det samme grænsefladebegreb og gøre helt forskellige ting med pakkerne. Enheden selv har ingen mening om, hvad der sker bagefter. Filbeskrivelsen er det eneste håndtag, programmet har på kernens side.

Opret enheden, og hold så øje med grænsen

Opret en enhed med vilje, når du tester grænsen. En vedvarende enhed overlever den proces, der oprettede den, hvilket er nyttigt til forsøg og en almindelig kilde til forvirring bagefter. Tjek flagene og ejeren, før du bebrejder VPN'en.

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

Linkdetaljerne viser enhedstypen og den tilknyttede ejer. Hvis ingen proces har den åben, ender pakker skrevet til den ingen steder. En enhed uden tilknyttet proces kan se sund ud i en linkliste, mens den ikke sender noget videre.

Hvad grænsefladenavnet ikke kan love

Grænsefladenavnet siger intet om kryptering eller godkendelse. Et program kan pakke pakkerne ind i TLS, i en egen protokol, i IPsec eller i ingenting. At vælge TUN i stedet for TAP ændrer indramningen på grænsen, ikke sikkerhedsdesignet. Valget af indramning er reelt, og det er meget mindre end sikkerhedsspørgsmålet.

Registrering fungerer på samme måde: en observatør ser den ydre protokol på ledningen, ikke en etiket, der fortæller, hvilken lokal enhed der har produceret den. En tunnel, der ligner noget andet, gør det på grund af sin ydre protokol, ikke på grund af sit grænsefladenavn. En observatør kan ikke se, hvilken lokal enhed der har produceret en pakke, kun hvordan pakken ser ud. Hold de to spørgsmål adskilt, når du sammenligner produkter, for ét svar indebærer aldrig det andet.

Tilpas rettelsen til det trin, der svigter

Adskil fejltrinene, når noget går i stykker. En manglende enhed, en tilladelsesfejl og et afvist login giver forskellige beviser og forskellige rettelser. Læs først den lokale tilstand, derefter programmets egen log og til sidst modpartens syn. Læs alle tre, før du ændrer noget.

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

Hvis enheden findes, og en proces holder den, virker den lokale grænse, og problemet er længere ude. Hvis enheden mangler, hjælper ingen kontrol af loginoplysninger. Et trin, du kan navngive, er et trin, du kan teste. Dokumentationen for TUN/TAP beskriver grænsen og enhedsmodellen.