Hva TUN gjør, og hva VPN-protokollen fortsatt må gjøre

Å behandle tun0 og en VPN-protokoll som én ting sender folk til feil logg. Grensesnittet er en lokal grense der et program i brukerrommet utveksler IP-pakker med kjernen. Protokollen er det programmet gjør med pakkene når det har dem: transport, autentisering, kryptering og en motpart. Opprettelsen av enheten velger ingen av delene.

To komponenter, én pakkevei

Kjernen skriver en IP-pakke inn i enheten, og programmet leser den fra en filbeskrivelse. I den andre retningen skriver programmet en pakke tilbake, og kjernen ruter den som om den kom inn på et ekte grensesnitt. TUN bærer IP, mens TAP bærer Ethernet-rammer. Å lese en pakke på den grensen viser innrammingen, og det er nettopp det enheten er til.

Alt utenfor den grensen er programmets sak. To programmer kan bruke samme grensesnittbegrep og gjøre helt forskjellige ting med pakkene. Enheten selv har ingen mening om hva som skjer videre. Filbeskrivelsen er det eneste håndtaket programmet har på kjernesiden.

Opprett enheten, og følg deretter med på grensen

Opprett en enhet med vilje når du tester grensen. En vedvarende enhet overlever prosessen som opprettet den, noe som er nyttig for eksperimenter og en vanlig kilde til forvirring etterpå. Sjekk flaggene og eieren før du klandrer VPN-en.

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

Lenkedetaljene viser enhetstypen og den tilknyttede eieren. Hvis ingen prosess holder den åpen, går pakker som skrives til den ingen steder. En enhet uten tilknyttet prosess kan se sunn ut i en lenkeliste mens den ikke slipper noe gjennom.

Hva grensesnittnavnet ikke kan love

Grensesnittnavnet sier ingenting om kryptering eller autentisering. Et program kan pakke pakkene inn i TLS, i en egen protokoll, i IPsec eller i ingenting. Å velge TUN i stedet for TAP endrer innrammingen på grensen, ikke sikkerhetsdesignet. Valget av innramming er reelt, og det er mye mindre enn sikkerhetsspørsmålet.

Oppdagelse fungerer på samme måte: en observatør ser den ytre protokollen på ledningen, ikke en etikett som sier hvilken lokal enhet som produserte den. En tunnel som ser ut som noe annet, gjør det på grunn av sin ytre protokoll, ikke på grunn av grensesnittnavnet. En observatør kan ikke se hvilken lokal enhet som produserte en pakke, bare hvordan pakken ser ut. Hold de to spørsmålene fra hverandre når du sammenligner produkter, for ett svar innebærer aldri det andre.

Tilpass rettelsen til trinnet som svikter

Skille feilstrinnene når noe går i stykker. En manglende enhet, en tillatelsesfeil og en avvist innlogging gir ulike bevis og ulike rettelser. Les først den lokale tilstanden, deretter programmets egen logg, deretter motpartens syn. Les alle tre før du endrer noe.

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

Hvis enheten finnes og en prosess holder den, virker den lokale grensen, og problemet er lenger ute. Hvis enheten mangler, hjelper ingen kontroll av påloggingsinformasjon. Et trinn du kan navngi, er et trinn du kan teste. Dokumentasjonen for TUN/TAP beskriver grensen og enhetsmodellen.