OpenVPN på en VPS: ingen /dev/net/tun-enhet att öppna

Första starten misslyckas med ett meddelande om /dev/net/tun eller en TUN/TAP-enhet som inte kan öppnas. Certifikaten har ännu inte lästs, så inget i profilen är misstänkt. Daemonen ber kärnan om ett objekt som gästen inte har.

Objektet är en teckenenhet som tillhandahålls av tun-modulen. Om du kan skapa den beror på vem som äger kärnan.

Vad daemonen ber kärnan om

OpenVPN öppnar /dev/net/tun och ber drivrutinen om ett gränssnitt. Drivrutinen är tun-modulen och enhetsnoden är handtaget som användarutrymmet använder för att nå den. Om modulen inte är laddad kan noden saknas eller öppningen misslyckas. Inget av tillstånden åtgärdas genom att redigera server.conf.

Läs felet först som en fråga om plattformen. Ett konfigurationsfel visas efter att enheten öppnats, inte före.

VM eller gäst med delad kärna

På KVM, Xen eller en annan fullständig virtuell maskin kontrollerar du kärnan. Du kan läsa in moduler och skapa noden. På OpenVZ, Virtuozzo eller i en container i LXC-stil delar gästen värdens kärna, så root inuti den kan inte läsa in en modul som värden inte har läst in.

Samma fel har därför två mycket olika ägare. I det första fallet kan du åtgärda det inifrån instansen. I det andra ber du värden, eller leverantören, att exponera något.

Kör ls -l /dev/net/tun, lsmod | grep tun och ip -brief link show innan du avgör vilket fall du är i.

På en VM, läs in modulen vid start

På en virtuell maskin skapar modprobe tun vanligtvis enhetsnoden. Kontrollera att den dyker upp och gör sedan inläsningen beständig via distributionens modulkonfiguration i stället för att förlita dig på ett kommando som skrivits en gång. En nod som försvinner efter omstart blir samma ärende nästa månad.

Kontrollera också att kärnan du startade har modulen överhuvudtaget. En nedskalad leverantörskärna kan sakna den.

Om noden finns men öppningen fortfarande misslyckas är behörigheter och enhetens major/minor-nummer nästa misstänkta. Det är lokala åtgärder, inte förfrågningar till leverantören.

I en container äger värden enheten

I en container är enheten och kapabiliteten två separata krav. Runtime måste släppa igenom /dev/net/tun, och containern behöver nätverkskapabiliteten för att skapa ett gränssnitt. En rootless runtime som inte ger något av dem kommer att fortsätta producera samma öppningsfel hur profilen än skrivs. Många OpenVZ-värdar erbjuder en TUN/TAP-brytare i kundpanelen, och att slå på den plus en omstart är ofta hela lösningen.

Ställ två precisa frågor till leverantören: är tun-modulen laddad på värden, och är enheten tillgänglig inuti den här instansen? Ett vagt ärende får ett vagt svar.

Varför det sällan hjälper att bygga om modulen

Att bygga en modul inuti gästen hjälper sällan. Kompilering kräver konfigurationen för exakt den kärna som körs, och /proc/config.gz är valfri och saknas ofta på minimala avbildningar. Även en fungerande modul kan inte sättas in i en kärna som containern inte äger.

När enheten dyker upp, starta om tjänsten och bekräfta gränssnittet innan du testar trafik. Att se tun0 visar att daemonen öppnade enheten. Det säger ännu inget om vidarebefordran, brandväggsregler eller de rutter klienterna får.

Det är separata frågor med separata bevis. En saknad enhet är ett förutsättningsfel; en tunnel som finns men inte transporterar något är ett policyfel.