OpenVPN på en VPS: ingen /dev/net/tun-enhed at åbne

Den første start mislykkes med en meddelelse om /dev/net/tun eller en TUN/TAP-enhed, der ikke kan åbnes. Certifikaterne er endnu ikke læst, så intet i profilen er mistænkt. Dæmonen beder kernen om et objekt, som denne gæst ikke har.

Det objekt er en tegnenhed, der understøttes af tun-modulet. Om du kan oprette den, afhænger af, hvem der ejer kernen.

Hvad dæmonen beder kernen om

OpenVPN åbner /dev/net/tun og beder driveren om et interface. Driveren er tun-modulet, og enhedsknuden er det håndtag, brugerrummet bruger til at nå den. Hvis modulet ikke er indlæst, kan knuden mangle, eller åbningen kan mislykkes. Ingen af de to tilstande rettes ved at redigere server.conf.

Læs fejlen som et platforms-spørgsmål først. En konfigurationsfejl vises, efter at enheden er åbnet, ikke før.

VM eller gæst med delt kerne

På KVM, Xen eller en anden fuld virtuel maskine styrer du kernen. Du kan indlæse moduler og oprette knuden. På OpenVZ, Virtuozzo eller en LXC-lignende container deler gæsten værtens kerne, så root indeni kan ikke indlæse et modul, som værten ikke har indlæst.

Den samme fejl har derfor to meget forskellige ejere. I det første tilfælde kan du rette den inde fra instansen. I det andet beder du værten eller udbyderen om at eksponere noget.

Kør ls -l /dev/net/tun, lsmod | grep tun og ip -brief link show, før du beslutter, hvilket tilfælde du er i.

På en VM, indlæs modulet ved opstart

På en virtuel maskine opretter modprobe tun normalt enhedsknuden. Kontroller, at den vises, og gør derefter indlæsningen permanent via distributionens modulkonfiguration i stedet for at stole på en kommando, der er skrevet én gang. En knude, der forsvinder efter en genstart, bliver den samme sag næste måned.

Kontroller også, om den kerne, du har startet, overhovedet har modulet. En skrællet leverandørkerne kan mangle det.

Hvis knuden findes, men åbningen stadig mislykkes, er tilladelser og enhedens major/minor-numre de næste mistænkte. Det er lokale rettelser, ikke anmodninger til udbyderen.

I en container ejer værten enheden

I en container er enheden og kapabiliteten to separate krav. Runtime skal sende /dev/net/tun igennem, og containeren har brug for netværkskapabiliteten til at oprette et interface. En rootless runtime, der ikke giver nogen af delene, vil blive ved med at producere den samme åbningsfejl, uanset hvordan profilen er skrevet. Mange OpenVZ-værter viser en TUN/TAP-kontakt i kundepanelet, og at slå den til plus en genstart er ofte hele løsningen.

Stil udbyderen to præcise spørgsmål: er tun-modulet indlæst på værten, og er enheden tilgængelig inde i denne instans? En vag sag får et vagt svar.

Hvorfor genopbygning af modulet sjældent hjælper

At bygge et modul inde i gæsten hjælper sjældent. Kompilering kræver konfigurationen af den præcist kørende kerne, og /proc/config.gz er valgfri og ofte fraværende på minimale images. Selv et fungerende modul kan ikke indsættes i en kerne, som containeren ikke ejer.

Når enheden vises, genstart tjenesten, og bekræft interfacet, før du tester trafik. At se tun0 viser, at dæmonen har åbnet enheden. Det siger endnu intet om videresendelse, firewallregler eller de ruter, klienterne får.

Det er separate spørgsmål med separate beviser. En manglende enhed er en forudsætningsfejl; en tunnel, der findes, men ikke bærer noget, er en politikfejl.